Smaller Teams Aren't the Strategy

There's a widely shared belief that AI is going to fundamentally change the structure of software engineering teams. Instead of the teams we have today, we'll have smaller groups of engineers managing fleets of AI agents, producing significantly more software with far fewer people.

I actually do think there's a good chance some version of that happens. AI is already changing how we build software, and it would be surprising if team structures remained largely unchanged as those capabilities mature. But I think we're getting ahead of ourselves by treating smaller teams as the goal rather than considering what would actually make smaller teams effective.

In my experience, writing code is rarely ever the primary constraint on delivering software. Engineers spend enormous amounts of time understanding requirements, coordinating across systems, resolving dependencies, making architectural decisions, navigating governance, and managing things they've already built. AI can help with much of that, but increasing the speed at which we deliver code absolutely will not make the rest of the organization move faster.

And that's where I think the conversation around smaller teams needs to be.

Individual Productivity Isn't Organizational Throughput

So now an engineer or an agent can implement a feature in two hours instead of two days. Cool, but what happens when that feature requires coordination across three teams, an architectural decision that nobody owns, changes to a shared platform, and a deployment process that depends on manual approvals?

The actual implementation might be faster, but the overall delivery process hasn't necessarily improved much. In fact, if every engineer experiences that same increase in implementation speed, we may end up putting considerably more pressure on the very dependencies and processes that were already slowing us down.

This is what I think gets regularly overlooked in conversations about AI productivity. We often measure improvements at the individual level and assume those gains will translate proportionally across the org. But engineering organizations are often systems of distributed yet interconnected teams, platforms, processes, and decisions. Improving one part of that system doesn't always improve the whole thing, especially when the other constraints remain unchanged.

That certainly doesn't diminish the value of AI-amplified development. It's an extraordinary capability, and it is only going to continue improving. But if our ambition is to redesign engineering organizations around that capability, we need to think much larger than just how much code an individual engineer, or even an independent agent, can produce.

What Would Actually Make Smaller Teams Work?

There's an important difference between reducing the number of people on a team and reducing the amount of work that requires those people in the first place.

Imagine taking a team of eight engineers, giving them AI tools, and reducing the team to four. Those remaining engineers may be able to produce just as much output, but they still inherit the same operational responsibilities, dependencies, architectural complexity, organizational knowledge requirements, and coordination overhead. We've just concentrated existing organizational burdens onto fewer people.

Now consider a different approach. What if that same team used a platform that handled most of its infrastructure needs with self-service? What if security and compliance requirements were enforced automatically in the SDLC? What if architecure standards, ownership, system dependencies, and past decisions were readily discoverable, and teams had clear authority to make decisions within their boundaries?

Combine those improvements with AI agents that can take on repetitive implementation, analysis, testing, and maintenance work, and suddenly everything changes considerably. The engineering system has now eliminated or absorbed work that previously required human effort, specialized knowledge, or coordination.

To me, that's where the real opportunity lies. We should be asking how much complexity and organizational overhead we can remove from the teams responsible for delivering software, rather than assuming faster implementation automatically means fewer engineers are needed.

Oh, and a fun thought: isn't this what we should have been doing before AI exploded?

And a note of caution here: AI makes it increasingly inexpensive for teams to create their own infrastructure, integrations, delivery pipelines, internal tooling, and architectural solutions. That capability is valuable, but it also creates an enormous opportunity for fragmentation. I wrote a bit about it here: https://matteroftech.xyz/creation-is-cheap-coherence-is-not/

Build the Organization First

I think this is ultimately a question of sequencing.

If engineering leadership begins with a target for smaller teams, the natural temptation is to look at AI productivity improvements and calculate how much human capacity can be removed. But that approach risks optimizing for a workforce structure before establishing whether the surrounding engineering system can actually support it.

I'd rather see organizations use this time to reconsider how engineering work gets done. Where are teams spending time coordinating instead of delivering? Which responsibilities could be absorbed by shared platforms? How much institutional knowledge is inaccessible or exists only via collective wisdom? Are there governance processes compensating for missing technical controls? How much time is spent navigating complexity that we've simply accepted as a normal part of software development?

Those are the problems we shuld be solving, regardless of AI and what happens to team size.

We also need to start thinking about what we do with all the capacity AI creates. Organizations have no shortage of problems they'd like to solve, capabilities they'd like to deliver, or technical debt they'd like to address.

Higher engineering output should not result in doing the same amount of work with fewer people.

It should result in finally addressing problems that previously weren't economically feasible, improving the quality and resilience of existing systems, and lastly, delivering substantially more value with the teams we already have. That order is very intentional. I have a feeling organizations will tend to jump straight into increasing feature output while disregarding this new capacity to build better foundations. That should be avoided.

Over time, I think we'll see different outcomes depending on the org and the work involved. Some teams will get smaller, some will take on more responsibility, and others may remain similar in size while doing things that would have been impossible a few years earlier. The roles and skills we need will evolve too, particularly as technical judgment, architectural understanding, and the ability to operate across organizational boundaries become increasingly more important.

But we should not declare any particular team structure the destination before we've done the work to understand what AI actually changes.

Smaller teams shouldn't be the strategy. They may be an outcome of a strategy that makes engineering organizations more effective.

Even if smaller teams never materialize, an organization with better platforms, clearer ownership, less coordination overhead, stronger verification, and greater engineering autonomy is still an organization worth building. And isn't that what we should have been aiming for all along?