A proposal arrives with twelve names on it and another with three. The first looks like more capability for the money, and on some work it genuinely is. On other work the twelve-person team will deliver less, later, and with more defects than the three-person team, and the reason is structural rather than a comment on anyone's ability.
We are a small senior team, so the conclusion of this page is predictable. The useful part is the mechanism, because it also tells you when to hire the larger team, and that recommendation is one we make regularly.
Coordination cost is quadratic
The number of possible communication paths in a team of n people is n(n-1)/2. Three people have three. Six have fifteen. Twelve have sixty-six. Nobody maintains sixty-six live relationships, so a team that size stops communicating directly and starts communicating through structure: standups, tickets, a business analyst, a delivery lead, a written process for decisions that a small team would settle in a hallway.
That structure is not waste. It is the necessary response to size. But it is funded out of the same budget as delivery, and it changes what the team is capable of. Decisions get made further from the code. Context travels through intermediaries and loses its exceptions. The person implementing the invoicing rule is now two conversations away from the person who knows why the rule has an exception for one customer.
What seniority actually buys
The value of a senior engineer is routinely described as productivity, which invites the reasonable objection that nobody writes code ten times faster. They do not. The advantage is elsewhere and it is larger.
- Mistakes not made: a data model that survives the second and third requirement, chosen because someone has watched two of them fail
- Questions asked early: noticing in week one that two systems disagree about which customer record is authoritative, rather than in month four
- Less specification required: the ability to sit with a dispatcher for a day and derive the requirement instead of waiting for it to be written
- Scope removed: recognizing which third of the requested functionality nobody will use, and saying so before it is built
- Failure anticipated: building the integration to handle the partial failure that will occur, because it always occurs
None of these appear in a velocity report, and most of them are invisible in the moment because they manifest as things that did not happen. That is why they are systematically underpriced by a procurement process comparing rates and headcount.
When the large team is the right answer
This is not an argument that small teams are always better. It is an argument that the work should choose the shape. Large teams are correct, and small ones are actively wrong, in a well-defined set of situations.
- The work genuinely decomposes into independent pieces with clear interfaces between them
- The specification exists, is good, and is stable enough that parallel work will not collide
- Volume is the constraint: hundreds of screens, a large migration of similar records, broad test coverage on known behaviour
- The domain is well understood and already written down, so context does not have to be rediscovered
- You need sustained capacity across several products at once, with an in-house lead directing it
If your work looks like that, a larger team at a lower blended rate is the better commercial decision, and a small senior team is an expensive way to buy throughput you could get more cheaply. We turn down work of this shape regularly, because we would be a poor use of the budget.
It is also worth saying that the two shapes are not mutually exclusive over the life of a system. A great deal of software is best served by a small team while the hard decisions are being made and the domain is still being learned, then by a larger one once the architecture is settled and the remaining work is largely volume. Getting the sequence backwards is the expensive version: putting a large team on undefined work produces a lot of code that has to be unpicked, and putting a small team on a mountain of specified screens simply takes longer than it needed to.
When it is the wrong answer
The mismatch appears when the work is sequential and ambiguous. Some problems cannot be parallelized because each decision constrains the next. You cannot assign the data model to four people and have them converge. You cannot discover an undocumented business rule twice as fast by having two people ask.
On that kind of work, extra headcount does not increase throughput; it increases the number of people waiting for a decision, and the coordination required to keep them occupied produces work that has to be reversed once the decision is made. This is the origin of a familiar pattern: a large team, a great deal of visible activity, an impressive burndown chart, and a system that does not yet do the one thing the business needed.
| Characteristic of the work | Small senior team | Larger team at a lower rate |
|---|---|---|
| Requirements already written and stable | Overqualified for it | Strong fit |
| Requirements have to be discovered from operations | Strong fit | Poor fit; discovery does not parallelize |
| Work decomposes into independent pieces | Capacity-limited | Strong fit |
| Each decision constrains the next | Strong fit | Adds waiting, not throughput |
| Volume of similar, well-understood work | Expensive way to buy it | Strong fit |
| A wrong architectural call is expensive to reverse | Strong fit | Depends entirely on who is leading |
| You have an in-house technical lead with daily time | Useful but not required | Effectively required |
How to judge a proposal
- 1
Ignore headcount. It is an input the vendor chose, not an outcome you are buying.
- 2
Ask what one defined increment costs in total, delivered to stated acceptance criteria.
- 3
Ask who will be doing the analysis, and whether those people will also be writing the code.
- 4
Ask how many people sit between you and the person implementing your business rules.
- 5
Ask what happens to the price if the increment turns out to be harder than estimated.
A team that cannot answer the second question without converting it into hours multiplied by a rate is telling you they do not know what the increment costs either. That is not disqualifying on well-specified work. It is disqualifying when the specification is the thing you were hoping to buy.
Common questions
- Is a small team a risk if someone leaves?
- It is a real risk and it should be managed explicitly rather than dismissed. The defense is not headcount, it is that domain knowledge lives in the repository as tests, written decisions, and documentation rather than in a person. Ask any vendor of any size where a business rule discovered in conversation ends up. A large team with everything in people's heads is more fragile than a small one with everything written down.
- Can three people really replace twelve?
- On the right work, yes, and on the wrong work, no. Where the constraint is decisions, ambiguity, and sequence, a small senior team frequently delivers more because it spends its time on the work rather than on coordinating the work. Where the constraint is volume of well-specified tasks, three people are simply three people and you should hire the larger team.
- How do we scale if the engagement succeeds?
- Usually by splitting the work rather than growing the team. Once discovery is done and the architecture is settled, large portions become well-specified implementation, which is exactly the shape that a larger or lower-cost team handles well. Sequencing the two models is more effective than trying to make one do the whole job.
- Does this mean junior engineers should not be on the project?
- No. It means the ratio matters and the composition should follow the work. Junior engineers do well on implementation with a clear interface and close review, and that is how people become senior. The failure is a team whose ratio was chosen to hit a blended rate rather than to match what the project requires.
- How do we compare a three-person quote to a twelve-person quote?
- Convert both to cost per delivered increment against identical acceptance criteria, then add the internal hours each will require from your staff. Headcount and blended rate are inputs; the total cost of a working outcome is what you are actually buying, and it is the only figure that supports a decision.