I had someone ask this recently, and as with any software engineering answer, I found myself saying "it depends". But, I have some opinions on this, of course. I'd love to hear from others, as none of what I share below is 'right', just 'my own mileage', and so other thoughts really would be welcome. This post is just a small opinion piece, and doesn't dig into any of the science behind group dynamics (e.g. Dunbar's number, etc.).
๐๐ก๐๐ญ factors ๐ข๐ฆ๐ฉ๐๐๐ญ team size descisions?
I think the factors are primarily Org culture. For example:
- Are your Engineering Managers hands on, or is there a strong emphasis put on leadership?
- How heavily valued are things like 1:1s, growth conversations etc.
- How much of the EMs time is spent on other aspects of the role.
Like the quality, speed, scope triangle, you canโt have both hands on ๐๐ง๐ effective leadership easily and will routinely see conflict.
It also depends upon team domain(s), etc. โ e.g. a product team focusing on Payments is a narrow domain, so cognitive load on the EM is likely to be reduced, and they may be able to take on a larger team. A platform team that spans all of cloud has a huge set of domains, and the EM is likely to be significantly more cognitively loaded.
๐๐ข๐๐๐๐ซ๐๐ง๐ญ ๐๐๐๐ฆ ๐๐๐ญ๐ญ๐๐ซ๐ง๐ฌ
Iโve shared this โteam shapes and hiring patternsโ in the past.
- Many teams focus on the traditional pyramid (many early career, some mid, few senior), which can work well in a mature product environment where there isnโt significant need for innovation or pace.
- In many startups, where pace is higher, the barrel shape can work well, as you have more of your senior group able to innovate and help delivery at pace.
- In really complex domains (platform teams are a great example), I tend to favour the inverted pyramid, as I find that you cannot routinely bring earlier career people along on the journey without slowing down. The domains in platform teams are huge, and so benefit from more senior employees as the โcoreโ of what is in there.
๐๐จ, ๐ฐ๐ก๐๐ญ ๐๐ซ๐ ๐ญ๐ก๐ ๐ง๐ฎ๐ฆ๐๐๐ซ๐ฌ?
My typical ballpark is โ6-8โ:
- Any less than 6, and a team will struggle to remain effective and deliver at pace when there are absences (holidays, sickness, etc)
- As you get to 8 and beyond, you may start to be compromising the quality of what you do with each person, especially if the rest of your role is busy
- Any more than 10, and even the best manager is going to be stretched thin, and some of their other work could easily become more 'tyranny of the urgent' as they will find themselves with far less time.
๐๐ก๐ฒ ๐๐ซ๐ ๐ญ๐ก๐จ๐ฌ๐ ๐ญ๐ก๐ ๐ง๐ฎ๐ฆ๐๐๐ซ๐ฌ?
I typically ballpark ~2hrs per week for each direct report. That is, ~1hr for 1:1, and then time around that โ thinking time, interacting on a problem that canโt wait for 1:1 etc. โ thatโs not to say I only spend 2hrs per week with each direct, but I earmark this time as dedicated time for that person.
Early stage ICs will benefit most from maximised time with a manager, a person whoโs a strong senior may need less, but Iโve never been in a situation where an IC or a Direct has needed less than 1hr direct focus of mine per week.
If the team are co-located, this can alter the figures slightly โ the regular presence in the office each day can afford things like 1:1s every 2 weeks instead of 1, more informal chats, and potentially up those 6-8 numbers to be 9-12 depending on competency of the leader.
So, how are you approaching team size, and how's it working for you?