You’ve sat in a 90-minute standup for a team of five. You’ve filled out a JIRA ticket for a bug you already fixed. You’ve watched a 20-person company hire a full-time process manager. And somewhere deep in your gut, you knew: this isn’t about getting work done. It’s about someone feeling safe.
Process is rarely about productivity. It’s a psychological defense mechanism for managers who don’t trust their teams. If that stings, good. Because that’s the only way we can stop pretending that every ceremony, every approval gate, every sprint retrospective is about efficiency. The truth is messier.
I audit engineering teams for a living, and I see the same pattern: a six-person team running ceremonies lifted straight from the 400-person org their VP came from. Nobody can say what coordination problem any of it solves. But ask them to kill a process, and suddenly it’s a political project. Adding a process is easy. Removing one requires a funeral.
This is the cargo cult of maturity. Startups watch their role models and think: if we just do what Amazon does, we’ll get Amazon’s results. But they forget that Amazon’s processes were built to solve specific problems at scale. A startup adopting PR reviews with three sign-offs before a single customer exists isn’t adding discipline. It’s performing it.
If the process isn’t solving a specific coordination problem, it’s solving a trust problem. Managers who don’t trust their teams build guardrails. Founders who fear accountability build gates. And teams that feel the friction but have no capital to fight it just learn to hate their jobs.
The worst part? The process doesn’t stay where you put it. It metastasizes. A weekly status meeting becomes a daily standup. A two-step approval becomes a six-step. Someone writes a wiki page about the approval process, and now you need a separate process to maintain the process. The amount of work you’re doing to manage the work starts dwarfing the work itself.
What’s the alternative? It sounds radical, but it works: start with the problem. Before you introduce any new ceremony, ask the room: what specific coordination breakdown is this solving? If nobody can describe the breakdown, you don’t need the process.
The most efficient teams are the ones with the least formal process and the most shared context. They communicate directly. They trust each other to make decisions. They add process only when the cost of miscommunication outweighs the cost of the ceremony. And when that happens, they name the problem, solve it, and move on. They don’t turn it into a religion.
So what do you do if you’re stuck in a process-heavy team? You can’t just rebel — that’s a career-limiting move. But you can start asking better questions. In the next retro, instead of ‘How can we improve our standup?’ ask ‘What problem is our standup solving?’ The silence that follows will be louder than any JIRA alert.
Process is a tool, not a virtue. If you can’t say why it exists, you can’t defend it.
FAQ
Q: Aren't some processes necessary? Like code reviews or sprint planning?
A: Yes, the right processes solve real coordination problems. The issue is when they're adopted by default, not by necessity. If your two-person startup runs daily standups because that's what Big Tech does, you're not being disciplined — you're being theatrical.
Q: What's the practical implication for a team leader reading this?
A: Before adding any new ceremony, force yourself to write down exactly which breakdown it fixes. If you can't articulate it, don't add it. And if you're stuck with legacy processes, start asking 'what problem does this solve?' at every retro. The political cost of removing a process is high, but it's higher to keep it.
Q: Doesn't this argument just justify chaos? Some teams need structure.
A: Structure isn't the same as process. Shared context, clear goals, and direct communication create structure without ceremony. The contrarian take: the more you formalize collaboration, the less it happens. Trust and alignment beat playbooks every time.