Three People Deliver What a Department Used To
Picture a software project as it typically looked five years ago. A new customer portal needs building: a product owner, two backend engineers, a frontend developer, a QA tester, someone for DevOps, a designer – and over the top of it all a team lead to coordinate the whole thing. Eight people, maybe nine. Timeline: the best part of a year to a first usable version.
The same portal gets built today by a team of two or three senior generalists with modern AI tooling – and it ships sooner. Not slightly sooner. Noticeably sooner.
This sounds like the usual tool hype, but it's something different. The interesting shift isn't that each individual has become more productive. It's that the optimal team size has moved downward. And a smaller team isn't merely cheaper – it's faster for structural reasons. That's what makes the whole thing counter-intuitive: fewer people here isn't the compromise, it's the lever.
The Old Logic: More Scope, More Heads, More Friction
For decades, building software followed a simple equation. More scope demanded more hands. More hands demanded specialisation, because no single person could cover the full breadth. Specialisation demanded coordination – handoffs between backend and frontend, between development and QA, between design and implementation. And coordination demanded people whose job was the coordination itself: managers, scrum masters, project leads.
The treacherous part: the effort of coordinating doesn't grow linearly with team size, but roughly with its square. Three people means three communication channels. Ten people means forty-five. Every extra person has to be brought along by every other – in meetings, in alignment sessions, in documents that only exist because the knowledge no longer fits in a single head.
This is precisely what Brooks's Law describes, that old piece of software wisdom: adding people to a late project makes it later. The new person doesn't produce value straight away; they first produce a need for coordination. A large team spends an alarming share of its energy not building the product, but synchronising with itself.
None of this was a failure of bad organisation. It was the rational response to a real problem: there was simply too much work for too few heads, and some of that work demanded specialist knowledge you couldn't bundle into one person. Large teams were the price of large scope.
What AI Takes Out of the Equation
Here's the thing: a huge share of what made teams large was never the demanding, thinking work. It was the grunt work – the mass of tasks that required hands but barely any genius. And that mass is exactly what AI is now dissolving.
Look at what actually eats time in a software project:
- Boilerplate and scaffolding – the same old skeleton of endpoints, models, and forms that every project needs from scratch.
- Glue code – the wiring between systems, database access, API integrations, format conversions.
- Migrations and plumbing – moving data, setting up pipelines, cabling the infrastructure together.
- First drafts of everything – the first version of a module, a test, a piece of documentation, a design you then merely refine.
- Research and ops toil – reading docs, looking up error messages, the recurring maintenance odds and ends.
This was never the work you hired the sharpest minds for. It was the work that absorbed heads – the justification for why you needed two extra junior developers, half a QA person, someone whose only job was the build pipeline. AI now handles exactly this layer reliably. It writes the scaffold, the glue code, the first test case, the first draft of the docs – and it does it in minutes.
With that, the reach of a single person shifts dramatically. A senior generalist with AI support now covers roles that used to demand several specialists: they build the backend, wire up the frontend, write the migration, set up the deployment – not because they're world-class at all of it, but because the AI supplies the depth where their own knowledge is shallow. The person stays the architect and the judgement call. The grunt work beneath them is no longer their bottleneck.
Why Fewer People Is Itself a Multiplier
Now comes the part that's easy to miss. If AI takes over the grunt work, you might assume the large team simply becomes more productive. But it doesn't, not to the same degree – and the reason is coordination.
A three-person team has three communication channels and a shared context that fits comfortably in two or three heads. Nobody has to write a concept down so another department can understand it; you turn around and say it. A decision that costs half a sprint in a large team – alignment, ticket, review, sign-off – gets made in the small team in a ten-minute conversation. The team that doesn't have to coordinate gains speed before it writes a single line.
Two effects work together here, and they compound:
- AI lowers the work that demanded heads. The scope three people can handle climbs steeply.
- Fewer heads lower the coordination that grew with the square. The friction that used to swallow half the energy nearly vanishes.
The result isn't "the small team achieves a bit less, but cheaper". The result is often "the small team achieves more – faster and cheaper". Productivity per person rises through AI; team productivity rises on top of that, because the quadratic coordination overhead falls away. That combination is what's new.
The Shape of the New Team
So what does the team that plays this advantage look like? It has a clear profile, and it's almost the opposite of what many organisations spent years optimising for.
It's small – two to five people, not twenty. It's senior – the people have built enough to know what a bad idea is before it costs three weeks. It's generalist – everyone can do most of it, nobody is pinned to a narrow strip. It's high-trust – decisions are made locally, with no approval cascade. And it's AI-leveraged – the tools aren't a nice-to-have, they're a fixed part of how the work happens.
The most important shift hides inside an old term. The "10x engineer", the lone hero who delivers ten times as much, was always half myth – and where it did exist, it was a risk, because everything hung on one person. The new equivalent isn't the individual. It's the small team as a unit, delivering together what a whole old department once did, without the friction. The lever has moved from the person to the team – and that's more robust, because several heads share the context.
At nh labs, we are exactly this kind of team. This isn't theory here, it's our daily reality: a small, senior, generalist-staffed team that uses AI tooling to tackle projects a traditional vendor would have thrown a many-headed crew at. And it ties directly into our Time-to-Software thinking: the fastest path from idea to running software runs not through more people, but through less friction between them.
Where This Picture Breaks Down
This is where you have to be honest, or you'll draw the wrong lesson – namely "fire half of them". That would be a thinking error. Small teams aren't universally superior; they're superior in a particular field. There are clear cases where the old logic still holds.
- Genuinely large surfaces. Some systems are simply enormous – a core banking system, a nationwide insurance platform, a regulated medical-device suite. Where the sheer surface area of the problem is vast and every part has to be tended at once, it won't fold into three heads, no matter how good the tooling.
- Deep specialist expertise. There's knowledge AI doesn't replace: cryptography that has to be correct, real-time control systems with hard guarantees, domains like actuarial science or clinical trials, where an error costs lives or millions. Here, no amount of breadth substitutes for the depth of a real specialist.
- Where scaling the org is the point. Sometimes size itself is the goal – politically, contractually, by regulation. A government body, a corporation with a hundred stakeholders, a project that demands the representation of many parties, isn't carried by three people, and that isn't an efficiency problem.
- The junior question. You can't run on seniors forever. Seniors come from juniors who were allowed to learn on real problems for years. A model that uses only finished generalists is burning its own future. Anyone who trains people deliberately builds in inefficiency – and that's an investment, not waste.
And a final, sober point: small teams concentrate the bus-factor risk. If all the knowledge sits in two heads and one of them drops out, a great deal grinds to a halt. What starts as a strength – context in few heads – is at the same time the weak spot. You counter it with documentation, clean code, and deliberately shared knowledge, but you should never talk it away.
What Leaders Should Actually Do
Anyone who takes this shift seriously stops steering by headcount. A few concrete consequences:
- Hire for seniority and range, not for volume. A generalist who covers three roles is worth more than three specialists who have to coordinate with each other. Better a few very good people than many average ones.
- Cut the organisation into small, autonomous teams. Two to five people who own one thing end to end, with no approval cascade. Autonomy here isn't a culture perk, it's the speed mechanism itself.
- Measure output, not headcount. The question isn't "how many people are working on it", but "what shipped last week". Headcount as a measure of success rewards exactly the wrong thing.
- Invest the saved headcount budget in tooling and in the few great people. The money that doesn't go into five extra roles belongs in first-class tools, in AI licences without penny-pinching – and in paying the people who carry the small team. Equipping a small team well is cheaper than equipping a large one badly.
The rule of thumb behind all this is simple: as long as the problem fits in a few heads, the small team wins. Only when the surface of the problem, or the depth required, genuinely outgrows that do you need more. Most projects underestimate how much now fits in a few heads.
Conclusion
The old equation – more scope demands more people – no longer holds across the board. AI has dissolved the grunt work that justified large teams in the first place, and small teams win on top of that exactly where it matters most: on the friction that grew with the square of headcount. Together, those two effects move the optimal team size noticeably down and the speed noticeably up.
This doesn't mean stop hiring. It means hire differently: for seniority and range over volume, for small autonomous units over layered hierarchies, for output over headcount. The honest exceptions remain – enormous systems, deep specialist domains, the need to train juniors, the bus-factor risk. But outside those exceptions, the maths tips in favour of the small, senior, AI-leveraged team.
We live this every day ourselves. The two-person team that replaces a department isn't a vision of the future – it's the way good software is being built right now. Grasp that early, and you build faster while spending less. Both at once.