Writing

How Big Should a Dev Team Actually Be?

The answer is smaller than you think, and the reason is coordination cost.

Every founder who has scaled an engineering org has had the same thought. We doubled the team and output did not double. Something is broken. Hire harder. Hire faster.

The thing that broke is not the hiring funnel. It is the shape of the team. Every new person you add to a group creates new communication edges. Four people have six. Eight people have twenty-eight. Ten people is already a ratio where most of the day is reconciling what everyone else is doing.

This is not a new argument. Fred Brooks made it in 1975 in The Mythical Man-Month. Adding people to a late project makes it later. The rest of his observations have aged just as well. Read it.

Good teams above a certain size are not really one team. They are a federation of small teams that do not need to talk to each other very often. That structural decision matters more than any individual hire, and it is almost never what the leadership conversation is about.

Start with fewer people than you think you need. Three or four people with focus and agency will out-deliver a team of ten that has to coordinate every decision. Small teams move faster because they are small. Coordination overhead is the enemy, and fewer people means less of it.