Growth by Subtraction: How Agile Transformations Quietly Create Bureaucracy (and Slow You Down)
- Darren Emery
- 3 days ago
- 6 min read
Most executives I speak to don’t say this out loud.
But after a drink or two, they admit it.
“We spent millions on Agile… and somehow everything got slower.”
And now the organisation costs more to run, takes longer to decide - and still misses the outcomes it promised the board.
More meetings. More roles. More handoffs.
More governance layers wearing Agile-themed hoodies.
And yet:
Release cycles stretched
Dependencies multiplied
Accountability blurred
Decision latency crept into everything
If that sounds familiar, you’re not alone. In fact, it’s become the default outcome of large-scale Agile transformations.
The uncomfortable truth is this:
Most Agile transformations didn’t make organisations lighter.
They made them heavier.
And that’s because agility, at scale, was misunderstood from the start.
The Original Promise vs. the Lived Reality
Agile was sold to executives as a solution to speed, adaptability, and customer responsiveness.
What many actually bought was:
A new operating model
A new layer of roles
A new set of ceremonies
A new coordination tax
The promise was flow.
The outcome was friction with interesting vocabulary.
SAFe. Spotify. Custom hybrids with slide decks thicker than the problems they were meant to solve.
None of these frameworks are inherently “bad”.
But they share a dangerous assumption: That agility is achieved by layering on structure.
In reality, agility is achieved by removing constraints.
Agility Isn’t an Operating System Upgrade
Here’s the mental model that gets organisations into trouble: “We’re not Agile yet. Let’s install Agile.”
So they do what enterprises always do:
Standardise. Scale. Add controls.
Create specialist roles to manage the complexity they just introduced.
This is how you end up with Release Train Engineers coordinating teams that can’t release independently, and Portfolio layers managing dependencies instead of eliminating them.
At that point, you don’t have an agile organisation.
You have a coordination machine.
And coordination does not scale well.
This is what we call Coordination Theatre - the appearance of alignment without the economics of speed.
It looks busy.
It feels controlled.
It produces decks, ceremonies, and confidence.
But underneath, it increases decision latency, hides real constraints, and quietly taxes every delivery cycle.
To be clear: this isn’t an argument for chaos, nor a naive call to “just let teams do whatever they want”. Regulated environments still require controls. The question is whether those controls are embedded in the system - or layered on top of broken design.
The Real Enemy: Organisational Complexity
Let’s be blunt. Complexity is the silent killer of speed.
Not technical complexity alone - organisational complexity:
Too many dependencies between teams
Too many decision-makers per decision
Too many approval paths
Too many roles whose sole purpose is “alignment”
Every dependency introduces a meeting, a handoff, a delay, and a negotiation. Scale enough of those, and delivery slows to a crawl - no matter how many squads, trains, or tribes you have.
The tragedy is that most transformations respond to complexity by managing it, not removing it. That’s where the weight comes from.
Why “Descaling” Is the Missing Conversation
Real agility doesn’t come from scaling frameworks.
It comes from descaling the organisation.
Descaling doesn’t mean cutting headcount indiscriminately or centralising control.
Descaling means:
Reducing dependencies
Shrinking decision paths
Simplifying interfaces between teams
Designing for independent flow
In other words: Growth by subtraction.
The C-Suite’s Actual Job (That No Framework Teaches)
Here’s the uncomfortable bit most transformations avoid.
The C-Suite’s job is not to roll out a methodology or mandate ceremonies.
Their real job is to design an organisation where coordination is rarely needed.
That means making hard structural choices:
What should teams own end-to-end?
What decisions can be pushed to the edge?
What dependencies exist purely because of historical org design?
Agility is not a delivery problem. It’s an organisational design problem.
And organisational design is one of the few things only the executive team can change.
The Org Chart Test (A Simple, Stark Diagnostic)
Want a fast sense of whether your transformation added speed or weight?
Look at your org chart.
Divide your headcount into two buckets:
The Value Creators: The people who create value (coders, designers, testers, sellers).
The Coordinators: The people whose primary job is to talk to the Value Creators and tell other Coordinators what the Value Creators are doing.
Every additional Coordinator exists to compensate for a decision the organisation refuses to make structurally.
If the "Coordinators" bucket is growing faster than the "Value Creators" bucket, you have a bureaucracy with stand-ups.
If your chart is full of Project Managers, Program Managers, Release Train Engineers, and Dependency Leads, understand this: These roles don’t exist because people are incompetent.
They exist because the system requires constant negotiation to function.
That’s a design failure - not an execution failure.
In one financial services organisation we worked with, over 40% of the delivery organisation sat outside teams whose primary job was “alignment”.
We didn’t start by adding new roles or frameworks. We removed two dependency loops and collapsed one decision forum.
The result: lead time dropped by 35% - without adding a single engineer.
Nothing about delivery changed. The system did.
That’s the difference between managing complexity and removing it.
Coordination Roles Are a Symptom, Not a Solution
This is where many execs get defensive.
“Those roles are essential. We couldn’t operate without them. They keep things aligned.”
Exactly. And that’s the problem.
If alignment requires permanent roles, the organisation is structurally misaligned.
Coordination Theatre feels like progress - until you look at the economics.
In high-performing systems, teams don’t need permission to release.
Decisions are clear at the point of action.
Dependencies are designed out, not managed in.
Coordination becomes exceptional, not constant.
The View from the C-Suite
Why COOs Feel the Pain First
COOs are often the first to sense something is wrong. They see rising overhead, falling throughput, and longer lead times despite more people. From an operating perspective, scaled Agile often looks like higher cost per unit of value. That’s not transformation. That’s inefficiency with better branding. Descaling speaks directly to COO instincts: Fewer moving parts. Clearer ownership. Lower operational drag.
Why CTOs Are Quietly Losing Patience
CTOs usually know where the bottlenecks are. They see teams blocked by external dependencies and engineers spending more time explaining work than doing it. Many are trapped inside a model that promised autonomy and delivered "coordination theatre." Descaling reframes the conversation: Stop asking teams to move faster. Start removing what’s slowing them down.
What Descaling Looks Like in Practice
This is where most articles stop. Let’s not.
Here are practical descaling moves we see work in real organisations.
1. Collapse Decision Layers
If a decision has a clear owner, limited blast radius, and is reversible, it should not require a forum. Push it to the team. Measure outcomes, not compliance.
2. Redesign Teams Around Value, Not Functions
Teams organised by component or capability create dependencies. Teams organised around customer value absorb them. End-to-end ownership reduces coordination by default.
3. Kill the Dependency Backlog
If you have a backlog of dependencies, you have a structural problem. Instead of managing them, ask why they exist. Remove the coupling. Redesign interfaces. Change team boundaries.
4. Replace Governance with Guardrails
Governance that checks work after the fact slows everything down. Guardrails that shape decisions before they’re made increase speed and safety.
5. Measure Flow, Not Activity
Velocity and utilisation metrics reward busyness. Flow metrics expose friction: Lead time, Cycle time, Time-to-decision, Time-to-learning.
The Courage Gap
Here’s the real reason most organisations don’t descale.
It requires letting go of control theatre.
It requires trusting teams with real responsibility.
It requires removing roles people have built careers around.
Installing a framework feels safer.
Descaling feels personal.
But only one of them actually works.
The Provocation
If your Agile transformation resulted in more roles, more layers, more meetings, and more coordination, then it didn’t fail because people “did Agile wrong”.
It failed because you added weight when you should have removed it.
Agility isn’t something you scale up.
It’s something you strip back.
A Final Question for the Exec Team: If you removed 30% of your coordination mechanisms tomorrow… Would delivery collapse? Or would it finally start flowing?
If that question made you uncomfortable, it’s usually a sign the organisation needs fewer frameworks - and a clearer design conversation.
That answer tells you everything you need to know.
Comments