When to hire your first engineering manager

When you’re a startup CTO, everything seems easy in the beginning. You have an idea, you code it and release it to users. Boom. Then you start hiring developers. Everyone is in the same room, everyone knows what to do, and you still code 80% of your time. It’s exhilarating. But there is a point where the team dynamics start to change. You raised a new round of funding, and there are now 12 developers and counting. Some of them are senior engineers; some of them are out of school. All of a sudden, the flat organisation that was so symbiotic is not functioning so well.

Developers now need more time to ship the same amount of features. Sometimes they have to wait for others to finish what they’re doing to finalise their feature. Some of the older members are nostalgic of the early days’ fast pace and have started dusting off their LinkedIn profile. Your co-founder is now telling you to hire managers and stop spending so much time coding. But is it the right thing to do? And what should these managers do?

When managers do their job right, they focus on one thing and one thing only: consistently reaching the team’s objectives by providing an environment where individual team members perform at their best. To do this job right, managers should spend significant time coaching and helping team members to improve as professionals. If there are too many people in the team, managers won’t spend enough time with team members and only perform superficial coaching. If there are too few people in the team, their value won’t be optimal. And if engineers are left without supervision, they will eventually stop getting feedback, meaning and career outlook, as Google painfully found out in 2001.

A framework for hiring engineering managers

There’s actually an ideal number of people a manager should have in their team: seven. Why seven? According to cognitive psychologist George A. Miller, the number of objects an average human can hold in short-term memory is 7 ± 2, also known as the magical number seven. Keeping the team small allows engineering managers to serve their team better. And since engineering management thinkers Will Larson and Michael Lopp agree, I’ve also adopted seven as the ideal team size number for the below framework.

1/ Between 1 and 5 developers, the CTO acts as a technical lead. They spend more than 50% of their time contributing to the code base and use the remaining time to coordinate with other developers and, when necessary, help them technically.

2/ Between 6 and 8 developers, the CTO should now act as an engineering manager and reduce their coding time to 20% or less. That means that the roadmap should be sized for the number of developers in the team, not accounting for the CTO who focuses on management activities (coaching, coordination, strategy). Ideally, by now, the CTO has started to delegate some of their old tech responsibilities to other tech leads (1 for 4 developers).

3/ Above 9 developers, the CTO should start creating new teams, led by either tech leads (if the team has less than 5 developers) or managers (if the team has 6 to 8 developers).

Small teams

The other advantage of creating small teams is to keep the startup mindset and agility within each team. There are many ways to start creating new teams, but Twilio’s CEO, Jeff Lawson, shares an excellent framework in his book, Ask your developer: Customer, Mission, and Metrics.

For a team to develop the intrinsic drive of a startup, they need organizing principles that articulate their purpose. I typically start by defining the customer they’re serving. This could be an external customer in the traditional sense, or it could be an internal customer they’re serving [...] Once you have a customer defined, then you define a mission [...] The mission statement should be accessible, easy to remember and articulate, and devoid of jargon so the team members actually believe it [...] Last, to measure progress against this mission, and to know if customers are being served by the team’s existence, they need measures of success.

When a team has a very clear customer, mission and set of metrics, they depend less on upper management (or other teams) to make decisions and are empowered to take initiatives within their scope.