Capability Before Capacity
- Darren Emery
- Jun 16
- 4 min read
Why Throwing More Teams at the Problem Doesn’t Work
It’s a classic executive move: things aren’t shipping fast enough, so we scale up. Add more teams. Approve the budget. Ramp up delivery. On paper, it looks decisive. In practice, it rarely works.
Because the truth is this: you don’t scale delivery by adding teams - you scale delivery by enabling capability.
If you add capacity without building capability, you don’t get speed - you get friction.
The Temptation to Scale
Under pressure, it’s understandable. You’re being asked to deliver more. Faster. Across more initiatives. Your board wants digital transformation; your customers want features; your competitors are releasing weekly. So, you look at the org chart and think: “We need more squads.”
But here’s the problem: capacity ≠ capability.
Adding five new delivery teams to a capability gap is like pouring more water into a leaky bucket.
You’ll see activity, but not outcomes.
Capability Loops > Headcount Growth
Think of your delivery system as a loop, not a line. High-performing organisations invest in reinforcing loops of capability development - not just scaling teams, but increasing the ability of those teams to learn, decide, align, and execute well.
A “capability loop” involves:
Clarity of purpose and priorities
The ability to make decisions at the right level
Shared understanding between teams and leadership
Effective feedback loops from customers and delivery
Technical and organisational enablers (automation, architecture, access to users)
Without these, every additional team adds noise, not speed.
🔁 More teams = more coordination
🔁 More coordination = slower decisions
🔁 Slower decisions = delayed value
This is The Coordination Tax. And it compounds with every team you add — unless you’ve built the capability to absorb that growth.
A Simple Audit: Are You Building or Buying Capacity?
Try this diagnostic: for every new team you fund, ask:
What specific capability will this team add or amplify?
If you can’t answer that clearly, you’re growing headcount, not performance.
Capability vs Capacity: What’s the Difference?
Capacity | Capability | |
Definition | Volume of people or teams | The ability to deliver value effectively |
Measures | Team count, hours, throughput | Lead time, quality, customer outcomes |
Investment | Hiring, team setup, tooling | Skills, leadership, practices, technical enablers |
Failure mode | Busyness without results | Learning and adapting to unlock results |
The Hidden Cost of Premature Scaling
Adding capacity prematurely can hurt more than it helps. Here’s what typically happens:
Dilution of leadership: Your senior talent gets stretched thin trying to support too many teams.
Onboarding without enablement: New hires are dropped into underpowered systems without context or support.
Scope creep disguised as growth: More teams = “We can do more” = more things started = fewer things finished.
Slowdowns in delivery: Studies by the Standish Group and others consistently show that larger teams correlate with lower delivery success rates.
📊 In fact, Standish Group’s CHAOS Report (2020) found that small teams had a 58% success rate, compared to only 18% for large projects. It’s not about more. It’s about better.
What Capability Would 10x Your Delivery?
Ask your leadership team this question:
“If we could 10x one capability in our organisation today, what would it be?”
You’ll get powerful answers:
The ability to test and learn faster
Clearer strategic prioritisation
Better technical architecture to support scaling
More empowered team leads making smarter decisions
These are the multipliers. Get these right, and you can deliver more with fewer teams. Get them wrong, and even 50 squads can’t ship a toothbrush.
Case in Point: Scaling by Shrinking
One client we worked with had 14 delivery teams, but only three were consistently delivering value. The rest were bogged down in dependencies, unclear scope, and shifting priorities.
Our recommendation? Cut the number of initiatives in half. Reduce scope. Let teams focus. Within 8 weeks, throughput improved, clarity increased, and customer feedback cycles shrank from quarterly to bi-weekly. The kicker? They didn’t hire a single person.
This is what happens when you build capability first.
Capability Is the Constraint
In most organisations, capability is the bottleneck, not capacity. Teams aren’t underperforming because they’re lazy or inexperienced — they’re trapped in systems that don’t enable performance.
Look at your system:
Can teams get fast feedback from users?
Are your backlogs prioritised based on strategic outcomes or stakeholder noise?
Do your product leaders have real decision rights?
Is your architecture modular enough to support independent delivery?
If the answer is “not yet”, scaling headcount will only scale dysfunction.
Hiring vs Enabling - Which Comes First?
We’ve worked with many senior leaders who’ve been given the budget to hire - but not the mandate to change how work happens.
They add people before fixing the system.
But here’s the sequence that works:
Enable → Deliver → Scale
Enable core capabilities (learning, alignment, architecture, leadership).
Deliver value in focused, measurable ways.
Scale only what’s working.
As Marty Cagan puts it:
“You can’t empower teams that don’t yet have the capability. And you don’t get capability from scaling headcount.”
Well said.
The Takeaway for Senior Leaders
Before you approve another headcount increase or fund five more squads, stop and ask:
What outcome are we trying to enable?
What capability is missing that blocks us from achieving it?
Are we growing delivery or just inflating our org chart?
Build capability first. Capacity can follow. But not the other way around.
Because throwing more teams at the problem doesn’t solve it. It often makes it worse.
