Team size, structure, and cognitive load

The question is always asked as "how many people should be on a team," and that's the wrong variable.

The right one is how much system a group of humans can hold in their heads at once. Size follows from that. A team of four owning one service with a clear boundary is comfortable. A team of eight owning eleven services, three of which they inherited and one of which nobody understands, is overloaded regardless of how many people you add, and adding people makes it worse because now the eleven services are understood in fragments.

Cognitive load is the constraint. Headcount is a lever you pull on it, and it's not even the most effective one.

Why five to eight, and where it comes from

The usual number is five to eight and it's roughly right, for reasons that have nothing to do with software.

Communication paths grow as the square. Five people have ten pairs, ten people have forty-five. Past about eight, the group stops being one conversation and becomes two, and you can watch it happen in a meeting: a side channel forms, then a subgroup that has context the others don't, then a de facto split that nobody has named. Naming it is usually the better move than fighting it.

Below four, you have a fragility problem. One person on holiday and one person sick is fifty percent capacity, and there aren't enough people to hold a real on-call rotation without it becoming somebody's permanent condition.

The rule breaks in two directions worth knowing. A team can run larger, up to ten or eleven, when the work is genuinely parallel and the system is well understood, and you'll see this on mature product surfaces. And a team should run smaller, three or four, when the work is deep and novel and mostly needs to happen in one or two heads anyway.

What you can't do is run large and novel at the same time. That's the configuration that produces four people confidently building incompatible halves of the same thing.

Stream-aligned by default

The default structure I use: stream-aligned teams, each owning a slice of the product that a customer would recognise, with a thin platform layer underneath them.

Stream-aligned means the team can take something from idea to production without needing another team to act. That's the whole property, and it's worth more than any efficiency gained by specialising. A team that has to file a ticket with a different team to complete its own work has a queue in the middle of its value stream, and everything after that queue is subject to somebody else's priorities.

The alternative structures (a team per technology layer, a team per project, a team per component) all fail the same way. Every meaningful piece of customer value crosses three of them, so every meaningful piece of work becomes a coordination problem, and coordination is the most expensive thing an organisation does.

Thin is doing real work in "thin platform layer." More on that in the platform lesson, but the short version: it should be smaller than you want it to be, it should exist because of pain that has recurred, and everything it offers should be optional.

Splitting without splitting the system

The most common way to make things worse is to split a team along headcount lines while leaving the system whole.

You take ten people who own one big service, make two teams of five, and now two teams own one service. You've created shared ownership, which is the state where nobody actually owns anything, plus a coordination tax on every change. Six months later there's a weekly sync meeting whose entire purpose is to be the seam you didn't cut.

Cut the system first. Find the boundary in the domain (not in the code, in the domain) where two parts change for different reasons and on different rhythms. Checkout and catalogue. Billing and onboarding. If you can't find one, the team isn't ready to split, and the honest move is to say so and manage the overload a different way: reduce what they own, or slow the intake.

When you do split, expect a real dip. Two to three months of it. The seam has to become an interface, some things that were a function call become an API, and both teams learn where the boundary actually is by being annoyed by it. That cost is worth paying once and unbearable to pay repeatedly, which is the argument against splitting teams every time headcount changes.

Reducing load without reducing the team

The lever most people never reach for. Before you add anyone, count what the team owns and ask which of it could stop being theirs.

Delete something. There's always something. A service with three users, a feature flag from 2023 that's permanently on, an integration that one customer needed and no longer uses.

Hand something over properly, with the adoption funded rather than announced.

Or, in the most common and most avoidable case, stop generating new surface faster than the team can absorb it. A team that ships three new services a year and never retires one has a cognitive load curve that goes up forever, and no headcount plan survives that.

The one-person team

A single engineer owning a system, alone, is not a small team. It's an unowned system with a delay on it.

They can't take a real holiday. They can't be on call sustainably. There is nobody to review their work with any context, so review becomes rubber-stamping. And when they leave, and they will, everything they knew leaves in the same fortnight and you get to discover what was in their head by finding out what breaks.

It happens by accident, usually. Someone builds a thing, the team around them gets reassigned, and the ownership stays with the person rather than moving to a group. Nobody decides it.

The fix is that ownership is always a team property, even for small systems. Two people minimum, one of whom is genuinely capable of picking it up, with enough regular contact to keep that true. If you can't staff that, the system belongs to a bigger team as one of several things they own, or it gets turned off. Those are the options. A named individual is not one of them.