When Processes Bring Teams to a Standstill
Projects . Tech . ToolingThe concept is set, the architecture is clear, the code itself is unproblematic. It is therefore almost only about implementation.
In earlier projects that would have been done in a few days. Programming, build, connecting the services, deploying to various environments — the team did it themselves. If something went wrong in a sandbox, they cleaned it up themselves and restarted. Usually a matter of minutes.
Today it looks different. For most steps the team must involve people from other teams. A faulty deployment in a development environment can no longer be cleaned up by the team itself. Instead it goes into a request, an ops team picks it up, and sometime — often only after a reminder — it gets cleared.
The actual work still takes minutes. The path to it takes on average half a day.
Promised Quality and Safety
The intention behind the new processes is serious. Quality should rise, errors should be detected early, nobody should blindly throw changes into a system. Scaling needs rules — that is no new thought.
Added to that is security as a separate requirement. Who may access which environment is no longer a team question. Permissions are cut tight, accesses run over defined ways, every change is traceable to a name. That also explains why a team can no longer clean up its own sandbox: the rights for that lie elsewhere now.
Part of the gates is non-negotiable anyway. Where audit obligations apply, it must be provable who approved a change and when it went into production. That is an external requirement, not a question of style.
For the rest the theory sounds plausible: the more checkpoints, the less can go wrong. The clearer a process is defined, the less it depends on individual knowledge. Responsibility becomes visibly distributed.
That is not wrong at first.
Where the Friction Arises
But reality diverges. A team wants to deploy a hotfix. The code is ready, tests green, everything fits. But: the CI pipeline demands a reviewer from another team. That person is in a meeting. Then the deployment ticket must be created. The ops team has a backlog. The ticket gets processed — two hours later. The hotfix goes live in the evening instead of the morning.
Another example: a developer needs a new environment variable in the staging environment. In the past: edit .env, deploy, done. Today: ticket, approval, ops, wait. The variable is set the next day.
The team does not lose competence. It loses agency.
The Hidden Cost
The visible cost is time. The invisible cost is behaviour change.
When every small step needs a gate, people stop doing small steps. They bundle changes. They avoid experiments. They build workarounds instead of fixing root causes because the fix would need three approvals.
The process that was supposed to ensure quality becomes the reason quality drops — because nobody iterates anymore.
What Helps
Not fewer rules. Smarter rules.
Trust but verify instead of verify then trust. Give teams write access to their own environments. Log everything. Audit afterwards. The person who breaks something fixes it — immediately, because they have the access.
Automate gates instead of human queues. Linting, tests, security scans, policy checks — all in CI. If the pipeline passes, it deploys. No ticket, no ops handover.
Define clear boundaries: What needs central control (production, secrets, compliance-relevant changes) and what is team territory (dev environments, feature branches, internal tooling).
Measure lead time, not gate count. How long from “code ready” to “running in staging”? If that number grows, the process is the bottleneck.
The Hard Truth
Processes scale. Trust scales too — but differently.
Whoever builds an organisation only on processes gets a machine that works reliably but slowly. Whoever builds on trust gets speed — but needs people who carry responsibility.
The sweet spot is not in the middle. It is: minimum viable process for the risk class of the change.
A typo in a README? No gate. A schema migration in production? Four eyes, rollback plan, audit log.
Most changes are closer to the typo than to the migration. Yet they go through the same gate.
That is the standstill.
Leave a Reply