Business

The Cautionary Tale of the Browser Wars and Why Business Transformations Often Fail

By Loraine Lawson,Steve Fenton

Copyright thenewstack

The Cautionary Tale of the Browser Wars and Why Business Transformations Often Fail

We all read the daily announcements about another major company launching a sweeping transformation. We’ve had waves of Agile, digital, omni-channel and cloud native transformations, and the AI-first transformations are a hazy silhouette on the horizon.

The press releases are optimistic, but the results are depressingly predictable. Trillions of dollars are wasted on failed transformations each year, and organizations don’t always survive the attempt. While most transformations fail outright, even the successful ones leave organizations weaker than before.

Learning From the Browser Wars

If you were to time-travel back 25 years, you’d find a great battle taking place between web browser makers. Mosaic was long gone, Netscape Navigator was dominating the market with a 70% share (1998), and they were about to lose it all to Internet Explorer, which soon flipped the tables on them to get a 75% share (1999). Firefox, Chrome, Edge, and Vivaldi didn’t even exist back then, so Internet Explorer was as good as it got.

There’s little doubt that Internet Explorer was a better browser than Netscape Navigator, but how did Microsoft get ahead of the dominant browser? Joel Spolsky attributed the loss of market share to Netscape’s decision to rewrite its browser from scratch. While they spent 3 years building a browser from the ground up, everyone else was racing ahead.

As Spolsky put it, “The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming. It’s harder to read code than to write it.” Every action the developers took to create a new browser based on “cleaner code” represented a loss of hard-won knowledge. The code looked messy because it handled scenarios and edge cases the developers weren’t originally aware of and have now forgotten.

When you remove all that mess, you aren’t making things tidier and better; you’re just breaking things.

Chesterton’s Fence

There’s a principle for this problem of tearing things down before you know why they exist. It’s called “Chesterton’s fence”, after the way G. K. Chesterton described the idea in 1929:

“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.”

To apply this rule, you have to work out why something exists before you remove it. In the process of determining this, you’ll often discover the necessity of its existence. You can apply Chesterton’s fence to everything from that inconvenient pole you want to remove from your kitchen (which is supporting the weight of walls on the upper floors) to rewriting Netscape from scratch.

And there’s a crucial lesson here because it also applies to transforming organizations.

The Reason Transformations Fail

Organizations perform transformations because they’ve identified an area of weakness so fundamental that they want to subvert the entire organization to the task of rectifying it. If you’re unable to deliver software frequently, you need an “Agile Transformation”. If you’re running your business in physical locations and customers can’t interact with you online, you need a “Digital Transformation”.

Organizations resist the kind of change a transformation introduces. Their control structures are designed to maintain the status quo. Every transformation attempt faces countless small battles: budget reviews that question the initiative, middle managers who protect their territories, processes that favor the old way of doing things. Each slight loss in these daily skirmishes undermines the transformation’s chances of success.

But there’s an even more spectacular failure that lies in wait for transformations that succeed. You see, when a transformation is a total success, it has won all the skirmishes and torn down every fence as far as the eye can see. The process of ripping out fence posts leaves no time for debates on their purpose, so the post-transformation landscape requires a process of re-learning thousands of past lessons.

There’s often limited time for this process of re-learning, because the next transformation is just around the corner.

The Transformation Paradox

You don’t find large-scale transformations in healthy companies. The only reason to initiate such a massive shockwave of change is that the organization has become disconnected from the reality it operates in. It takes years of denial to build up a gap so large that you have to use the brute force of transformation to close it.

The organization that reprimanded me in an annual review for advocating for web-based technology later kicked off a massive digital transformation project in an attempt to catch up on its lost decade. Their headquarters, which sits on a road named after their organization, now stands empty.

This is just one example among many, but the lesson is clear: the longer and harder you resist the changes around you, the more doom seeps into your organization. If you want to spot this kind of ingrained organizational rot, you need look no further than their number one symptom: transformation projects. In contrast, organizations that watch the world changing around them and make continuous minor adjustments never build up the level of decay that requires a transformation.

Think of it like taking a shower. Adaptive organizations keep one hand on the temperature valve, making minor adjustments as the water temperature fluctuates. In contrast, rigid organizations ignore the gradual changes until they’re either frozen or scalded, then they frantically spin the valve from one extreme to the other, creating even more chaos.

You only need to attempt a transformation because you’ve delayed beyond the last responsible moment. The failure has, for all intents and purposes, already happened. The transformation is the last throw of the dice for an organization, so they accept the collateral damage it will cause; the miles and miles of fence that must be flattened along the way, and the resulting loss of crops to hungry goats.

This is the paradox of transformations. You shouldn’t do them, but if you are doing one, it’s probably your last resort, so you have to carry on.

Lasting Change Is More Deliberate

It’s far better to aim for continuous and lasting change. This is a more deliberate process that replaces denial with courage to experiment. To make change stick, you need to implement it at a smaller scale and consistently.

Instead of converting an organization from paper to digital, you convert an organization from static to dynamic by making responsiveness to change part of its operating model. This takes a few crucial organizational capabilities, in particular a generative culture with psychological safety and transformational leadership.

You’re not forcing people to experiment, you’re making it safe to do so.

Continuous small-scale change reduces the chance of having to race to catch up. Instead of performing house-clearance style transformations where you throw out everything, then find yourself re-purchasing expensive items you should have kept, you’ll prevent the hoarding that makes it necessary to throw everything in a skip.

Ironically, the organizations that have learned how to be good at constant small-scale change are better equipped to make a more dramatic change when they need to. Rather than a transformation, they undertake a Kaikaku or Kaizen Blitz to switch out larger puzzle pieces to boost their advantage. Unlike a transformation, these approaches to radical change start by understanding the current state and the target state, which often reduces the total amount of change required to reach the desired destination.

If you want change to be successful, you need to make it happen all the time.