There's a dynamic that develops slowly in many technology organisations, and by the time it's visible it's already doing serious damage. Delivery teams start to see architects as the people who slow things down. Architects start to see delivery teams as the people who cut corners. Both are responding rationally to the situation they're in. Neither is wrong. And the organisation pays the price.
The friction isn't personal. It's structural. And it can be fixed.
Architecture governance usually starts with good intentions. Standards exist for real reasons - security, consistency, long-term maintainability. The review process exists to protect the organisation from decisions that look fast now and expensive later.
But as organisations scale, the process doesn't always scale with it. A central team reviewing every significant decision becomes a queue. The queue becomes a delay. The delay becomes a blocker. And delivery teams, under pressure to ship, find ways around it.
The workarounds aren't malicious. They're pragmatic. But every shortcut taken around the governance process is a small erosion of the architecture the organisation is trying to protect.
What makes this particularly difficult is that the friction generates resentment on both sides. Delivery teams feel policed rather than supported. Architects feel their work is undervalued and their warnings ignored. The relationship that should be collaborative becomes adversarial.
Once that dynamic is established, it's self-reinforcing. Architects add more checkpoints to catch the shortcuts. Delivery teams find more creative ways around them. The gap widens.
The organisations that resolve this tension don't do it by asking both sides to be more understanding. They change the structure so the friction doesn't have an opportunity to form.
The most effective shift is moving architecture out of the critical path. Instead of a delivery team needing an architect's sign-off to proceed, the architect's thinking is embedded in the pathway itself - pre-approved patterns, ready-made solutions, guardrails that enforce good decisions by default. The team follows a route the architect has already designed and validated. No queue. No delay. No bottleneck.
When architects are no longer the gatekeepers, they become something more valuable: the people who design the roads everyone else travels on.
The other piece is making architecture work visible. Much of the resentment delivery teams feel comes from not being able to see what architects are working on or why decisions take time. When that work is tracked openly - priorities visible, timelines clear, decisions explained — the black box disappears.
Transparency doesn't just reduce frustration. It rebuilds the credibility that friction erodes.
The goal isn't an architecture function that delivery teams merely tolerate. It's one they actively value - because it makes their work faster, clearer, and more confident. That's what governance looks like when it's working.