Frankenstein Architecture: Why Most Transformations Are Just Collections of Parts
- Darren Emery
- 2 days ago
- 7 min read
Part 13 of the Performance Architecture Series
In the previous article, we examined Incentive Architecture: why organisations often reward the very behaviours that hold performance back.
That matters because incentives shape behaviour.
But even when organisations start aligning incentives - even when individual layers begin to improve…
...transformations still fail because performance is an emergent property of the whole system, not the result of isolated improvements.
And that's why most transformation efforts break. They treat the organisation as a collection of parts -
instead of a connected system.
The Illusion of Progress
Over the last decade, many enterprises have invested heavily in transformation.
Agile adoption.
Product models.
DevOps.
New governance forums.
Better metrics.
From the inside, it often feels like progress.
And in isolation, much of it is.
Step back, however, and the results are often underwhelming.
For a CTO or CPO, this isn't just a process problem. It’s an economic one. You are essentially paying a "System Tax" on every pound of capital deployed. You see it in the massive opportunity cost of features that hit the market too late, or the AI initiatives that never leave the sandbox because the governance layer wasn't designed to handle them.
Delivery is still slow.
Strategy still struggles to land.
Teams are still overloaded.
Customers still wait.
We have spent years trying to change the outputs without ever redesigning the engine.
Most organisations have evolved into something closer to a Frankenstein architecture:
→ Agile teams operating at high velocity - attached to waterfall governance models designed for quarterly control.
→ Annual project budgeting - funding product-led initiatives.
→ Output-based incentives - measuring outcome-driven strategies.
→ Centralised functions - supporting decentralised execution.
We have bolted modern delivery onto legacy design - then stood back and expected performance to emerge.
It doesn’t.
Because performance is not additive.
It is systemic.
Where Work Actually Waits
Work doesn’t just slow down inside teams.
It slows down between them.
Between:
funding and execution
decision and action
teams and dependencies
delivery and feedback
insight and incentive
In other words:
Work waits at the seams.
And the seams are where performance dies.
This happens because the system forces work to pause, translate, or re-justify itself at every boundary.
And those boundaries are defined by the architecture.
This is also where you lose your best people.
High performers don't quit because the work is hard; they quit because the friction is exhausting.
When your architecture forces a senior engineer to spend 60% of their time in "Certainty Theatre" -meetings, justifications, and manual handoffs-you aren't just slowing down delivery.
You are accelerating attrition.
The Performance Architecture Stack
To understand this properly, we need to step back and look at the system as a whole.
Performance is shaped by a set of interacting layers.
This is the operating physics of enterprise performance:
Capital Architecture - how work is funded
Governance Architecture - how work is controlled
Incentive Architecture - what behaviour is rewarded
Decision Architecture - who is allowed to act
Flow & Dependency Architecture - how work moves
Feedback Architecture - how the system learns
These are not independent. They are interdependent.
Crucially, they are not equal.
They operate with different levels of gravitational influence.
Capital shapes what is possible
Governance defines the constraints
Incentives drive behaviour within those constraints
Decision architecture determines responsiveness
Flow and dependency define execution speed
Feedback determines adaptation
If the upper layers are misalign,
The lower layers cannot compensate.
The Layer Collision Problem
This is where transformation efforts start to fail.
Because improving one layer while ignoring others does not create progress.
It creates collision.
For example:
High-velocity teams + Annual Capital Cycles → You’ve built a Ferrari, but you can only buy fuel once a year.
Real-time feedback + Output-based incentives → The team sees the cliff approaching, but they’re paid to keep driving.
AI-driven delivery + Legacy Governance → You can now generate code in seconds, but it still takes six weeks to get a security sign-off. The bottleneck hasn't disappeared; it's just become more obvious.
These are not edge cases.
They are the default state of most large organisations.
Because transformation is usually applied locally:
Agile fixes delivery
Finance adjusts funding
HR tweaks incentives
Leadership updates governance
But rarely designed as a coherent system.
What you have instead is an accidental system - emergent, inconsistent, and impossible to optimise.
Why Local Optimisation Fails
This is the core mistake.
Most transformations assume that improving individual components will improve overall performance.
But enterprise systems do not behave like that.
They behave like interconnected networks.
In a network, local optimisation often creates global degradation.
You can make teams faster… and still slow the system down.
You can improve feedback… and still fail to adapt.
You can clarify decisions… and still delay execution.
Because each improvement is constrained-and often throttled - by the layers around it.
When those layers are misaligned, they don't just fail to help; they actively cancel each other out.
The Structural Contradiction
At this point, the question shifts.
It is no longer:
“How do we improve delivery?”
“How do we scale agile?”
“How do we become more data-driven?”
You need to start asking: "Where is the system actively sabotaging the strategy?"
Because that is where performance is lost.
In the gaps where the architecture makes the strategy impossible to execute.
It is the collision between your goals and your rules:
The Mandate-Permission Gap: You give a leader the mandate to move at AI-speed, but leave them trapped in a governance structure designed for 12-month Waterfall cycles.
The Strategy-Funding Gap: You claim to value "Innovation," but your capital allocation is still locked into rigid, annual silos that can't pivot.
The Signal-Incentive Gap: Your data says "stop," but your bonus plan says "keep going."
The Velocity-Dependency Gap: You've optimised a team to ship in days, but they are tethered to a centralised function that moves in months.
When these layers don't speak the same language, the organisation doesn't just slow down - it stalls.
You are asking your people to achieve the impossible: to deliver 21st-century results while navigating a 20th-century chassis.
In a collision between a bold strategy and a legacy architecture, the architecture wins every single time.
Systemic Friction
Most organisations cannot see this directly.
They experience it as:
delays
rework
escalation
missed opportunities
frustrated teams
slow strategy execution
Underneath it all lies systemic friction.
Ask yourself: Is it safer for a leader to wait for a committee approval they know is unnecessary... or to act quickly based on evidence?
If your culture rewards compliance over impact, your architecture is working exactly as designed. It is protecting the status quo at the expense of the strategy.
Your system is not optimised for performance.
It is optimised for safety.
And safety-driven systems are predictably slow.
What High-Performing Systems Do Differently
High-performing organisations do not treat transformation as a set of initiatives.
They treat it as system design.
They:
align capital with strategic intent
design governance for speed, not just control
ensure incentives reinforce desired behaviour
push decision-making closer to the work
reduce dependency and enable flow
shorten feedback loops to enable learning
But most importantly:
They design these together, as a single, coherent operating system rather than a sequence of independent projects.
They remove contradictions because they understand performance cannot exist inside a system that disagrees with itself.
The Executive Diagnostic
To understand if your transformation is a system or just a collection of initiatives, ask these five questions:
1. The AI/Risk Paradox: Are we trying to build an 'AI-First' company on top of a “zero risk” governance model?
2. The Authority Gap: Do our leaders have the actual authority to match their accountability-or are we paying them to manage a system they aren't allowed to change?
3. The Hidden Tax: Where are we investing in "team speed" only for those gains to be cancelled out by our funding or approval layers?
4. Systemic Sabotage: What behaviours are we publicly encouraging that our internal architecture quietly punishes? (e.g., rewarding "Plan Adherence" while asking for "Innovation").
5. The Safety Bias: In a crisis, is it safer for a leader to follow the process or to follow the evidence?
These questions reveal whether your architecture permits you to perform, regardless of how much effort you put into "transforming."
The Reframe
Most transformations fail for a simple reason:
They are not systems.
They are collections.
Collections of improvements, initiatives, and changes.
But performance does not emerge from collections.
It emerges from coherence.
You cannot fix flow while incentives still reward congestion.
You cannot improve feedback while governance delays response.
You cannot accelerate decisions while dependency architecture prevents movement.
Transformation isn't a project you "do" to your teams.
It is a redesign of the environment they inhabit. If you want a different output, you have to stop tuning the engine and start looking at the physics of the chassis.
Final Thought
Across this series, we’ve explored the layers of performance architecture:
Capital defines what gets funded
Governance defines what is allowed
Incentives define what is rewarded
Decisions define what moves
Flow and dependency define how fast it moves
Feedback defines whether it improves
But none of these operate in isolation.
They form a system.
And systems do not respond to effort.
They respond to design.
So the question is no longer: “How do we improve each part?”
It is: “Have we designed a system that can actually perform?”
Because if the answer is no…
no amount of transformation effort will fix it.
Agilicist work directly with executive teams to map their Performance Architecture and identify the structural handbrakes holding back their strategy.
If you want to move beyond "local optimisation" and start designing for systemic speed, book a call: https://calendar.app.google/LnfEXzuZ8v6eWKYP7
We can start with a diagnostic of your current architecture.
This article is part of the Performance Architecture Series, exploring how organisations design for sustained performance.
Comments