Before you delete that pointless process, find out who put it there

Most pointless process is scar tissue from an incident nobody remembers. Find the story before you swing.

Second week on the job, a new delivery lead found his first trophy: the Friday release freeze. No production deploys after Thursday noon, no exceptions, owner unknown. The freeze had its own wiki page, last edited four years ago. He read it twice, called it bureaucratic theatre in the team channel, and retired it on the spot. The channel lit up with applause emojis. Someone posted a wrecking ball gif. Fastest win of his first month.

Six Fridays later, a payments change shipped at 4:40 in the afternoon and died quietly at eleven on Saturday night. The one engineer who knew the recovery steps was on a plane. The team spent the weekend rebuilding transaction records by hand, and Monday's postmortem carried an awkward footnote: the same failure had happened in 2023, almost beat for beat. That earlier outage was why the freeze existed. Nobody warned him, because the engineer who wrote the rule had left in the spring, and the story left with her.

He didn't delete a pointless process. He deleted the memory of a bad weekend.

Pointless process is usually scar tissue

Here's the uncomfortable truth: most process you're tempted to mock was written by someone while they were still bleeding. Rules don't appear because a manager woke up craving paperwork. They appear in the week after something broke. An outage, a compliance scare, a client escalation, a demo that went so badly the account nearly walked. The fix becomes a rule, the rule outlives the incident, the author changes companies, and three years later a smart new leader finds a fence standing in the middle of a field and can't see a single reason for it.

The cruel part: the better the rule works, the more pointless it looks. Nothing has blown up in so long that the fear reads as imaginary. There's an old name for this trap, Chesterton's fence: don't tear down a fence until you know why somebody built it.

It's also why "that's just how we do it here" deserves a proper translation. What that sentence actually means is: the reason left the company, and nobody wants to be the one who finds out the hard way. That's not stupidity. That's an organization remembering a lesson without remembering its name.

Your job isn't to defend old rules. Your job is to find out what they know that you don't.

Dig before you demolish

The origin of a rule is almost always findable, and finding it takes an afternoon, not a quarter. Three digs, in order of payoff:

• Ask the longest-tenured people one precise question. Not "why do we do this?" That gets a shrug. Ask "what happened right before this rule appeared?" That gets a story, and the story carries the reason.

• Search the incident history around the rule's birthday. The incident channel, the old severity tickets, the postmortem folder, the thread titled "never again." Rules cluster around bad weeks.

• Read the oldest version of the runbook. The first draft usually names the fear in plain language. Every edit since has sanded it into policy wording. Version one tells you what they were actually scared of.

If an honest afternoon of digging turns up nothing, no incident, no author, no story, that silence is evidence too. Now you've earned an opinion. And write down whatever you do find, because in a few years somebody new will be staring at your replacement rule, wondering who put it there.

Three bins, sorted honestly

Once you know the origin, every rule you want to kill lands in one of three bins, and the bin decides the verb.

Scar tissue that still protects something live. The risk that created the rule is still real. Keep the rule, or replace it with something better than a blanket ban. A Friday freeze built in the era of manual deploys can retire honourably once feature flags, automated rollback, and a real on-call rotation are doing the same job. The protection survives. Only the friction dies.

Dead ritual. The thing it protected is gone. The system was decommissioned, the client churned, the regulation changed two revisions ago. Kill it in the open, with the origin story told, so the team learns that rules in this organization have reasons, and endings.

Misapplied cure. The fear is legitimate, the mechanism is wrong. One bad config change becomes a change board where thirty people review everything, which mostly teaches risky changes to travel in disguise. Right fear, wrong medicine. Redesign it: heavy review for the genuinely dangerous classes of change, a fast lane for everything else.

Sort honestly, because the second bin is the fun answer and the first is the common one. Your frustration will lobby hard for dead ritual. Make it show evidence.

Remove it like someone who might be wrong

When a rule genuinely deserves to go, the move isn't deletion. It's a controlled removal, run by someone who knows they might be wrong. Four steps:

• Announce a trial, not a funeral. "We're pausing the freeze for eight weeks" invites the organization to watch with you. "The freeze is dead" invites it to watch you.

• Time-box it. An end date forces a review. Without one, the removal drifts into the new normal without anyone ever deciding it worked.

• Name the rollback trigger before you start. "One weekend incident tied to a Friday deploy and the freeze comes back while we rethink." Decide that on a calm Tuesday, because nobody negotiates well mid-outage.

• Measure what the rule was protecting, not just what it was costing. Everyone tracks the speed they gained. Track the weekend pages, the failed changes, the recovery time too. If you only measure a rule's cost, every removal looks like genius until the bill arrives.

If you can't name the rollback trigger, you're not running a trial. You're hoping.

The fence builder might be in the room

One layer nobody warns new leads about: rules have authors, and authors have memories. Call the freeze bureaucratic theatre in front of the person who wrote it after the worst weekend of her career, and you haven't critiqued a process. You've reviewed her judgment in public, without reading it first.

So retire rules the way you'd retire a respected colleague: honour the incident, then explain what changed. "This freeze saved us in 2023, and it was the right call. Here's what's different now: flags, automated rollback, a second on-call. That's why I believe it's safe to trial removing it." Same decision, opposite politics. One version turns the fence builder into your reviewer, and she's the best reviewer available, because she knows the failure modes the wiki never captured. The other version creates a quiet enemy with an excellent memory and no deadline.

Said with respect, the removal makes you look senior. Said with a smirk, it makes you look lucky. Until you aren't.

The interview question hiding in all this

"Tell me about a process you improved" shows up in nearly every delivery interview, for Scrum Masters, project managers, and delivery leads alike. Most candidates answer with a deletion story. Too many meetings, a pointless freeze, I cut them, velocity went up. It sounds decisive. To an experienced interviewer it sounds like a wrecking ball describing its week.

The strong answer includes the archaeology. What the rule protected. How you found out. Which bin it landed in. The trial, the time-box, the trigger you named before you started, the measure that proved the protection held. "I retired our Friday freeze after confirming the incident behind it was covered by rollback and feature flags. Eight-week trial, a named rollback trigger, weekend incidents stayed at zero, lead time dropped." Same Friday. Same deletion. Only one of these answers proves you know which walls are load-bearing.

Fences aren't sacred. Plenty of them deserve to come down, and the leaders who take them down well are the ones who get handed bigger systems. Just do the archaeology first. The question that saves you isn't "is this process annoying?" Every process is annoying. The question is: who put this here, and is the thing they were afraid of still alive? Answer that, and you can cut with a steady hand.