It's Thursday morning, 9:40, and Sandra, Lead Architect at a large German industrial corporation, is standing in front of a whiteboard drawing an architecture. Loosely coupled, clear domain boundaries, well-thought-out interface contracts. It's the right architecture. She knows it. Her team knows it.
At 10:15, Sandra walks into the steering committee. Fourteen people, three projectors. The division head interrupts after slide two. He was at a conference last week. He heard a talk about "Headless API-First." He didn't understand everything, but enough to bring it up in a steering committee. He asks why the platform isn't being built Headless API-First. What Sandra is proposing sounds complicated. Headless sounds modern.
By 11:00, the architecture is Headless API-First. Not because it's right. Not because anyone thought through the implications. But because the institution wants it that way. Nobody in that room is incompetent. The people aren't the problem. The system is the problem.
Three weeks later, an external consultant sits at the same table. He's good. He has twenty years of experience. After two days of workshops, he arrives at exactly the conclusion Sandra had from the start. Loose coupling. Clear domain boundaries. The right architecture.
The division head listens, nods, and says: "But we agreed on Headless API-First." The consultant hesitates. Then his own structures kick in: the client is king. The client doesn't want to hear that he's wrong. The client wants to hear that his intuition was right. So the consultant adjusts his recommendation. He calls it "a pragmatic adaptation to the existing decision landscape." Sandra calls it something else.
The consultant's role would be to advise. To say what's right, even when it's uncomfortable. But the incentive structure of consulting points the other way: follow-up contracts, client satisfaction, references. Contradict the client and you risk the contract. So the consultant confirms what the client already decided and calls it strategy.
It's Not the People. It's the Machine.
In nearly every corporation, there exists an invisible force that shapes technical decisions without ever having written a single line of code. It's not a person. It's the institution itself — its evaluation cycles, its incentive systems, its governance rituals. Together they create a gravitational field that bends every architectural decision in its direction.
Not because anyone has bad intentions. But because the system is built so that rational actors behave irrationally. When incentives and engineering collide, the incentives win. Always.
The Annual Review Cycle as a Silent Saboteur
Every year, between October and December, something happens in German companies that officially goes by "annual performance review" and unofficially by "the two weeks where nothing else matters." Managers evaluate their direct reports. That sounds reasonable. The problem is the mechanics.
Starting in September, an invisible race begins. Everyone needs something to show. Something with "impact." Refactoring has no impact. Paying down technical debt has no impact. "What did you achieve this year?" — "I cleaned up the codebase." That's not a sentence that triggers promotions.
Only 14 percent of employees say annual performance reviews inspire them to do better work. Worse: 66 percent report that annual appraisals actually lower their productivity. The system designed to measure performance destroys performance.
So Sandra doesn't build what would make technical sense. Sandra builds a new microservice gateway because that sounds better on a review slide than "stabilised the existing codebase." She's not being opportunistic. She's being rational. The system says: build something new. Visible. Presentable.
The Roadmap Belongs to the Business. Engineering Drinks from the Firehose.
In most organisations, the roadmap is written by the business. Engineering determines how it gets built. In theory. In practice, it's drinking from the firehose: too many competing priorities, no room for foundations, and the "how" is so constrained by the "what" and the "when" that no real decisions remain. Every feature gets bolted onto the existing headless architecture because a rebuild would cost three months that nobody has budgeted.
Engineering becomes a fulfilment centre. The architecture is no longer a design — it's a by-product. Layer upon layer, feature upon feature, each under time pressure, none with a view of the whole.
The institution separates the people who know what's possible from the people who decide what gets done. And then it wonders why the results are neither possible nor done.
Goodhart's Law and the Metrics Trap
"Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes."
As soon as a metric becomes a target, it ceases to be a good metric. Velocity is measured — so story points get inflated. Test coverage is measured — so tests are written that test nothing. Deployment frequency is measured — so deployments happen more often, whether the changes make sense or not.
The institution measures what's measurable. Not what's important. The architecture is built to satisfy metrics. Feature velocity over system stability. Coverage percentages over correctness. Goodhart formulated this in 1975. We still haven't understood it.
The Political Economy of Technical Decisions
TOGAF, the most widely used enterprise architecture framework in the world, contains a sentence more honest than anything else in enterprise IT: "Corporate politics is critical to enterprise architecture."
In practice: the division with the highest revenue gets the most developers. The VP who speaks loudest gets his feature. The platform the CTO chose three years ago doesn't get questioned — because questioning it would mean questioning the CTO.
Conway's Law is not a joke. Organisations design systems that mirror their org chart. Three teams, three budgets, three definitions of success — so a system with three parts. Sandra drew the right architecture. But it doesn't fit the org chart. So Sandra draws a different one.
Slow Is Smooth, Smooth Is Fast
Slow is smooth, smooth is fast. Navy SEALs learn this on day one. Institutions don't understand it. "When will it be done?" is the most common question in every steering committee. Not "Is it right?" Not "Will it last?"
So things get built fast. And because they're built fast, they're built sloppily. And because they're built sloppily, they take longer than if they'd been done properly from the start. Investing a week to understand the domain looks like standing still. It's the investment that prevents three months of rework. But the institution doesn't see the rework because it lies in the future.
Institutions reward heroes who pull all-nighters to save releases. They should reward systems that don't need heroes.
The Courage to Reassess
No is the most unpopular word in a corporation. No means: we were wrong. So nobody says no. Instead things get "re-scoped," "pivoted," or "deferred to Phase 2" — where Phase 2 is a euphemism for "never."
Sandra knows the third microservice project doesn't make sense. Nobody says it. Because saying no means upsetting the stakeholder, looking bad in the review cycle, not getting budget. So Sandra builds it. On time. On budget. Correctly implemented. Nobody uses it.
Building Institutions That Don't Eat Their Own Architecture
What if review cycles were continuous instead of annual? What if refactoring were rewarded the same as a new feature? What if the roadmap were designed together with engineering instead of dictated by the business?
There are organisations that do this. They measure lead time instead of velocity. Incidents instead of coverage percentages. Outcomes instead of feature output. They give engineering a voice as a design partner, not as an order taker.
Sandra is standing in front of her whiteboard again. The headless API is on the roadmap. She's a good architect. She knows which system would be the right one. But she builds the system the institution rewards.
The institution is the architecture. As long as we only rebuild the software but not the organisation that produces it, we keep getting the same thing: good people in bad systems. The whiteboard has the right architecture. The org chart has a different one. And the org chart wins. Always.