How I hired my first engineer and how he changed everything

When I joined Scrimmage there already was a team of 3 engineers. All of them were cheap offshore engineers from the countries like India and Pakistan. In addition to being from cheap countries, they also were juniors so the product was really struggling. I came from a place where clean code practices were the #1 priority and without careful refactoring you can’t even push your code to remote. Here everyone was pushing code in a single master branch with no review, no linter, and no architecture. In addition to that they were using vanilla JS which made me cry a lot of times after seeing functions with 10 parameters and no clue what those parameters mean.

At the moment I became a CTO, everyone knew, that change is going to come. Initially, I always wanted to make things work how they are. I started to add more structure to our development, introducing peer reviews, liners, etc. But then I noticed that it is not enough to just give tools, you have to make people believe in them and know how to use them. I started talking to every member of the team on 1 to 1 calls that they have to start learning clean code and a bunch of other resources I send them. For me, it was a common practice to spend 2-3 hours per day learning some new technologies but I knew it is not everyone’s choice so I felt a little bit awkward asking for that. It came to a point where I even proposed to pay for the time they spend learning that because ROI was obvious to me.

After 3 months of struggles, I realized that now I spend more time talking to people, reviewing code, and fixing bugs than actually writing code. Time was moving fast, but the quality of the code was moving barely. That is how I realized that sometimes it is better to be alone than with a team of 3 juniors. My management approach has always been peer-based. I position myself as just one more guy on your team who has his own life, his own problems. Sometimes I am also tired, sometimes I am very motivated sometimes happy. Eventually, I build a strong connection with a team and form loyalty, which is an end goal of my management approach.

The advantage of this approach is that work feels easy. You can tell me anything you want and you will never expect blame or a cold answer. However, there are disadvantages… I get really attached to people I work with and when the time comes to fire, it makes things complex. I remember my first firing meeting. I took a day off that day to just calm down my emotions and convince myself that I made the right decision.

Eventually, I fired everyone, except one front-end developer who was helping me with simple design work. Work was feeling much easier, now I had complete control over a code based and was able to make the product move faster than it was moving before, which was shocking. More engineers are not always equal to more progress.

Hiring the first new Engineer

I knew that we had money for one more engineer but I didn’t want to hire anyone less than a person like me. And I knew one such person. It was a guy whom I met on my previous job. I was working with him for like 2 months together but he impressed me with honesty and dedication. The most impressive fact about him was that he was coding in his free time. He also was the best engineer I ever knew, so I was hunting him hard. Every month I was texting him if he is looking for a new project and one day I got a successful reply. At that moment my co-founders were already convinced that he was worth whatever money I negotiate so the rest was just me talking to him.

That was the most awkward hiring call I ever had because usually, you don’t know the person you hire, but here we knew each other to some extent. I was trying to position Scrimmage as a potentially great startup with an amazing team of me. My trust in him made me say that our code is shit and our second developer is a junior which almost made him drop the proposal lol. Don’t say engineers that your code is shit on the first meeting, never)

Eventually, he asked for a higher salary, I was greedily doubting it for a day but then agreed. That was a pivotal moment for Scrimmage technical team because this guy changed everything. I had high standards for writing code. He had ridiculously high standards for writing code. Even I decided to rewrite clean code after bringing him on board lol.

2 months went fast and we made a lot of progress to the code base. At that point, we were trying to make this team work with 3 members including a junior frontend dev. To make it work we were introducing hard linters, strict project management, and double code reviews but eventually, we let him go. No there were only us two and a huge pivotal moment in a company’s history. While going through Techstars company decided to make a pivot into a web3 product. It was our chance to through all the dirty code we had and implement a new architecture with abstractions and types.

I don’t think I would have ever done it without him. I was a guy who was made to be a founder. I invest my time in everything, including marketing, product, business, design, etc. He was the guy who was made to be a technical leader. He invests all his time into learning new technologies and programming principles. When he has inspiration he organizes small hackathons on weekends. On Monday I code to him ask “How was your weekend”, expected an answer like “Good, had a nice sleep and played some games”. But I get a response like “Good, wrote an AI model that can classify who won a game by a screenshot”. When you hear this from someone, whatever you have right now, make this guy work with you.

If someone is ready to spend their free time learning or doing something they are doing during work – it is the biggest sign of a growth mindset and a passion for what they are doing. Such people make great co-founders and that has to be your first hire. The first 3 people you hire will establish the culture of your team for the rest of its life. Don’t hire people who are not reliable, not passioned, or not dedicated to what they are doing. Even one such person in the funding team can ruin the whole culture.

Conclusion

When Scrimmage was just starting the majority of the dev team was not dedicated and it was an extremely hard time for us. With time, we replaced those people with ones who are trustable and contribute greatly to the culture. My first hire made the biggest contribution toward it. Then there was the second and third hire which came on already established ground of a corporate culture and software architecture. Not high-quality standards, dedication, and a culture of growth are not something we wanna achieve, it is already a part of us and a part of every new team members which joins our team.