The Cure for Corporate Inertia
We all know that big, established companies struggle to respond to "disruptive" change. Blockbuster, HMV, Nokia, and Yahoo! are all current examples of companies that are struggling with this problem--they are trying to adapt, but are being held back by powerful and often invisible inertial forces.
A recent example of corporate inertia really struck home, and got me thinking about the key role management processes play in preventing change.
In October 2010 I agreed to do a Webinar for a big book publisher. I have done half-a-dozen webinars before, typically for small companies with a subscription-based business model. The process looks like this: they email me, I agree to do it, we arrange a date 2-3 months out, we do a quick technology check the week before, and then the event happens. It is all very easy for me, lecturing to an unseen audience in my own office. Frankly, I am not sure how much the audience gets out of these events, and indeed I sometimes wonder how many people are actually listening. But that is a question for another day.
The process with the publisher was rather different. The person I was talking to suggested a multi-speaker event six months out. The other speakers and I all said yes. He then consulted with his board, who decided it was all a bit rushed, and couldn't be marketed properly, so we ended up delaying by a further six months. We all agreed.
A couple of months later, I received a draft contract--10 pages of detailed legalese, including clauses restricting my use of the presentation materials with other audiences and requiring me to acknowledge them in all subsequent use of the materials.
It finally dawned on me what was going on--the webinar was being treated like a book. You know, one of those bulky paper things we used to take on holiday before the Kindle was invented. And once I had taken out the clauses that restricted my use of my own materials, the final version was then sent to me in hardcopy, by courier. You know, one of those companies that was set up to distribute paper around the world before the Internet was invented.
The publisher had, in other words, taken its century-old process for selecting manuscripts and negotiating rights with authors, and applied it with little adjustment to these new digital and virtual offerings. My realization that this is what happened also explained the mystery around the six-month delay. Every publisher knows that books either get published in spring or fall; that is the way the publishing calendar works. So once our webinar missed the spring window, it obviously had to be bumped to an autumn date.
I know I am being a bit harsh on the publisher here. The people who work there are smart and knowledgeable, and they understand these new technologies as well as I do. But they are being held hostage by their archaic management processes, processes that they themselves curse but are incapable of getting around. The result, in this particular case, is a webinar that has cost a great deal to put on (in management time and legal fees) and with significant delays. It remains to be seen if the size or quality of the audience is better than usual, but I can guarantee the product (my performance) will be exactly the same as the low-cost, low-frills webinars I have done before.
This experience reinforced for me just how inert and inflexible management processes are in most large organizations. A company can change its strategy, replace all its senior managers, outsource half its activities, and even get people thinking differently, but its core management processes--the way it allocates resources, evaluates people, negotiates contracts--will still be running under their own steam, just as they did decades earlier.
Why are management processes the last bastion of resistance when a company is trying to change? I think there are three linked reasons.
- Management processes are a long way from the action. They support primary value-adding activities, but are often two or three steps removed from the marketplace, so feedback from customers about the need to work differently or more quickly is filtered and lost.
- There are strong vested interests at play. Board members like to offer advice and make decisions, lawyers like writing contracts. Turkeys don't vote for Thanksgiving. Enough said.
- Management processes are usually dependent on each other, and together they create a tightly-woven matrix that cannot easily be pulled apart. If you try to change one process, you upset a further two or three others, and pretty soon you are taking on the entire system.
So what's the way forward?
One argument is that systemic problems require systemic change, in which case the whole problem gets tossed back to the CEO: Only he has the authority and influence to rip up the old management processes and start again. Lars Kolind did this, for example, when he created a "spaghetti organization" in Danish hearing-aid company, Oticon.
But I think its a cop-out to hand the problem back to the CEO, and indeed there isn't much evidence that CEOs are any good at re-engineering their management processes anyway (with a few notable exceptions).
So I think we need to explore a more bottom-up approach, one that at least creates some urgency and evidence that will subsequently support a more top-down led change process. Let's call it experimentation:
- Experimentation is a mindset in which action is more important than analysis; in which the manager's role as a change agent is to maximise learning rather than minimize risk.
- Experimentation is also a methodology for structuring a small-scale change project with clear objectives and explicit deliverables.
Here is a brief example. The leading general insurance company in Scandinavia is a company called If. During the first quarter of 2011, If launched a set of management experiments, designed to help it increase its agility and responsiveness to changing customer demands.
Like most companies, If has well-established procedures for launching new products and services, and there was a legitimate fear that these processes could suffocate efforts to try new ideas. So, the company formed four teams and gave them carte blanche to act first (within the boundaries of an experimental methodology) and worry about the approval process later. They were given a two month window to design, implement and review their experiments.
One team mocked-up a new and dramatically simpler interface for selling auto insurance to private customers, and did some initial user testing. A second team designed and tested out a new home pick-up/cleaning service for drivers who had had an accident. The third team tried giving "20% time" (a la 3M and Google) to employees in two claims units (one unit also got a brainstorming room to work in), to see if the quality and quantity of new business ideas could be increased. The fourth team designed and ran a disarmingly simple study to test the hypothesis that fast-cycle feedback from customers will lead to a significant improvement in performance from salespeople (it did!).
Let's be clear. None of these experiments was earth-shatteringly original, and none of them had findings that were entirely surprising. But they all addressed real business imperatives, and they did so in double-quick time, by circumventing the formal management processes of the company. Under the normal rules of engagement, these projects could have taken a year or more, and some would have been strangled at birth. But because they were pursued under an experimentation banner, they proceeded quickly and painlessly, with all the questions and concerns put on hold until the results were in.
The company is now taking some of these projects forward, while others are not being pursued. That is the way experimentation works--you don't expect 100% success. But perhaps most importantly, the learning and insight gained from the work was immense. As the old adage has it, to really understand something, you have to try to change it.
So what's my advice to the publisher? Turn the webinar into an experiment--no permissions, no contracts, no lawyers, just a one-off event with a two-month lead time and a clear understanding of what you want to accomplish. How risky would this really be?