Why Smaller Teams Deliver Faster in Digital Operations

When delivery slows down on digital transformation or digital operations projects, the instinct is almost always to add more people. It seems logical that adding more capacity would help, whether that be more engineers, another designer, a dedicated tester, or sometimes additional project management support. The increased cost is an easy ask to justify upward measured against the risk of a delay. But after 16 years of technology delivery across organisations, I find the real constraint is almost never headcount, it is in fact team structure.

Team structure is not just the roles you have on a team, but it's also how people see their scope and whether they feel ownership towards the product or service end-to-end. In larger teams you inevitably end up with individuals passing work between siloed roles and losing context, momentum, and accountability at every handoff.

I had a recent example of this leading a multi-national e-commerce transformation for a large client, where they asked me to step in to recover a failing platform and turn around the company's quick commerce channel. When I started I inherited a team of 25 external individuals, and strategically and iteratively chose to bring it down to 7 in-house individuals. The shift significantly reduced run costs, but impressively, we also got faster.

Key Takeaways

• Smaller digital operations teams often deliver faster than larger ones because coordination overhead grows exponentially with each person added, while useful output only grows linearly.

• The "you build it, you run it" model, where the same team designs, builds, and operates a product, produces better decisions because every perspective is in the room when tradeoffs are being made.

• Adding people to a struggling delivery team is the default response but often the wrong one, because the real constraint is often how people see their scope, not whether there are enough of them.

• Right-sizing a digital operations team is a strategic leadership decision about ownership and accountability, not just a cost-cutting exercise.

Why adding people to a slow delivery team usually makes it slower

Every person added to a team increases the number of communication channels exponentially. This is maths that hasn't changed since Fred Brooks observed it in 1975: a team of 7 has 21 communication links, but scale that to 15 and you're at 105, which is five times the coordination cost for roughly double the people. Amazon built an entire organisational philosophy around this with their "two-pizza team" model, capping teams at roughly 5-10 people because they found that individual productivity measurably drops as teams grow, a pattern researchers call the Ringelmann Effect.

In siloed teams the coordination problem compounds because people only see their slice of the product (or the problem!), and over time that narrow view shapes how they think about their role. Work gets passed from function to function, context evaporates in the handoff, and nobody feels ownership of the outcome because nobody both owns and understands the full picture. On the e-commerce programme I was brought in to recover, the previous structure had completely separated support and development, so the support team had been papering over bugs for months because they didn't have the authority or the access to fix root causes, while development had no visibility into what was actually breaking in production.

Here's how siloed and end-to-end team structures compare across the factors that most affect delivery speed:

Ownership of outcomes: Siloed teams diffuse ownership across roles and functions. End-to-end teams share ownership across the whole team. Bug visibility: Siloed teams separate symptoms (support) from code (dev). End-to-end teams see both. Change lead time: Siloed teams take weeks due to handoffs, approvals, and queues. End-to-end teams deliver in days or hours. Product knowledge: Siloed teams develop narrow, role-specific knowledge. End-to-end teams build broad, cross-functional understanding. Accountability when things break: Siloed teams have unclear accountability. End-to-end teams have immediate accountability.

What "you build it, you run it" actually means for team design

"You build it, you run it" is an operating model principle where the same team that designs and builds a digital product also operates and supports it in production. Amazon CTO Werner Vogels coined the phrase in a 2006 interview when speaking about feedback loops. When the people who build something also live with the consequences of how it runs, they make different design decisions and they fix things faster. People think differently when the 2am alert is coming to their phone, not some disconnected anonymous team.

When I restructured the e-commerce team it was important that a core value was that everyone "got their hands dirty" across the full product and everything it took to design, build, and run it. That included me working through budgets, vendor contracts, and commercial business cases as much as being in the backlog and product design with the team. Everyone debated, contributed to and understood the core system design decisions together rather than handing requirements from one function to the next.

Once we brought the build and run functions together we were shocked by the number of bugs the previous support team had just been papering over because they had no power to do anything else. With the same people now building and supporting the product, those bugs got fixed at the root rather than patched over. Over time we spent less time unpicking legacy complications and more time building new value, and the team got faster because they understood the whole product rather than just their small corner of it.

What better decisions look like when a team owns the full product

End-to-end ownership, where the same team designs, builds, and operates a product, doesn't just make teams faster at delivery. It changes the quality of the big decisions they make because every perspective is in the room when tradeoffs are being weighed, and importantly they have a broad context and form principles for making smaller decisions autonomously.

Part of the e-commerce platform the team was building was to handle made-to-order drinks for online ordering, so coffees, teas, and specialty drinks. One example of an important design decision the team had to work through was how to handle milk alternatives like oat, soy, almond, and coconut, which varied depending on what the individual store happened to stock. This not only would be a pattern across other customisation, but it touched everything: how the company was going to handle this both online and in its store operations, what the right customer experience was, what the technical constraints were from existing POS and stock management integrations, and what the tradeoffs looked like between different approaches across UX, technical effort, cost, and operational complexity.

In a siloed team structure a product designer would have specced a solution in isolation and handed it to engineering. Engineering would have likely built exactly what was asked, without opportunity to truly understand or add their expertise.

Instead, the whole team sat with the problem together and the decision that came out of that (virtual) room accounted for UX, technical sustainability, cost, and operational reality all at once because every perspective was present. It was a truly better design.

How to tell if your delivery team is the wrong shape

The first thing I look at when I'm engaged on a delivery problem is whether the team is structured around perceived traditional roles or around common goals. If your digital operations or transformation team is spending more time coordinating than delivering, the problem probably isn't that you need more people. When I'm engaged I start looking at whether there are handoffs between individuals or functions that could be eliminated if a smaller group owned the process from design through to production support. Are some roles on the team primarily to coordinate between other roles rather than to build or deliver anything themselves? And when something goes wrong in production, how many people are needed before anyone can actually understand and fix it?

For the e-commerce platform example, through the significant technology improvements, better operating model and smaller team, the OpEx dropped by 50%.

That's a significant saving on its own, but what made the value compound was that it came alongside faster delivery, not at the expense of it. The business operations team went from four-week change cycles to autonomous and automated changes in minutes, and incident rates dropped by 40%. Reducing costs and increasing velocity at the same time is what happens when you get the team structure and ownership right.

If your transformation team is spending more energy coordinating work than doing it, the question worth asking probably isn't "do we need more people?" but whether the people you already have are structured to own the outcome or just responsible for their individual piece of it. If you're trying to work that out, it's the kind of operational question I help organisations work through.

Common Questions

Why do smaller teams deliver faster in digital operations?

Smaller teams deliver faster because coordination overhead grows exponentially with team size while useful output only grows linearly. A team of 7 has 21 communication links but a team of 15 has 105, which means significantly more time gets spent coordinating and less time building.

What does 'you build it, you run it' mean?

'You build it, you run it' is an operating model principle where the same team that designs and builds a digital product also operates and supports it in production. Amazon CTO Werner Vogels coined the term in 2006 when speaking about feedback loops, and the core idea is that teams who live with the consequences of their design decisions end up making better products.

How do I know if my delivery team is too big?

The clearest signals are spending more time in coordination than in delivery, handoffs between roles that lose context, and needing more people to fix a production issue than were involved in building the feature. If roles exist primarily to coordinate between other roles then the team structure is likely the constraint rather than the team size.

Is right-sizing a team the same as cost-cutting?

Right-sizing a delivery team is a strategic leadership decision about ownership and accountability rather than just a cost reduction exercise. Cost savings often follow (in one engagement OpEx dropped by 50%), but the primary goal is giving a capable team full ownership of their product and the authority to make decisions about it.