The number of direct reports for an engineering manager is a recurring debate among tech managers. I’ve heard many different versions of it, and I’ve witnessed many implementations, which led me to have strong battle-tested opinions on the topic.
So, how many reports should an engineering manager have?
I’m a fervent fan of High Output Management by Andy Grove, and in that book, he shares that “A manager whose work is largely supervisory should have six to eight subordinates; three or four are too few and ten are too many […] this ensures half a day per week for each subordinate.”
And the keyword here is “supervisory” which means the manager has a medium amount of individual responsibility, however, that level of responsibility will depend on how your organization and yourself want to define the role of engineering manager.
A lot has also been written about managerial archetype, but it all feels either subjective or generic to me, and the rationale is often not clear. Things are actually more complex than just following a rule of thumb, and I hope to shed some light as to how I think of it with this article.
The Criteria That I Like To Consider
Below are the criteria that I keep in mind when thinking about defining the role and span of an engineering manager. It’s a sort of brain dump of the things that have bitten me back in the past every time I made the mistake to ignore them.
The overall set of responsibilities. What you want the EM role to be and the time it takes for someone to drive those activities: more hands-on, vs. more managerial, vs. process, vs. tech leadership.
The bus factor. There are many reasons why someone might leave a team: they go on vacations, they get promotions in other areas of the company, or they simply quit their job. This is why a pair of two developers can never be a team, because if one leaves, it only takes the other one to go on leave to put the team’s scope on a full halt. In addition, a pair of two will make it hard for them to get a feeling of belonging to a team. A team requires a critical mass of people in order to be a team, and that has a direct impact on how many people will end up reporting into an engineering manager.
The job role ecosystem. For example, if your define the role as being totally people focused and have no expectations to be hands-on or manage stakeholders, then someone else in your org will have to do those tasks, which means that how you define the role of EM will start a chain reaction on your job role ecosystem, and will create overlaps or gaps with other roles in your organization which you will have to define and solve.
The ratio of managers to contributors, and org flatness. The number of direct reports for an EM will directly impact the ratio of EMs to ICs in the overall org, which is going to influence how flat the org will be. The higher the number of reports, and the fewer managers you need, and the flatter your org will be.
The complexity of scopes. If the scopes owned by the team are complex, or have many heavy stakeholders, they may require coordination work, or stakeholder management work, which logically will take time away from the EM. A large project or a heavy stakeholder can be counted as one direct report to acknowledge the time and effort required.
The span of control, communication, and coordination. Jeff Bezos is credited for coming up with the two-pizza team rule, which implied at Amazon that no team should be larger than what two 14″ pizzas can feed, which means 6-10 people. It comes from the observation that as a group size increases, productivity doesn’t grow linearly with the number of people, and it’s often due to the overhead of communication and coordination that’s required. So a factor to keep in mind when deciding how many people should report into an EM is also that you want the communication and coordination to be kept in a sweet spot.
The stability, maturity, and seniority of the team. When teams have been together for a long-time, people tend to have optimized how to work together and you can generally have EMs managing more people due to those optimizations. Note that those situations often come with a lot of “comfort zones” between people which sometimes imply underperformance that’s been hidden under years of working relationships which turned into friendships. A related aspect to consider is the maturity of the direct reports: a team of staff, principal, or very senior devs will usually require less handholding than a team made of medior and junior devs, hence an EM can usually have more direct reports in such situations.
So How Many Direct Reports Per EM?
There is no one-size fit all, it really depends on the overall organization and what the EM role is meant to accomplish with a team and within the organization.
Personally when I think of an engineering manager, I want someone who has a good level of seniority, which means the technical proficiency of a medior or senior engineer, and I also want someone who has the ability to be “hands-on” if required, and by hands-on here I mean leading technical projects, taking technical decisions, and also pushing code regularly, which can be daily or weekly based on the scope and need.
My sweet spot is 4-8 direct reports, with exceptions of 3 direct reports, and 1 or 2 as a hard no. At 8+, the team should probably split into two teams and divide the scope.
How did I come with those numbers? I consider that every direct report will take 2-3 hours per week—I’m a bit sharper on this than Andy Grove—which means that managing six direct reports should take an EM around 2-2.5 days per week. It also means there’s 50-60% of time left in a 5-day work week, and the EM should be able to make good use of that time to lead projects and push code.
My preference is for project leadership to be distributed and delegated among members of the team, because it helps with giving everyone an opportunity to expand their skills and grow their leadership capacity, and also, because it makes more time for the EM to actually be hands-on instead of just managing people and attending meetings.
The expectations for hands-on work reduces conversely to the number of direct reports. With 7-8 direct reports, I expect 10-20% of coding or equivalent technical work, and at 8+, I expect 0-10% of hands-on work.
Embedding the expectation of being hands-on into the role helps with org flexibility. Indeed, when the case occurs that an EM ends up with 1-2 reports and can’t justify to keep on being a manager, because he/she is already hands-on at least part of the time, the option to become hands-on 100% of the time is immediately possible without having to re-skill or change of job, and the EM can simply become an IC. As a side effect, the person is then earmarked for the EM role in case a need opens somewhere else in the organization. Having this option also helps with preventing layoffs, for example in the case that the person didn’t have skills that could fit other roles in the organization, like it would be the case with a non-technical manager, or a technical manager who hasn’t pushed code for years.
Another benefit of the hands-on requirement is that it forces the EM to make decisions with where to spend time effectively: the EM will likely say “no” to processes and meetings that bring limited value, and more likely will delegate and leverage his team by executing through the ICs more, which is good for their personal development, and for the overall resilience of the organization. The one thing I’m usually not okay with letting an EM delegate has to do with the core managerial duties: performance appraisals, 1on1s, and so on, because it’s essentially turning the EM into a manager of managers, which adds hidden layers to an organization and is often not needed.
Join my email list
Isn’t 8 Reports Too Little? I’ve Heard of People Who Had 25!
The most I had to manage in my career so far was 17 people. It lasted for about 1.5 years, and it was at a time when I had to manage all the EMs and also all the POs of an org, and in addition, one team lost their EM and so I had to be the “shadow EM” with all the engineers reporting into me until I found a successor with the correct profile to lead that team.
I saw setups in which a few EMs were given two teams, and went to 12 direct reports in total. The way to do it was to look after each team on a biweekly basis, and to coordinate all the team ceremonies with that cadence. It worked fairly well in each case, also because the individuals who were put into those configurations had shown a high degree of skills and seniority in the role.
So yes, one can go up to 12-15 direct reports with the right setup and the right teams, but I don’t recommend it as a standard setup. It’s better to stick to something more reasonable, so that it enables the EMs to keep pushing code so they stay close to the tech and don’t become disconnected from what’s happening on the ground.
Another more extreme example happened during my time at Booking.com. I was there when a Holacracy-style setup with no team leaders was tried over a 2,500-people organization. All EMs were removed and the Senior Tech Managers above them ended up with 25-35 direct reports each. This came with serious drawbacks: most conflicts on teams were left undetected until they exploded, and performance reviews were done by the Senior Tech Managers with a feeling of being totally removed from any context and mostly relying on second-hand feedback. The relationship between the Senior Tech Managers and the ICs was very superficial and transactional, which made it difficult to build rapport and trust. Everyone was unhappy about it, and the autonomous team trial was reverted after about a year.
You can totally end up with the decision to have up to 12 direct reports per EM as standard, but then you should be aware of the limitations that this will impose on the role itself, and on the relationships that the EM will be able to establish with the direct reports. You would also lose all the benefits around org flexibility mentioned above and which can only come when an EM is able to go back to being an IC when needed.
So What’s A Viable Path To Grow EMs?
At that stage you might be thinking “wait, if the minimum number of reports is 4, then how can you possibly take someone who has been mostly an individual contributor and turn him or her into an EM? Surely we have to make teams with only 2 direct reports to help them start slow!”
My take on this is that growing EMs has more to do with stability of the assigned team rather than number of direct reports. With this in mind, one sure way to grow an IC into an EM is to identify the teams in your org that are stable and led by more experienced EMs, then move one of those experienced EMs to a less stable team, and let the more junior EM come into the stable team so he/she can learn the ropes. If a team is stable and with any decent Product Owner as a partner, 4-6 direct reports should be fine for a newly promoted or on-trial EM.
Now remember, EM is a functional role, which means there needs to be a need for it based on the organizational structure. If there are no structural need for an EM at that point in time, then an IC can still have many opportunities to learn the ropes, for example by getting tasks delegated by the EM within his current team, which for example includes:
- Coaching/mentoring of the more junior ICs.
- Being a representative of the team and of the EM in a meeting with stakeholders.
- Leading some team meetings or processes, delegated by the EM.
- Doing mock 1-on-1s with teammates who is willing to play along.
- etc.
Once the IC has developed enough of the skills around the various tasks required by the role of EM through this type of delegation and support, he might get a shot at leading his own team when a spot opens.
Can Any Tech Role Be An EM?
This again depends on the type of org design and what roles you want for the organization.
A common question I hear is “can architects have their architect role and be EMs at the same time?” and to this, I believe it’s not possible. Don’t get me wrong, someone who comes from an architect role can totally become an EM. What I mean is that someone cannot be expected to be an EM for a team within a scope, and also act as a full-time architect for another scope, even if the scopes are somewhat related.
The important thing to keep in mind is that again, EM is a functional role, meaning that it is tied to a particular need that is created by the org structure. An EM is tied to the scope of a team which should be centered around a product, which is a more vertical focus.
An architect is someone who’s scope should be generally broader than a single team, because by definition the role is needed when multiple teams need to be coordinated via a higher-level view of the situations, which makes it a more horizontal role.
The conflict between the verticality of EM and horizontality of architect make it difficult to combine both scopes in a single person. So if an architect wants to become an EM, my ask to them is that they would have to stop having architecture responsibilities, and instead they should start being more hands-on in order to have their day-to-day activities aligned with the scope and needs of their team.
What next?
I post regularly on tech and managerial topics, join my email list to be notified when something new comes out.
Join my email list
You can also check out some of my other articles on management, for example the following ones:
Be First to Comment