> at 15 engineers, it is very doable for a single person to keep track of everyone's work and ensure alignment.

All my past experience disagrees. Sure you have 15 engineers, but you're supporting a business of 150 people. This is a pretty common ratio.

The noise gets very loud at that scale and it becomes almost impossible for self-managed engineers to make forward progress. At the very least you need super clearly defined ownership boundaries. That means business process and workstream ownership, not code ownership.

My rule of thumb is that management complexity is given by #direct reports x #project, where project is defined as a set of stakeholders (be it PM, etc. depending on business).

Concretely, managing 12 ICs on a well defined platform team w/ a single PM is much easier than managing 6 people working across 6 businesses, as is more common when managing a team of data scientists.

+111111

I don't believe a manager can be effective at 15 direct reports. I think it's possible to keep things afloat, but split that team in half and hire another manager and you'll be in a much better position.

What usually happens here is that your most senior members of the team are picking up management responsibilities instead of doing IC ones. By all means they should contribute to mentorship, direction, culture, etc. but there is way too much going on to have a deep understanding of those 15 engineers.

The only times I think this work is when the leader sucks, so swamping them with reports means they have a more difficult time micro-managing. But they're probably getting in the way in some other fashion.

it's worth reading Mythical Man Month WRT team composition. not because Brooks says anything new about the subject, but to get perspective on how long people have been trying to find a good idea for how to structure teams.

Yup, 15 is just too many. I think that 10 is already pushing it, depending on how many projects are going on at the same time.