Running Corporate Technology: Smart vs Traditional

There are two fundamentally different ways technology is run inside large organisations.
Engineers feel the difference immediately usually within their first week.

One model treats engineers as risk to be controlled.
The other treats engineers as the system designers they actually are.

Everything else morale, velocity, quality, resilience is a downstream effect.

Model A — Technology Run By Generic Management

This is the dominant corporate model. It survives not because it works, but because it looks controllable.
1. Decisions are made by non engineers.
Architecture is dictated by people who don’t ship code, debug prod, or carry pagers.
2. Design authority is replaced by committees.
If enough people sign off, the design must be safe — even if it’s incoherent.
3. Requirements are frozen early.
Learning is treated as failure. Discovery is treated as scope creep.
4. Central teams own everything and nothing.
Platforms, tooling, security, release management — all abstracted away from delivery and accountability.
5. Engineers are throughput units.
Work arrives as tickets. Context is stripped out. Ownership is temporary.
6. Documentation is valued over correctness.
A wrong design with a diagram is preferable to a correct one discovered late.
7. Metrics reward appearances, not outcomes.
Green dashboards coexist peacefully with outages, rollbacks and customer pain.
8. Failure is investigated, not absorbed.
Post-mortems focus on who missed a process, not what the system made inevitable.
9. Scaling means adding layers.
When things slow down, coordination is added instead of removing constraints.
10. Release is an event.
Change is risky, infrequent, and stressful — therefore avoided.
11. Tooling lags years behind reality.
Engineers compensate with scripts, side systems and quiet heroics.
12. Abstraction is accidental.
Complexity leaks everywhere, but no one owns simplifying it.
13. Engineers stop caring.
Not because they’re lazy — because the system punishes initiative.
14. Talent retention becomes a mystery.
Leadership blames “the market” instead of the environment they created.
15. Technology becomes brittle.

The system works, until it doesn’t, and no one knows how it actually works anymore.

This is not a skills problem.
This is a system design failure.

Model B — Technology Run By Engineers

This model looks chaotic to outsiders.
To engineers, it feels calm, rational, and fast.
1. Engineers make engineering decisions.
Authority is tied to competence, not org charts.
2. Architecture emerges through use.
Designs evolve based on real constraints, not imaginary futures.
3. Requirements are negotiable.
Learning early is success, not failure.
4. Teams own systems end to end.
Build it, run it, improve it, or simplify it away.
5. Context is preserved.
Engineers understand why something exists, not just what to build.
6. Documentation follows reality.
It’s generated from code, pipelines and contracts — not PowerPoint.
7. Metrics are operationally honest.
Latency, error rates, deploy frequency, recovery time — not vanity KPIs.
8. Failure is expected and designed for.
Systems degrade gracefully. Humans don’t have to improvise heroics.
9. Scaling means removing friction.
Fewer handoffs. Fewer gates. Smaller interfaces.
10. Release is continuous.
Change is small, reversible and routine.
11. Tooling matches how engineers actually work.
CI, observability, infra and security are accelerators, not obstacles.
12. Abstraction is intentional.
Complexity is isolated, owned and constantly questioned.
13. Engineers optimise for long term health.
Because they’ll still be on call for it next year.
14. Talent stays because the work is meaningful.
Engineers grow systems, and themselves.
15. Technology compounds.
Each improvement makes the next one easier.

This model does not require “rockstar engineers”.
It requires trust in engineering judgement.

The Part No One Likes Hearing

Most corporate technology teams are dysfunctional, through fear of engineers making mistakes. So organisations replace judgement with process. They replace ownership with governance. They replace learning with compliance.

And then they wonder why:
• Systems are fragile
• Delivery is slow
• Engineers disengage
• Innovation comes from outside

If you don’t let engineers design systems, they’ll eventually stop understanding them. If they stop understanding them, no amount of process will save you.