Picture this:
You’re in charge of managing a team. But there have been disagreements among the top management, and the person you report to has left. You’re unsure of how work will be allocated with a new reporting manager.
Soon enough, you realize that the new manager is the exact opposite of the old one and is making too many changes to work allocation, how the output is measured, and the general working style of your team.
This is leading to a general loss in productivity and shipping speed as it has broken too many existing processes and created chaos. But during appraisals, they refuse you a promotion and cite your inflexibility to work with their system as the cause of the drop in performance.
But your biggest gripe, by far, is that the top management — people who've been around since the early days of the company and know the current systems from the inside out — are too busy fighting their own fires to pay attention to this.
Exhausted, you leave for greener pastures.
Do you relate to the situation?
When changes are enthusiastically introduced to a system and processes messed with without understanding how the current system works, we may have removed what they call a Chesterton’s Fence.
G.K. Chesterton, who also lends his name to the fallacy, explains Chesterton’s fence as follows:
"There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “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.”
You see, an organization is a complex system with thousands of moving parts, all of which got added organically as it grew from the founding team to the thousands of people who work in it today.
All these parts were added with a purpose and they are closely interlinked with each other. You break one part and you affect many others.
At such times, a person — one who doesn't have an inkling of why certain things are the way they are in the organization — starts making huge changes, it is obvious that it will tip off a lot of dominos in the complex chain and a lot of things are likely going to break.
In other words, this person starts removing fences without understanding why they were put up in the first place.
Let me tell you a story.
When I was in college, I used to intern with my friend's father, who had a carbon brush manufacturing facility in Mumbai and used to supply carbon brushes for DC electric motors used at industrial plants.
While working with him, I once accompanied him on a trip to the Polycab Wires factory in Vapi, Gujarat.
There, as he was giving me a tour of the factory and describing how the entire process of making insulated wires worked, right from annealing to insulation, there is this one bit from my conversation I clearly remember:
"I'm currently dealing with these young engineers who are now demanding a harder grade of carbon brushes for the motors, simply because they wear off slowly and have to be replaced less often.
But what these amateurs don't realize is that a harder carbon brush wears off the commutator and that is much more difficult and expensive to replace than a pair of carbon brushes, as these are all legacy Seimens motors from Germany with no replacement parts available in India.
If the commutator wears off, they will have to order one from Seimens Germany, if they can even get it for this old and outdated model now, that is.
Experienced engineers know this, these young ones don't. They don't think in second-order effects and how some errors are more reversible and manageable than others."
A similar Chesterton's Fence case happened with TV shows.
Before rampant piracy and OTT services took over, one could watch TV shows only on a one-episode-per-week basis. In fact, HBO continued to release episodes weekly even if they were aired on an OTT platform.
Do you remember religiously waiting for a new episode of Game of Thrones? It kept you interested in the show. The system of releasing episodes on a weekly basis, as was done before, worked.
The reason why the old-school method worked was that it sustained viewer interest in a season for a longer duration. A 10-episode season of Game of Thrones captured your attention and created social media buzz for 10 weeks instead of a week or two, as is typical for shows whose entire seasons are released all at once.
Not only that, it incentivized people to stay subscribed to the channel longer.
Compare a recently popular show like The White Lotus (an HBO production) on DisneyHotstar to another one like The Playlist (on Netflix).The former gets talked about consistently across all social media channels after every episode whereas the latter will be quickly binged on and forgotten in a week or two.
While both avenues are valid for new content, one has more of an ability to keep the interest of the viewer over time. Ironically, Netflix is now considering releasing episodes on a weekly basis to reduce the user churn it has experienced recently.
What is common to both the instances highlighted above is that the old system is replaced by a new one for everyone to later discover that the old system served everyone better.
Change is good. But too much intervention too quickly in a complex system that has stood the test of time leads to all sorts of unintended and undesirable consequences.
Here’s an example of how to do it better.
I recently spoke to a manager at a leading IT firm who told me about a legacy code that was written about a decade ago for an insurance company.
She told me that the code was written to process about 10 applications per day. It worked until recently when the application volume had reached about 10,000 per day. In the interim, the teams used workarounds so as to not disturb the legacy code. But with the 10,000 applications per day frequency, the old system had to be replaced.
Now, a big issue here was that the legacy code and the changes made to it weren’t documented by the teams before. So, before drastically changing the code to serve the new demand, the team traced back to the workarounds figured out why they were introduced, and then resolved them by writing new code. They also paid attention to documenting the changes they were making for others to make sense of it in the future.
Even though the process took around a week and required the team to write extensive documents, they traced back reasons why the code was written in a certain way.
Changing any system is certainly useful and at times may be necessary. But how you go about it can make all the difference.
As a newcomer with all the energy and enthusiasm in the world, you might think of disrupting legacy systems all at once with your novel and revolutionary ideas. You may like to believe that moving fast and radically changing how something is done is the way to go.
But without gathering a good understanding of why a certain system is currently the way it is, you’re but a rebel without a cause.
