Small Teams Win
The best software teams are getting smaller, not bigger. Why smaller software teams might be the better choice, especially in the age of AI. When a business is doing well and growing, hiring more engineers feels like the obvious next step. More customers, more features, more things to maintain. Surely, we need more people to handle all of that. But do we?
We rarely stop to think about what we’re actually adding to the team. Every new engineer brings additional capacity, knowledge and experience. That’s great. But they also bring something we tend to underestimate: more communication, more coordination and more organizational complexity.
At some point, adding another engineer might not make your team much faster. In certain situations, it can even slow things down. So, before hiring another engineer, perhaps we should ask a different question: Can we make our existing team more productive instead?
The hidden cost of growing a team
Having more engineers in an organization gives us the impression that we can handle more tasks. And we’re not entirely wrong about that. More people generally means more available engineering capacity. The problem is that software development rarely happens in isolation.
Most tasks require some clarification, technical discussions, reviews, or input from other engineers. Developers need to understand the product, follow company standards, make architectural decisions and coordinate changes with people working on related parts of the system. None of this is necessarily bad. Collaboration is how we build good software. The problem appears when coordinating the work starts taking more time than doing the work itself.
As teams grow, the number of potential communication relationships grows even faster. There’s a simple mathematical formula to illustrate this:
Connections = n × (n − 1) / 2
Where n is the number of people on the team. Let’s look at what happens when we keep adding engineers.
Every dotted line is a conversation that might have to happen.
A team of 5 people has 10 possible communication relationships. Increase the team to 10 people, and suddenly there are 45. With 20 people, that number reaches 190. Of course, these are theoretical connections. Not everyone needs to communicate with everyone else, and each relationship doesn’t automatically mean additional meetings or wasted time. But the graph illustrates something important: team size grows linearly, while the number of possible relationships grows quadratically.
Each additional connection creates another opportunity for clarification, disagreement, synchronization or waiting for someone else’s decision. More engineers may also mean more pull requests to review, more overlapping changes, longer planning sessions and greater difficulty keeping everyone informed. And then there’s onboarding. New engineers need time to understand the codebase, the architecture, the product and the way the organization works. Existing engineers need to help them get there, often interrupting their own work.
These costs aren’t necessarily visible on a project board or in a sprint report, but they’re real. The more people you add, the more important it becomes to manage these interactions. And the more time you spend managing them, the less time is left for actually building software. This is one of the reasons adding more engineers doesn’t always translate into proportional gains in productivity.
The difference between one and two engineers
There’s one interesting detail that the graph doesn’t fully explain: the difference between working alone and working with just one other person.
When you’re building software alone, you make most decisions yourself. You think about a problem, consider different solutions, choose one and move forward. You don’t need to explain every thought to someone else, schedule a meeting to agree on an approach or convince another engineer that your implementation makes sense. You simply make the decision.
Introduce a second engineer, and something fundamental changes. You now have another person with their own experience, opinions and understanding of the problem. Suddenly, you may need to explain your thinking, listen to feedback, discuss alternatives, disagree and sometimes reconsider the entire approach. All of that takes time.
But there’s another side to this. The second engineer can challenge your assumptions, catch mistakes, contribute knowledge you don’t have and help you make better decisions. They can also keep the project moving when you’re unavailable. Working alone reduces internal communication overhead, but it doesn’t automatically make you more productive. Sometimes, a five-minute conversation saves hours of building the wrong thing.
That’s why I wouldn’t argue that one engineer is better than two. What I find interesting is that every additional person changes how the team works, not just how much work it can handle. A team of two isn’t simply twice the capacity of one engineer. It’s a different way of building software, with new advantages and new costs.
So what’s the best team size?
I don’t think there’s one simple answer. It depends on what you’re building, the complexity of the product, the technology, the experience of your engineers and the culture of your organization. A small startup building an MVP has very different needs from a company operating critical financial infrastructure.
Still, we have some useful examples from companies that have spent years thinking about this problem. One of the most popular approaches is Amazon’s two-pizza team philosophy. The idea, associated with Jeff Bezos, is simple: a team should be small enough that you can feed everyone with two pizzas. Amazon describes these teams as typically having around 5–10 people.
It’s a catchy rule, but the real principle goes far beyond pizza. In June 2026, Werner Vogels, Amazon’s CTO, revisited this idea in his article A Return to Two-Pizza Culture. He described how Amazon wanted teams to remain small enough that everyone understood what others were working on, without constantly requiring meetings. Teams were expected to own their products and make decisions without unnecessary bureaucracy.
One idea from his article particularly caught my attention: making a reversible decision quickly is often better than spending too much time trying to make the perfect decision. I think this captures something important about smaller teams. It’s not just about reducing communication overhead. It’s about allowing people to make decisions and take responsibility without needing to involve half the organization.
Amazon isn’t the only company working this way. In its Linear Method, Linear recommends that early-stage projects be small enough for teams of just 1–3 people to complete them in 1–3 weeks. The goal is to reduce management overhead, ship frequently and collect feedback quickly. Basecamp follows a similar philosophy. In Shape Up, it describes project teams consisting of one designer working with one or two programmers.
Notice the common pattern. These companies don’t simply try to make every team smaller. They also reduce the scope of work, give people more ownership and allow teams to make decisions independently. A small team without autonomy is just a small team waiting for permission. And there’s little benefit in making a team smaller if everyone still needs approval from five different departments before shipping a feature.
Small teams need clear ownership
This brings us to something that I think is even more important than the number of engineers: dependencies.
Imagine splitting a team of 15 engineers into three teams of five. On paper, you’ve reduced the number of possible internal communication relationships dramatically. Each team now has just 10 possible connections instead of 105 in the original team. Sounds great, right?
Not necessarily. If these three teams are constantly changing the same code, depending on each other’s work and waiting for cross-team approvals, you haven’t solved the coordination problem. You’ve just moved it somewhere else.
For small teams to work well, they need clear responsibilities and enough independence to deliver their work from beginning to end. That doesn’t mean every team needs its own microservices, databases and infrastructure. A well-structured monolith can support independent teams, too. The important thing is to make dependencies manageable.
There’s an interesting case study published on Martin Fowler’s website that explores the relationship between architecture and team organization. It shows how aligning team responsibilities with a modular architecture, together with improvements to developer experience, helped an organization improve its delivery performance.
I think this is where many organizations get things wrong. They try to fix slow delivery by hiring more engineers, introducing another management layer or reorganizing teams. But the actual bottleneck might be the architecture, unclear ownership, too many approvals or simply too much work in progress. Adding people won’t necessarily fix any of those problems.
AI is changing the rules of the game
Everything I’ve described so far isn’t particularly new. We’ve known about communication overhead, small teams and organizational complexity for decades. But AI makes this discussion much more interesting.
For a long time, software organizations grew by hiring more specialists. Frontend engineers, backend engineers, DevOps specialists, QA engineers and people responsible for different parts of the development process. There were good reasons for that. Each area required specific knowledge, and there was only so much one person could reasonably understand and deliver.
AI is starting to change those boundaries. An experienced engineer can now use AI tools to explore an unfamiliar codebase, generate a first implementation, write tests, investigate errors, prepare infrastructure configuration or prototype an interface. Things that previously required switching between specialists, or spending significant time learning unfamiliar tools, can sometimes be completed by one engineer working with AI.
Consider an experienced backend engineer who needs to build a frontend for an internal tool. A few years ago, the reasonable solution might have been to involve a frontend specialist. Today, that engineer can use an AI coding agent to build an initial interface, iterate on the design and implement much of the functionality independently.
Does that suddenly make them an experienced frontend engineer? Of course not. But they may no longer need dedicated frontend support for every task. The same applies in the opposite direction, and across many other areas of software development.
AI doesn’t eliminate the need for expertise. It allows experienced engineers to work beyond their original areas of expertise.
That’s a significant difference. It means that a small group of experienced engineers may be able to take responsibility for a much larger part of the software development process than before. Instead of passing work between multiple specialists, they can move through more of the process themselves. This can mean fewer handoffs, less waiting, faster feedback and potentially much smaller teams.
There is a catch, though. Writing code faster doesn’t automatically mean delivering better software faster. Generated code still needs to be understood, tested, secured and maintained. AI can also introduce mistakes that take time to discover and fix.
Google’s 2025 DORA research makes an interesting observation: AI tends to amplify an organization’s existing strengths and weaknesses. A team with good engineering practices, clear ownership and efficient delivery processes may benefit significantly. A team struggling with unclear requirements, poor architecture and slow reviews may simply generate more code that gets stuck in the same bottlenecks.
Technology is making implementation easier, but the difficult parts of software engineering haven’t disappeared. You still need to understand the problem, make decisions, consider trade-offs and take responsibility for what reaches production. And that’s exactly where experienced engineers matter.
Before you hire, find the actual bottleneck
I don’t think organizations should stop hiring engineers. There are plenty of situations where adding more people is exactly the right decision. A team might be handling more independent work than it can reasonably deliver. It might need expertise that nobody currently has. Or the operational responsibility might simply be too large for a small group to handle safely.
But before opening another position, I’d ask a few questions:
- Are we actually limited by engineering capacity, or are engineers spending too much time waiting for decisions, clarifications and approvals?
- Can we reduce the scope of our projects and ship smaller changes more frequently?
- Can we simplify the architecture, automate repetitive work or eliminate unnecessary dependencies?
- Are we making good use of AI tools to improve the productivity of our existing engineers?
- If we hire another person, what additional responsibility or independent work will they be able to own?
Sometimes the answer will be to hire. Sometimes it will be to split a large team into smaller, more independent groups. And sometimes the best solution will be to change how the existing team works. I think the last option deserves far more attention than it usually gets.
Smaller, not necessarily fewer
There’s an important distinction between building smaller teams and building a smaller engineering organization. A company might still need hundreds or thousands of engineers to build and operate its products. That doesn’t mean those engineers should work in large, tightly connected teams. The goal should be to organize people into small groups that can deliver meaningful results with as little unnecessary coordination as possible.
And with AI increasing what individual engineers can accomplish, I expect we’ll see more teams taking responsibility for larger parts of products with fewer people. We may even start questioning some of the specialist boundaries that have shaped software organizations for years. But the objective shouldn’t be to replace engineers with AI or reduce headcount at all costs. It should be to build more effective teams.
Best teams deliver value
The best engineering team isn’t necessarily the one with the most engineers. It’s the one that can consistently deliver valuable software without getting in its own way.
So before you hire another engineer, look at what your current team is spending its time on. You might discover that what you need isn’t another engineer. It’s fewer things slowing down the engineers you already have.