Same Spell, Same Failure: How Engineering Teams Get Trapped in Broken Rituals

There's a particular kind of meeting that happens in engineering teams everywhere. Someone raises a problem. A solution gets proposed. And then, from somewhere in the back of the room — or buried in a Slack thread — comes the phrase that kills momentum dead: "That's just how we do it here."

No explanation. No origin story. Just institutional gravity, pulling everyone back into the same orbit they've been stuck in for months, sometimes years.

This is what we'd call the incantation problem. The team keeps chanting the same words, following the same steps, expecting something different to happen. It rarely does.

Why Broken Rituals Feel Safe

Here's the uncomfortable truth: repetition isn't always laziness. Sometimes it's survival.

When engineers are under pressure — shipping deadlines, understaffed sprints, executive pivots every quarter — the brain reaches for what's familiar. Familiar is fast. Familiar doesn't require justification. Familiar doesn't get you questioned in a post-mortem.

Psychologists call this status quo bias, the tendency to prefer the current state of affairs even when change would be objectively better. In software teams, it shows up as the deployment process nobody touches because "last time someone changed it, everything broke." It shows up as the code review template that's been copy-pasted since 2019. It shows up as the sprint planning ritual that takes four hours and produces plans nobody looks at by Wednesday.

The ritual isn't working. But it feels like it's holding things together. And that feeling is powerful.

The Fossilization Timeline

Broken rituals don't arrive fully formed. They calcify slowly, in stages.

Stage one: The original reason. Some process gets introduced because it solved a real problem. A specific incident. A particular client. A moment in the company's history that required a specific response.

Stage two: The context disappears. The people who remembered why the process existed leave, get promoted, or just stop explaining it. The documentation — if there ever was any — goes stale.

Stage three: The ritual becomes culture. Now it's not a process, it's an identity. Questioning it feels like questioning the team itself. New hires who push back get told to "get up to speed first." Senior engineers shrug and say it's not worth the fight.

Stage four: The cost becomes invisible. By this point, nobody's calculating what the broken ritual actually costs — in engineering hours, in morale, in the features that never shipped because the team was busy maintaining the incantation.

This is when it gets dangerous. Not because the ritual is actively catastrophic, but because its cost has been normalized into the background noise of how work gets done.

The Psychology Behind the Pushback

Even when engineers know a process is broken, they often won't say so out loud. That's not cowardice — it's a rational response to how change proposals tend to land in established teams.

Proposing a process change is implicitly criticizing everyone who built and maintained that process. It requires political capital most engineers would rather spend elsewhere. And if the change fails or causes disruption, the person who suggested it owns that outcome in a way that feels very different from the shared ownership of maintaining the status quo.

So the ritual persists. Not because nobody sees the problem, but because seeing the problem and surfacing it are two very different risks.

Breaking the Spell Without Blowing Up the Room

The good news is that organizational inertia isn't permanent. It just requires the right kind of pressure, applied consistently, in the right places.

Name the ritual explicitly. Vague discomfort doesn't create change. Specific friction does. Instead of saying "our deployment process feels slow," say "our deployment process requires seven manual steps, three of which have no documented purpose, and costs us approximately four engineering hours per week." Numbers make the invisible visible.

Ask for the origin story. Not to mock it — genuinely. "Hey, does anyone know why we do this?" is a disarming question. Sometimes the answer reveals a constraint that no longer exists. Sometimes it surfaces a risk nobody had articulated. Either way, you've turned a ritual into a conversation.

Run a small experiment, not a revolution. Proposing to "fix the entire deployment pipeline" is a political nightmare. Proposing to "try a different approach for one service over two sprints and measure it" is a lot easier to get through the door. Small experiments create evidence. Evidence changes minds more reliably than arguments.

Create psychological safety for the post-mortem. Teams that regularly ask "why did we do it this way and is it still working?" don't let broken rituals fossilize in the first place. That kind of retrospective culture doesn't happen by accident — it requires explicit permission from whoever's running the team.

The Cost of Keeping the Chant Alive

Every broken ritual is a tax. Sometimes it's a small one — a few hours of friction per sprint. Sometimes it's a load-bearing tax that's quietly shaping what the team believes is possible.

The teams that move fastest aren't the ones with the most tools or the most talent. They're the ones that have built the habit of questioning their own habits. They know the difference between a process that exists because it still works and a process that exists because nobody wanted to be the one to stop it.

The incantation only has power if you keep saying it.

Stop chanting. Start asking why.