LESSONS LEARNED AFTER BUILDING A TECH TEAM FROM SCRATCH
A bit more than three years ago, I co-founded Comet, a french based company that helps freelancers to become sustainable by providing them missions and tools. As a tech founder, I had to adapt intensively to new orientations, business opportunities while building a robust technical team for the company. CTO is a fancy term you give to yourself when building a company as a tech founder, but in fact, in the beginning, you are just the first developer in the team.
These challenging years allowed me to understand some very interesting aspects of a fast-growing technology company. I finally had the idea of writing this article to help people who might encounter the same issues I did. I am pretty sure companies meet the same challenges at some point, particularly during their early days. Also, I am not pretending to have the perfect fit for everyone, but in the scope of this article, I wrote down things that I learned the hard way. Hopefully, it would help some to save time and stay focused on the right problem for their current stage.
SUFFER BEFORE HIRE
Don’t rush the recruitment, you probably can continue a bit more in your actual stage and it is a big mistake to recruit according to the ability to do it. You recruit because you need to, not because you can. This is particularly true for funded companies that suddenly have raised money and can afford a much bigger team. Think about frugality, what can your team do without being bigger? How can you optimize your processes? As a tech leader, you should seek the best ratio between team size and productivity. Recruitment is always the ultimate solution.
Do it yourself
Once you start recruiting, you’ll probably face new jobs you are not an expert in. It is always a bad idea to delegate a job you don’t understand. Identify your coming challenges and start working on yourself. This will give you a more advanced point of view on what the team needs at a certain time.
Recruiting an expert is always the key at scale, but starting slowly by handling tasks by yourself is usually a good starting point. Understanding the problem you have and the good way to solve it before recruiting an expert would give you a more precise idea of the expert you need. Also, a new coming expert would still need a bit of context to choose the right path. Having done the job before, you might have a good clue to share.
Stress is better than tiredness
Recruiting to bring comfort to the team is also a bad idea. You might think at some point that your team needs more time to step back and think about a bigger picture. You might also think about replication, doubling the effort on some matter to avoid a single point of failure or bottleneck. While this is a good concern, be careful. The last thing you want is to put your team in a laidback mood reducing your productivity over time.
It might also demotivate people who may not understand their impact on the project. It is very hard to revert that mindset once it is installed in the team. Your team needs to be a bit stressed to deliver at a good pace. Stress is not necessarily a bad thing as it gives people better feedback on their importance to the team. Too much stress is not good either. Don’t break your team, tight people with deadlines but don’t ask them to work overnight unless the company is at risk and it is temporary.
HIRE THE RIGHT FOLKS
When you need to hire, do it well. Recruitment is true science, and hopefully, there are methods to do it properly. Remember, you don’t recruit friends to share beers with. You are looking for skilled experts who share your company values. This is rare, and you will meet more failures than success, but if you recruit properly, this would be a game-changer for your company.
Write scorecards
First thing first, you cannot recruit if you don’t know what you need. Write scorecards, define the role and major outcomes you are looking for. What does mean a QA Engineer for your team? Do you want your DevOps to be SRE? What is the main difference between a senior developer and a junior? All these questions must have answers. You don’t need to over-engineer a scorecard, just write down the expected outcomes for the role. Here is a QA Engineer scorecard at Comet for example. Writing scorecards would be useful for recruitment, but also to promote actual team members.
You should write scorecards for every job you have in your team, use KPIs as outcomes when available or SMART goals, so you cannot discuss how to assess performance. Also, share the scorecard during interviews with candidates so they can understand what is the job and give feedback about it. It is a good way to assess if a candidate is comfortable with the job or not.
Don’t doubt
Eventually, you will have doubts about a candidate during the process. Doubt means NO-GO. You have a recruitment process to catch any misfit or misalignment before engaging energy with someone. If you smell something bad, trust yourself. Your time does not worth taking the risk. Sometimes a candidate seems to be the perfect fit considering the hard skills but a terrible solution for the team, this is also a no-go.
A good fit should include both, hard-skills and soft-skills. I know this sounds dumb and obvious, but it is easier to occult a part of the problem because; “we need a new DevOps, and Paul has the skills we seek for months”. If Paul is a cultural misfit, you are going to deeply regret your decision no matter his hard-skills.
KEEP PEOPLE FOCUS
When your team gets bigger, you will probably have no time to do an operational job anymore. It’s going to be harsh, going from an operational job to a strategical one is not an easy move, but it is a good sign your company has evolved (in a good way). Don’t lose yourself, you have multiple solutions; Either you try to focus on the tech part and recruit a VP Engineering to handle the team, or you focus on the management and look for a CTO for the technological strategy. No matter your choice, at this point, it is time to put management in your team.
Management is a threat to execution
Managers don’t have a direct impact on production, but they do have a long-term impact on the team. While a good manager can drive individuals, and thus, the team to succeed, a bad manager can destroy your delivery and lead to turnover. Tech folks are expensive to recruit and retain, the last thing you need is to spend a tremendous amount of time and energy recruiting to see folks leaving after only a few months.
When starting the management chapter, ask yourself what means management to your team. Draft the scorecards with your team, so they can understand what is the job. Introduce your team in the recruitment process. They should be able to give feedback so the onboarding would be smoother when it’s time. Gathering respect from the team is particularly important for technical managers as developers tend to be more sensitive to technical hard skills for such positions. It does not mean that a developer is a good manager, but your future manager should be at least a bit technical.
Management is not a promotion
Promoting your best developer to a managing position is a non-sense. Developing and managing are two different jobs that require completely different skills. There is no relation whatsoever between these two roles in the team and this misunderstanding could lead to terrible damages.
This being said, it does not mean that developers cannot be managers. Consider your developers who want to become managers, but handle them as they ask to switch for a different job in the company. Test their ability with the manager scorecard and build a ramping phase so they can progressively test their new position and eventually get back to their job without feeling being demoted. Remember that such management errors are very costly for the team (and individuals). Don’t lose the opportunity to be 100% sure before officializing a move concerning management.
THAT BEING SAID
Once you started to recruit, your next problem might be what should be your role in the team? Should you continue to code? That’s a whole new chapter coming in.
