Every process on your team that looks pointless falls into one of two groups: the ones protecting you from something you can’t see, and the ones protecting nothing at all. The hard part of running operations is that, from where you stand, the two groups look identical.
G.K. Chesterton made the argument in 1929, in a chapter of his book The Thing preserved by the Society of G.K. Chesterton. A reformer comes across a fence or gate built across a road and says, “I don’t see the use of this; let us clear it away.” The more intelligent reformer answers: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
Management writing calls this Chesterton’s fence, and most people quote it as an argument for leaving things alone. I think that reading is wrong, and I think the misreading does nearly as much damage as the careless reformer.
The Thursday ritual I almost killed
Early in my years running a team in IT operations at a large telecom, I inherited a weekly task that struck me as absurd. Every Thursday afternoon, one engineer compared the firewall rules on two sets of edge devices by hand, line by line, and emailed a one-sentence result to a distribution list nobody on my team could identify. It took about three hours. Our automated configuration backups already captured both devices. I wanted those three hours back, and I had a backlog that justified wanting them.
I asked around before cancelling it, mostly out of courtesy. Nobody knew why it existed. The engineer doing it had been handed it by someone who had been handed it by someone else. It took two weeks and a phone call to a retired manager to get the answer. Years earlier, a sync process between those devices had failed silently for more than a month, and an internal audit caught the gap before operations did. The manual comparison was the remediation our department had promised the audit group. The mystery distribution list was the auditors. Cancelling the task would have broken a commitment my team didn’t know it had made.
Here is the part that matters, though. Once I knew the reason, I could see it was already covered by something better: the old sync process had since been replaced by tooling that alerted on configuration drift within minutes. So we didn’t keep the fence. We walked the auditors through the new alerting, got their agreement in writing, and retired the Thursday comparison a month later. The three hours came back, and this time nobody was exposed.
That is what Chesterton actually asked for. Not reverence. Homework.
Your instinct is to add, so old fences pile up
If the only risk were managers tearing things down too fast, the advice would be simple: slow down. There is a second problem, though, and it runs in the opposite direction.
In 2021, researchers at the University of Virginia published eight experiments in Nature under a blunt title: People systematically overlook subtractive changes. Asked to improve designs, essays, travel itineraries and physical structures, participants reached for additions far more often than removals, even when removing something was the simpler and better fix. The bias got stronger under cognitive load and weakened when the task explicitly reminded people that taking something away was allowed. As the university’s summary of the work put it, our first instinct is to add, and subtraction shows up only when people keep thinking past their first idea.
Put those two findings side by side and you get the shape of most teams I’ve walked into during fractional COO engagements. Every incident, audit finding and bad afternoon in the executive suite added a step, a report, an approval or a meeting. Almost nothing was ever removed, because removal takes effort and nobody owns the job. A decade later the team is surrounded by fences, each built for a reason that made sense once, most of them guarding an empty field.
Telling that team to “respect Chesterton’s fence” is the worst advice you could give. They don’t have a fence problem. They have a fence graveyard.
Knight Capital kept a fence nobody understood
The cautionary tale people usually reach for is the reformer who tears something down and gets hurt. The most expensive example I know goes the other way.
In 2003, Knight Capital stopped using an old order-routing feature called Power Peg. According to the SEC’s order against the firm, the code was never deleted. It sat in the system, dormant, for nine years. In 2005 the firm moved a piece of logic that Power Peg relied on to track filled shares, and nobody retested Power Peg afterward; why would they, when nobody used it? Then in 2012, developers reused the old flag that once switched Power Peg on, assigning it to new code for the NYSE’s Retail Liquidity Program. A technician deployed the new code to seven of eight servers. On the morning of August 1, the flag woke Power Peg up on the eighth.
In about 45 minutes, the system sent more than 4 million orders into the market, traded over 397 million shares, and lost more than $460 million. The SEC later fined Knight’s broker-dealer $12 million in its first enforcement action under the market access rule.
Nobody at Knight tore down a fence. They left one standing long after anyone remembered what it was for, and then someone reused its gate. The fence that hurts you is not always the one you remove. Sometimes it is the one you stopped understanding and kept anyway.
What the principle actually asks of a manager
Read properly, Chesterton’s fence isn’t “keep” or “remove.” It’s “don’t act on a process you can’t explain.” That rule cuts both ways, and it turns into a routine you can run.
Look for the incident, not the rationale. Most operational rules were born the week after something went wrong. “Why do we do this?” usually gets a shrug. “What happened right before we started doing this?” often gets a story. Old tickets, change logs and audit findings are better witnesses than the current team. (If the problem is that the team has quietly drifted away from what a rule required, that’s a different disease; I wrote about it in the piece on normalization of deviance.)
Give somebody the job of subtraction. Removal never happens by itself, so schedule it. Once a quarter I have teams list every recurring report, approval and check, and answer two questions for each: what failure does this protect against, and would we catch that failure some other way today? Anything nobody can answer goes on a list for investigation, not deletion.
Put a deadline on the thinking. Chesterton’s reformer was told to go away and think, not to go away forever. If two weeks of honest digging turns up no incident, no regulator, no customer contract and no owner, I’m comfortable running an experiment: suspend the step for a set period, tell the people who would notice, and watch. Fences that guard nothing tend to prove it quickly, and a reversible decision like this one is cheap to undo.
When you find the reason, check whether it still holds. This is the step people skip right after doing the hard part. The Thursday comparison had a perfectly good reason; the reason had simply been solved by something better. Knowing why a fence exists earns you the right to remove it. It doesn’t oblige you to keep it.
Label the fences you build. Every check, approval or report your team adds from now on should carry one line of context: the incident or risk it answers, who owns it, and when it should be reviewed. Treat it like the note you’d want taped to the next mystery task you inherit. If you’re adding a safeguard at all, it’s worth asking first whether you can design the mistake out instead of adding another manual step.
New managers feel this tension most. The pressure to show impact makes every odd process look like an easy win, and the fear of breaking something makes every process look sacred. Neither instinct is the job. The team you inherited doesn’t need a guardian for its old fences or a bulldozer. It needs someone willing to find out what each one was for, and then make an honest call.