The case for squads of four

The standard response to a slipping roadmap is more engineers. It is intuitive, it is easy to approve, and past a fairly small number it does very little.

Where the time actually goes

On a team of four, most communication is direct and most decisions happen in the moment. On a team of twelve, an increasing share of the day is spent keeping twelve people’s mental models aligned: standups that inform rather than coordinate, documents written mainly to prevent duplicated work, review queues that add a day of latency to every change.

None of that is waste exactly. It is the cost of coordination, and it grows faster than the headcount does.

What we hold to

Four engineers per squad, all senior enough to own a slice end to end. One product owner. One designer, shared across two squads.

The constraint is deliberate. A squad of four can hold the whole system in its collective head, which means fewer documents, fewer meetings, and far fewer decisions that need escalating.

The trade we accept

Small squads are less resilient. One person on leave is a quarter of capacity. We handle that with genuine overlap: no single-owner areas, pairing on anything unfamiliar, and documentation written for the person covering rather than for an audit.

We also cannot brute-force a deadline. When a date is immovable and the scope will not fit, the answer is to cut scope, and we say so. Clients occasionally dislike hearing it. They dislike a rushed system considerably more, three months later.

Why seniority is the load-bearing part

The model only works because every engineer can operate without supervision. A squad of four juniors is not a small senior squad; it is a large team missing its coordination layer, which is the worst of both.

That makes hiring the constraint on how fast we can grow, and we have decided to be at peace with it.