You've sat through the all-hands. The one where the CTO stands up front and announces: "We're a flat organisation. We trust our people. We move fast."
Then you go back to your desk, open a PR, and wait three days for two mandatory approvals before anything gets merged.
Modern tech leadership in a nutshell... the values are contemporary, the processes are from 1983.
The Gap Nobody Talks About
I've worked with engineering teams for decades. The teams loudest about autonomy and trust are often the ones who've built the most elaborate approval labyrinths.
Want to deploy a hotfix? Fill in the change request form. Get it reviewed by the Change Advisory Board. Wait for the next deployment window on Thursday. No exceptions.
Want to rename a variable? Create a ticket. Add it to the backlog. Get it groomed. Get it pointed. Get it into a sprint. Get it reviewed. Get it approved.
I've sat in architecture meetings where a fifteen-minute decision required six people in the room, a slide deck, and a follow-up email to "get alignment." The decision? Whether to use Postgres or MySQL for a new internal tool. Stakes: low. Theatre: absurd.
This is not agile. This is bureaucracy wearing agile's clothing.
Where the 1983 Thinking Hides
Your processes aren't evil. Most of them were sensible once... nobody ever revisited the assumptions underneath them.
The three-person approval chain? It made sense when you had one shared server, no version control, and a deploy taking six hours and breaking production monthly. The assumption baked in: developers cannot be trusted without supervision.
The change freeze window from December 15 to January 5? It made sense before CI/CD pipelines, automated rollbacks, and feature flags. The assumption: shipping is inherently dangerous.
The architecture review board where two senior engineers must sign off on every new service? It made sense when services were monolithic and a bad decision would take eighteen months to undo. The assumption: most engineers will make the wrong call.
None of these assumptions were ever wrong. They were appropriate responses to the constraints of the time. The problem is the constraints changed... the processes didn't. The checkout queue at a supermarket made sense before self-scan machines. Nobody keeps the checkout queue and adds self-scan as an optional extra.
The processes survived. The assumptions didn't. Nobody noticed because nobody asked.
The Cost of Living in the Past
This isn't merely an annoyance. It's measurable.
DORA's research tracks software delivery performance across thousands of teams worldwide. Elite teams deploy on demand... multiple times a day. Low-performing teams deploy between once a week and once a month. The gap isn't talent. The gap is process friction.
DORA's research also identifies psychological safety... the belief you won't be punished for mistakes... as one of the strongest predictors of software delivery performance. Teams where members feel safe raising concerns early and admitting uncertainty ship faster and break less.
You cannot build psychological safety in a system treating every developer as a potential liability.
According to Gallup, highly engaged teams are 17% more productive and see a 21% improvement in profitability. Engagement collapses under top-down control. And when your best engineers leave because they're exhausted fighting the system, industry research puts the replacement cost at six to nine months of their salary.
Then count the knowledge lost, the onboarding time, the dropped context. The true cost is closer to a year of productivity for every senior engineer who walks out.
Outdated processes aren't free. They're expensive in ways nobody puts on a dashboard.
What Agile-Washing Looks Like
Most teams I've worked with aren't malicious about this. The CTO announcing trust on stage genuinely means it. The contradictory process was built by a different team three years ago and nobody has the mandate... or the courage... to remove it.
Scrum.org identifies this as the core reason agile fails: organisations adopt the ceremonies without the mindset. You get standups without autonomy. You get sprints without trust. You get retrospectives where nobody says what's wrong.
There's a particular variant I see in larger tech companies: "agile" teams making all their significant architectural decisions in week one of a project. Week-one architecture is waterfall with extra steps. You're making your biggest choices at the moment you know the least... the exact opposite of what agile is supposed to enable.
The sprint board is new. The command-and-control instinct underneath it is decades old.
What to Do About It
Start with one question: Why does this process exist?
Not "what does this process do"... obvious from reading it. Ask why. Trace it back to the original problem it was solving. Then ask whether the problem still exists in the same form, with the same severity, and the same consequences.
If the answer is "we don't know" or "it's always been this way"... there's your starting point.
Some patterns worth looking for:
Approval gates built on suspicion. If a process exists primarily to catch someone doing something wrong, ask whether suspicion is the right default. Most engineers don't need protection from themselves... they need guardrails, not gates. There's a significant difference between automated checks preventing a bad deploy and a human sign-off proving it got reviewed.
Reviews blocking rather than improving. Code review is valuable. Mandatory 48-hour hold periods are not. The difference is whether the review exists to improve the work or to prove someone checked it. One adds value. The other adds friction.
Meetings performing decisions. Sprint planning where the work was already assigned before anyone arrived. Architecture sessions where one person's opinion always wins. These aren't collaborative decision-making processes... they're compliance theatre.
Documentation nobody reads. If your runbook hasn't been touched in two years but still governs production deployments, you don't have documentation... you have archaeology. It reflects how the system once worked, not how it works now.
At Step It Up HR, the core argument is this: the old ways of treating people at work don't work anymore. This applies to engineering processes as much as to HR policy. The underlying question is identical... do you trust your people, or don't you?
If you don't trust your engineers to deploy without four sign-offs, fix the hiring. If you do trust them, fix the process.
The Uncomfortable Truth
Command-and-control processes feel safe. They feel rigorous. When something goes wrong, you point at the checklist and say "we followed the process."
Cold comfort when your team is three months behind after a quarter spent waiting for approvals. Cold comfort when your senior engineer hands in their notice because they spent more time waiting for sign-off than writing code.
Real rigour comes from investing in the people making decisions, not from wrapping decisions in approval theatre. Fewer incidents? Build a culture where engineers feel safe raising concerns early. Faster deployments? Remove manual checkpoints and invest in automated testing. Better architecture? Grow the people... don't bottleneck them through a committee.
The next time you sit through an all-hands and hear about flat structures and trust and moving fast, ask yourself one question when you get back to your desk: does your process match what was said on stage?
If not... you know what needs changing.