It’s 3 a.m., and production is down.
The internal platform says your system is healthy. Dashboards are green.
Reality disagrees
… but the platform has the final say.
—
Internal development platforms often succeed.
They reduce variance and standardise workflows.
And in the process, they quietly move decision‑making —
away from engineers, and into the platform.
The platform claims to be removing toil.
What it removes instead is judgement.
The Promise of Less Thinking
Every few years, the same promise comes back:
Make the system simple enough, and expertise becomes optional.
- CASE promised it.
- 4GL and 5GL promised it.
- No‑code platforms and “citizen developers” promised it too.
Today, platform engineering sometimes promises it again — this time via workflows, dashboards, and a reassuringly modern vocabulary.
What’s sold is optimisation.
What’s served is control.
Flattening Is Not Optimisation
When a platform treats specialisation as a problem to be solved, control becomes the goal.
Optimisation doesn’t come from flattening capability until every worker is interchangeable. It comes from a division of labour that preserves judgement at the edges, while aligning specialised roles closely enough to keep friction low. Complex systems scale by composing expertise, not erasing it — a logic ants appear to have grasped some time ago.
Mis‑engineered platforms respond to scale by forcing uniformity. They mistake consistency for safety, ignoring the reality that different systems require different trade‑offs, and that those trade‑offs depend on expertise that the platform cannot fully absorb. Their interface narrows until behaviour becomes uniform, predictable, and easier to govern.
The paved road narrows into a corridor, then into a checkpoint. The golden path hardens until it's the only one safe to use.
Complexity did not vanish. It's displaced, pushed behind layers that fewer people are allowed to inspect, reason about, or challenge.
Nocturnal Diagnostics
When something breaks at 3am, where does the investigation begin?
- Do you drop into the underlying system?
- Or do you open the platform UI, and valiantly — sometimes vainly — venture to reconcile what it shows with reality?
If the first thing you inspect is the wrapper, the abstraction has already won.
The system is still there. But reality is no longer something you can inspect — only something you attempt to reconstruct from the abstraction that defined it. And when the abstraction is wrong, there’s nowhere left to go.
The system isn’t the problem. The abstraction is — and the abstraction is the only thing you’re allowed to touch.
The second signal is subtler.
Engineers stop asking how the platform works,
and start asking how to get approval from it.
The next signal will not be subtle.
Production breaks:
“We don’t have access.”
Constraint Accretion
Platform teams rarely set out to act as gatekeepers. The drift towards control is a structural response to pressure: audits, incidents, cost constraints, and executive mandates that reward restriction over engineering.
The path starts wide, helpful, and opinionated in useful ways, encoding best practices and removing friction. Adoption grows because it works.
Then constraints accumulate. Each seemed reasonable in isolation:
- “Use the approved module.”
- “Custom configuration not supported.”
- “Submit a request if your use case doesn’t fit.”
Taken together, they narrow the path — not by intent, but by default, as constraints outpace capability.
Nothing is forbidden. It’s just that some paths are more equal than others.
The platform still claims flexibility.
Technically, it’s telling the truth.
Where Flexibility Goes to Die
That flexibility lives in the escape hatch.
Every platform has one. Few are designed to be used.
As the official path narrows, everything that no longer fits is routed into a space that is technically available and practically hostile.
You need a non-standard network policy. The platform doesn’t support it.
There is an escape hatch — but it requires approvals, undocumented steps, and someone who’s done it before.
The question shifts from whether the platform is right, to how to get past it.
Yes, bypassing the golden path is possible —
- if approvals can be navigated,
- if tribal knowledge can be found,
- and if responsibility can be carried alone.
That’s not flexibility.
It’s deterrence with plausible deniability.
The exit exists, but is poorly lit, lightly documented, and guarded by process. “Unsupported” stops meaning requires skill and starts meaning proceed at your own risk.
The decay follows a familiar arc:
- The “right” thing is easy.
- The “wrong” thing is hard.
- Then everything else becomes impossible.
By then, the escape hatch exists mainly to preserve the fiction that escape is possible.
Abstractions Under Load
The platform starts to subtly shapeshift.
It stops composing the underlying infrastructure and starts containing it.
What was once a thin layer becomes a system of its own — adding UI, constraints, and calling the result “safety”.
Behold the shadow PaaS:
- Narrower than the systems it wraps
- Brittle at the core and sharp at the edges
- Riddled with bespoke abstractions — and bespoke failure modes
- Slower to evolve
- Supported — until it isn’t
Overlapping features justified as “consistency,” restrictions rebadged as “simplicity,” reinvention framed as “governance.” The platform stops composing the cloud and starts competing with it — while insisting that it's doing neither.
The underlying infrastructure hasn’t gone away. It’s just harder to reach.
Systems that were once directly observable and debuggable are now mediated through dashboards. Logs are filtered, delayed, or just out of reach. Interventions and metrics are preselected — to the exclusion of the ones you actually need.
The real system is buried deep under layers that were meant to simplify it.
Under load, the wrappers stretch. Under stress, they tear.
Abstraction didn’t remove danger.
It removed structural integrity.
When production is on fire, engineers don’t need permission:
- They need reach.
- They need to see underneath.
- They need the freedom to ask questions the platform did not anticipate.
Golden cages shrink the question space:
- Fewer knobs.
- Fewer metrics.
- Fewer sanctioned interventions.
Failures become more uniform, and harder to mitigate. Pipelines are torturously slow, randomly fail, and out-convolute a Rube Goldberg machine with both hands tied behind their backs.
Pressure builds. And reopening the system would mean reintroducing judgement.
There is only one tool left.
Process.
From Flow to Ceremony
This is where the platform mutates into a tollbooth.
It begins with substitutions that appear harmless: a form replaces a file, a dropdown replaces a variable.
Work no longer flows through primitives; it's funnelled through workflows. Engineering becomes ritual. “Self‑service” arrives — much as it has for visa applications.
You fill out the forms. You re‑enter the same information in different shapes. Validators and exception cases decide whether progress may continue. Authority and discretion live elsewhere.
Work shifts from building systems to performing for the platform.
Change requests stagger through guarded processes, gated by approvals from people you’ve never met, whose only role is to enforce constraints —
while the integrity of the service itself remains out of scope.
Instead of one line of YAML:
- you click through five screens,
- enter the same value thrice,
- your ticket waits …
- until finally, it’s misunderstood and misapplied.
Judgement is replaced by checklists, expertise by compliance, and skill by form completion. What once required understanding the system now requires navigating it.
As “infrastructure‑as‑code” degrades into little more than driving a UI — and manually copying values back into Git — the code is no longer the source of truth. Git just keeps the receipt.
That’s not automation.
That’s bureaucracy — with version control.
The platform has not just accumulated power. It has become dependent on it.
Owning the Interface
Most platform failures aren’t technical. They’re control problems that happen to speak fluent engineering.
Few organisations describe their systems as mechanisms of control. They are framed — often sincerely — in the language of safety, consistency, and scale. For a time, the framing holds — adoption rises, usage standardises, and metrics look healthy.
Well‑designed platforms solve this asymmetrically: strict where it must be, invisible where it can be. They enforce policy through automation rather than interruption, preferring guardrails along the road to gates across it.
In less well‑designed platforms, “developer experience” shifts meaning.
DX stops removing recurring toil and starts routing behaviour.
Some choices are smooth, others expensive, and the rest merely unsupported.
Nothing is banned. It is simply discouraged.
Effort does not disappear; it relocates. Capability shrinks while responsibility remains. Teams route around the platform where it hurts.
Then enforcement enters the conversation.
And trust leaves it.
The cage remains, only the gold is gone.
Flow vs Friction
Good platform engineering:
- Optimises for capability, not capture.
- Treats engineers as customers, not subjects.
- Governs with flow, not friction.
- Removes toil, not judgement.
- Scales function, not tickets.
Manual workflows give way to automation. GUIs yield to infrastructure-as-code. Abstractions are observable and debuggable, extending primitives rather than hiding them.
And when exceptions are needed, they’re usable, documented, and owned. The escape hatch is a contract, not a trapdoor: flexibility in exchange for responsibility.
Public works enable movement.
Zoning boards decide what is allowed to exist.
Good platform engineering is the former.
Golden cages are the latter.
Top comments (0)