Cricket loves tradition more than almost any sport on earth. Whites. Tea breaks. Five-day Tests. A pavilion full of people who remember how things were done in 1957.
Roland Butcher grew up in Barbados, moved to England at thirteen, and played for Middlesex between 1974 and 1990. In 1980-81 he made his Test debut at Bridgetown, in the country of his birth, and became the first Black cricketer to represent England. For a century the "tradition" of the England side had an unwritten shape. He broke it by being good enough.
Roland joined me on Corey-osity Unleashed, and one idea from our conversation keeps nagging at me. If you're still doing it the 1970 way in 2025, you're obsolete. Tradition is not a virtue.
I agree with him. I also think most leaders hear this, nod, and go straight back to their Tuesday change board.
Age Is Not Evidence
Every team runs on practices nobody remembers choosing. The weekly status meeting. The release freeze before every holiday. The sign-off from a director who has never read the code. Ask why, and you get the same answer: "We've always done it this way."
The phrase sounds like a reason. It isn't one. It tells you how long a habit has survived, not whether it works.
Economists have a name for this pull. In 1988 William Samuelson and Richard Zeckhauser ran a series of decision experiments where the same choices appeared with and without a pre-existing default. People stuck with the status quo when one was offered, and the bias grew stronger as the number of alternatives grew. Nobody in those studies decided the default was best. It was simply already there.
Your team works the same way. The more options on the table, the more attractive "keep doing what we do" looks. Inertia wears the costume of wisdom.
The Most Dangerous Phrase
None of this is new. In a 1976 interview with Computerworld, Grace Hopper warned data processing managers about the single most dangerous sentence they used, the one about always having done it this way. Quote Investigator traced the line back and found Hopper made the point more than once, with the wording shifting each time.
Think about who said it. Hopper helped build some of the first compilers and pushed for programming languages written in plain English. She spent her career watching people resist ideas which later became obvious. She did not warn against old ideas. She warned against old ideas defended by age alone.
Fifty years later, software teams still use the phrase. We say it with more acronyms now.
The Change Board Nobody Questions
Here is my favorite example from engineering, because the research is so clear.
Plenty of organizations still push every production change through a change advisory board or a senior manager. It feels responsible. It looks like control. It has been around since before most of your engineers were born.
DORA studied it. Their write-up on streamlining change approval is blunt. Heavyweight external approval has a negative impact on software delivery performance. DORA found no evidence a more formal external review process leads to lower change fail rates. Worse, the slow process pushes teams to release larger batches less often, and bigger batches carry more risk when they land.
Read it again. The ritual meant to reduce risk raises it.
DORA's alternative is not chaos. Peer review during development, backed by automated testing, continuous integration and good monitoring. Real control, closer to the work, done by people who read the diff.
So why do so many CABs survive? Because nobody owns the question. The board exists, the meeting is in the calendar, and removing it feels like a bigger risk than keeping it. Status quo bias, with a recurring invite.
I wrote about a cousin of this problem in Command-and-Control Is Dead. Your Processes Never Got the Memo. Leaders change their words long before they change their workflows.
Don't Bulldoze the Fence Either
Now the other side, because "tear it all down" is its own lazy habit.
G.K. Chesterton wrote about this in 1929, in his book The Thing. Picture a fence or gate across a road. One reformer sees no use for it and wants it gone. Chesterton's answer: if you don't see the use of it, you don't get to clear it away. Go and find out why someone built it. Come back when you know, and then you might be allowed to remove it.
Engineers know this as Chesterton's fence, and it matters. Some of your odd traditions encode real scar tissue. The freeze before Black Friday might exist because a deploy took down checkout in 2016. The two-person sign-off might be a regulator's requirement for segregation of duties. DORA itself names segregation of duties as a legitimate goal of change approval. The tradition is not the problem. Forgetting why it exists is the problem.
So the rule is not "kill old practices." The rule is "make every practice earn its place again."
A tradition with a known reason is a tool. A tradition with no reason is a superstition.
Some Traditions Earn Their Place
Back to Roland for a moment. In October 2022 the City of London gave him the Freedom of the City. The Freedom itself is believed to date back to 1237. It started as permission to trade in the City. Today it honors people for their contribution to London and public life.
Nearly eight hundred years old, and still alive. Why? Because its purpose changed when the world changed. Nobody kept it running out of loyalty to 1237. It survives because people keep finding a reason for it.
This is the test for every practice on your team. Not "how old is it?" but "would we invent it today?"
Run a Tradition Audit
You don't need a transformation program. You need an afternoon and some honesty. Here is how I'd run it with an engineering team.
List the rituals
Write down every recurring meeting, approval step, template, freeze, report and checklist. Include the ones nobody talks about, like "we always email the release notes to the VP."
Ask three questions of each
- Why does this exist? Find the original reason. Ask the longest-serving person on the team. Search old tickets and postmortems.
- Who owns it? If nobody does, you have found your first candidate.
- What would break without it? Be specific. "Something bad" is not an answer.
Sort into three piles
- Keep. The reason still holds. Write the reason down next to the practice so the next person doesn't have to dig.
- Change. The goal still matters but the method is stale. Swap the weekly CAB for peer review and automated checks, the way DORA suggests.
- Stop. No reason, no owner, nothing breaks. Kill it, and tell people you killed it.
Run experiments, not revolutions
For anything in the "stop" or "change" pile, try it for a set period. Pause the status meeting for a month. Track what happens. If nothing breaks, you have your answer. If something does, you found the fence's purpose, and now you get to protect it with intent.
I like this approach because it respects both Roland and Chesterton. Nothing survives on age alone, and nothing dies on a whim.
Old Dogs Learn Fine
The saying claims old dogs won't learn new tricks. In my experience the dogs are fine. The trouble is the kennel. Teams don't resist change because people are slow. They resist because nobody gave them permission to question what was already there.
Give your team the permission. Make "why do we do this?" a normal question in retros, not an act of rebellion. Reward the person who finds a dead ritual the same way you'd reward the person who fixes a production bug.
Roland changed what an England cricketer looked like by playing the game well, not by asking the pavilion for approval. Your team won't get a moment like Bridgetown. They will get a hundred small ones, every time someone asks why.
So look at your calendar for next week. Which meeting would you never invent if you were starting the team from scratch today?
Cancel it first. Then ask why it took you so long.