The standard consulting model is to staff a project with a pyramid: a partner who sold it, a manager who runs it, and a base of junior engineers who do most of the typing. It is an excellent business model. It is a poor way to build a system.
Coordination cost arrives first
A team of three has three pairwise relationships. A team of ten has forty-five. The work of keeping everyone aligned grows quadratically while the useful output grows, at best, linearly — and only if every additional person is genuinely productive on this specific problem, which early on they are not.
For system design specifically, the coordination overhead lands hardest. The decisions that matter most are the ones that need the whole picture held in one head: where the service boundaries go, what the data contract is, which failure modes you are choosing to accept. Those decisions do not parallelise. Splitting them across ten people produces a system with ten people’s worth of local optimisation and nobody’s coherent design.
Seniority is a compression of the search space
An engineer who has built this class of system before is not merely faster. They rule out large regions of the design space immediately, because they have watched those regions fail. That is not a skill you can add by hiring three more people who have not.
The value shows up as things that never happen: the migration that did not need a rollback, the schema that did not need rewriting in month four, the incident that did not occur because somebody recognised the shape of it in a design review.
Absent outcomes are invisible on a status report, which is exactly why the pyramid model survives.
What we do instead
Three to five engineers, all senior, one principal accountable end to end. Everyone holds the whole system in their head. Design decisions get made in a conversation rather than a document review cycle.
It costs more per person and less per outcome. It also means we cannot take on work faster than we can find people who meet the bar — which is a real constraint, and one we would rather have than the alternative.
The honest caveat
This does not scale to every kind of work. Large migrations with genuinely parallel workstreams, long-running maintenance, or high-volume mechanical change are all better served by a bigger team.
The model fits where the hard part is deciding what to build rather than typing it. That happens to be most of the work we are called in for — but it is worth being clear that it is a choice about fit, not a claim that small teams are universally better.
