Patrick is the CTO of DataPlus, a 100-person business intelligence startup. DataPlus is currently enjoying double-digit growth and probably won’t need to raise funding anytime soon. As CTO, Patrick oversees product (led by a Head of Product), data operations (lead by a Head of Data Operations) and engineering. The engineering team consists of 4 engineering leads, each of them managing 2 to 6 developers. On average, the leads currently spend 60% of their time writing code (alone or in pair with team members) and 40% of their time synchronising with other leads and product owners.
To scale the engineering team, Patrick had tried in the past to hire a Head of Engineering, but the person he recruited, while brilliant, regularly overlapped with his CTO responsibilities. This person eventually became CTO of a DataPlus spinoff. While Patrick is still wondering if he should keep looking for a Head of Engineering, one of the engineering leads, Lily, told him she’s interested in the job. Lily is a brilliant engineer and regularly shows leadership, but Patrick is wondering if she might not be a bit too junior for the role.
What should Patrick do?
There is a big debate within the tech community on the importance of managers, especially at startups and small companies. Do we need to have managers, what are they for, and why pay people who don’t code? With that in mind, it is common for small companies’ CTOs to manage 25-50 developers directly, giving them a lot of autonomy. Yet when you ask developers what they think about it, they want managers (and not just any). Following a large-scale study called Project Oxygen, Google realised that (good) managers had a significant impact on a team’s productivity and systematically shared the same skills (the list is in the study link). So technology organisations need (good) managers.
In An Elegant Puzzle: Systems of Engineering Management, Will Larson (CTO of Calm, former Head of Engineering at Stripe) argues that the ideal number of engineers in a team is between 4 and 6. Below 4, the manager is more like a Tech Lead: they code 60% of the time and spend the rest synchronising with other teams and mentoring juniors (this is Patrick’s case today). In this configuration, the lead cannot coach their team members, to help them overcome their difficulties, or to acquire new skills.
While counter-intuitive, managers who spend time coaching their teams and making continuous improvements are the ones who get the best results. What you want to avoid, on the other hand, is managers who spend 80% of their time in meetings and synchronising, and only 20% improving their team (individually and collectively). The development process must be as fluid as possible to reduce friction between teams.
Concerning Patrick’s situation, he has, in my opinion, two solutions:
Solution 1: Hiring an external Head of Engineering
Patrick hires an external Head of Engineering who has a “systems design” profile (basically someone who has An Elegant Puzzle, High Output Management and Team topologies by their bedside) and who will coach the leads to become better at coaching and leading their teams. The right candidate is someone who is currently an Engineering Director in a post-series C startup (raised +50M€) and who has already managed managers. An Engineering Manager who manages leads can also be the right choice since DataPlus EMs currently act more like leads than managers, and EMs might ask for a slightly lower salary 💸
Benefit(s): Patrick brings on board an experienced manager who will work on increasing the team’s performance and upskilling the current leads, including Lily.
Drawback(s): Great leads of leads are difficult to find and might not want to join a company where the career ceiling is blocked (Patrick is one of the founders). Lily might also have a motivational down since she wanted the job and didn’t get it.
Solution 2: Chief Architect + Training
Considering DataPlus current growth pace (they won’t double team size every year), Patrick could choose a slightly longer-term solution. The idea is to turn the current leads into managers. Basically, instead of spending 60% of their time coding and 40% doing sync, they will gradually end up spending 80% of the time making team improvement (coaching + systems design). To do that, Patrick must:
1/ Solve his synchronisation problem → leads are currently spending too much time doing synchronisation. Patrick could ask Lily to become Chief Architect with the mission of reducing friction and need for synchronisation between teams to 0. Micro-services, agile rituals, etc. She sets up what she wants, but Patrick’s leads need to stop spending time in meetings. If thousands of strangers manage to sync without meetings in open source projects, there’s no reason 25 talented developers can’t.
2/ At the same time, Patrick trains the leads on management skills (including Lily) so that they can start behaving like managers-coach. Their missions will be to improve their team, individually (coaching) and collectively (systems design).
3 / Patrick sets up (with the support of the Chief Architect) a series of metrics that will allow him to manage the engineering team, without having to be too much involved in operations.
Benefit(s): Patrick scales the engineering team without adding a perhaps unnecessary management layer. He also grows his internal talents (who already have the right corporate culture) and values them.
Drawback(s): Patrick will have to continue managing the engineering team directly while training and architectural results start to show. This solution obviously won’t work when the team goes over six leads.
Solution 2 also allows Patrick to test Lily in a leadership position, without putting too much pressure on her by giving her the Head of Engineering title. If Lily is also trained in parallel on systems design and coaching, and she performs well as a Chief Architect, Patrick might consider appointing her Head of Engineering.