tags: #publish links: [[Management]], [[Teams and Teamwork]], [[Organisation Design]] created: 2021-09-18 Sat --- # Factors affecting viable team size https://www.patkua.com/blog/how-many-people-can-someone-lead/ https://randsinrepose.com/archives/seven-plus-or-minus-three/ https://review.firstround.com/how-to-size-and-assess-teams-from-an-eng-lead-at-stripe-uber-and-digg Related: [[Dunbar's Number and the Monkeysphere]], [[Inverse Conway Maneuver]], [[Org design isn't copy-pastable between different organisations]] IMO there is no one answer to "the best" team size. It is situation- and role-dependent. As well as thinking about what works for the team members, we should design the team size to suit the depth of involvement we need the manager to have, based on: - how much support they have from other roles around them - how much support the people in their team need - what the base manager-role KTLO is like in this organisation - e.g. bureaucracy; sophistication of people management expectations in this organisation It depends what kind of work your team is doing, how many things are happening in parallel, and how much the organisation's processes cost you just to stay afloat day to day. It depends what we actually want the manager to cover in this team! **Factors:** *What are the manager's job responsibilities? What are the responsibilities of the others? How independent are the team members? What about within-group communication bandwidth?* Some good framing here, and how the supporting job roles around the manager (like product manager/owner, program or project manager, senior and principal engineers) affect this: [https://www.patkua.com/blog/how-many-people-can-someone-lead/](https://www.patkua.com/blog/how-many-people-can-someone-lead/) My own experience is that the manager role is quite different with a 4-5 people team vs an 8-10 person team (or 15, which was my peak number of individual-contributor reports so far). [Here's another article describing how these different-sized groups behave](http://maltzj.com/posts/notable-change-points-in-team-sizes). With a small team, e.g. 5, you have time to pay attention to individual tasks people are doing, details of projects, helping make sure your senior tech folks are properly playing a role of accountability for tech design, etc. With a small enough team you theoretically may have time to get involved technically, if that makes sense. With a larger team, e.g. 10+ people, most of these are no longer possible. You're necessarily more of a resource planner than a task-level coach, or at least you have to be _way_ more selective and rely on delegation structures a lot more. You won't be fully across your project technical details and task breakdown any more. You won't have time to read everything. You certainly won't be coding or reviewing code, unless you are drastically neglecting other areas such as 1-1s and people management, planning, or coordination with other parts of the org. **How experienced are your engineers?** With a very junior team, you need to devote much more time to coaching and supporting them, and will need to be sufficiently close to the execution of their work to make sure they're getting the help they need, whether from you or other engineers. With a team of seniors and principals, you will actively harm the team if you are involved at that level - you can and should give them much more space, set goals but be hands-off on their execution. **Which supporting roles are present?** If you have a product manager that's doing the planning and prioritisation for you, or a scrum lead to drive delivery execution, great, you have bandwidth for other things. If not, you'll struggle to do that as well as run a team of 10 juniors. **How bureaucratic is the organisation?** If a manager has a lot of administrative, reporting or funding-request theatre to do, they'll need a smaller team to keep up with everything. **What people management and coaching do you need to do?** Does your organisation expect you to do weekly 1-1s, or fortnightly, or less? Are there formal expectations for quarterly or annual performance review or growth planning processes? Do you need to coach every engineer on their day-to-day work? Can any of this be delegated to others, e.g. squad leads within a large team? After we've considered all of that, _then_ we can look at things like cognitive load, size of problem domain and surface area, rate of technical change, and the communication bandwidth within the team, which are also relevant factors.