Over the last couple of years much of my work has been about change in one form or another. There are endless tomes dedicated to the subject: helping making it happen, helping people cope with it, change in a business context, change in a personal context; the list goes on and on. What has come to fascinate me about change is not anything in the list above but simply the ‘tipping points’ of change, of which I think there are two critical ones.
There needs to be recognition or acceptance that change is necessary. This is the first tipping point, and the easier one as ‘facts and figures’ can often show something isn’t working or can work better. This is often the impetus for some form of project to begin. These projects – long and short – are solution-finders, intended to understand the problem (or opportunity) and find a way of overcoming (or exploiting) it. The second tipping point is at the culmination of such projects; actually taking the results and doing something with them. In my experience, this is often the one people find hard, and especially where the change needed is not evolutionary in nature, but revolutionary.
Evolutionary solutions build on what is in place already; they improve current processes and approaches, make them more streamlined etc. Think of the changes to engine efficiency in cars. The need to reduce fuel consumption and emissions has led to significant improvements, but the fundamentals of the engine have remained broadly the same. These improvements have been evolutionary in nature. Sometimes, though, it isn’t possible (or is sub-optimal) to address an issue with such an evolutionary approach; there is a need for something more radical, more revolutionary in nature. This type of change can start from a blank page and go back to basics: the electric car is a revolutionary change to address fuel efficiency.
Here’s the kicker, though: as the electric car example highlights, revolutionary change is significantly more complex and inherently more risky than evolutionary. It is far less ‘familiar’ to people, and I think it is this lack of familiarity that causes many of the difficulties in getting such radical change successfully implemented, let alone embedded.
A number of the projects I’ve been involved in have been tackling ‘endemic’ issues; by this, I mean issues or problems that have been around for so long in one form or another that they are no longer the exception to the rule, but rather have become embedded in how people work. In some strange way people often become comfortable with these problems, because working with or indeed around them has become a matter of routine and people find comfort in the routine. When a new approach changes that routine it often makes people uncomfortable, even when the change might remove a problem or improve their working or personal lives. In these cases, a ‘coping mechanism’ seems to come into play – compromise. Faced with significant change, there is often a desire to maintain an element of the status quo so that the familiar still exists, so that it doesn’t feel quite such a risk and departure from normal business as usual. In the case of evolutionary change, this is not so much a problem; the change is after all based on building upon what is there currently.
In the case of revolutionary change, however, such compromise can be potentially crippling: it’s like trying to swim whilst keeping one hand on the side of the pool.
The basis of much revolutionary change is in establishing a new way of working that removes old issues or creates significant improvement capacity. Its strength is often in taking that blank sheet of paper view and starting more closely from scratch. (This is not to suggest totally from scratch; that is rarely a realistic option.) Compromise – reducing the extent of impact, preserving some old processes etc – is often seen as a risk-reduction approach or a way of winning people over and creating buy-in: the ‘watered down’ version is accepted as having potentially less benefit, but it is easier and still delivers good value. Unfortunately, this often isn’t the case.
The irony is that compromise can create a self-fulfilling prophecy for failure: we need to preserve some of the past because this new approach is risky and might go wrong; compromise protects us from risk. In fact, such compromise can expose companies to risk: it makes revolutionary solutions more likely to fail. Naturally, if they do fail everyone is relieved they kept a fallback position, whereas the question that should be being asked is “did it fail because we kept that fallback?”
Such compromise is difficult to avoid without consistent senior management support and buy-in. That sounds like a mantra for all change, but the reality is that most evolutionary change can be justified on the basis of numbers alone: the figures generally add up so managers can be very confident that the change is the right thing to do. Revolutionary change is greater risk / reward, and is harder for managers because it often requires a leap of faith. Rarely is it certain that a solution is the best solution, that all avenues have been explored, that all risks have been minimised, that something horrible hasn’t been overlooked; these all create doubt, doubt creates desire for the reassuringly familiar, this desire leads to compromise, and compromise can lead to failure.
This may seem like I’m unsympathetic towards senior managers; this couldn’t be further from the truth. Whilst all this change is going on, the business still has to be run, budgets need to be managed, targets met; adding the risk of significant change to this is a tough choice (and anyone that tells you change isn’t risky is fibbing – it can be managed, but it inevitably adds risk). What I’ve learnt is that compromise is often seen as getting the best of both worlds, whereas the reality is that it often gets the worst of them.
Not compromising can look inflexible, but it doesn’t need to be. Simply establish core design principles (CDPs) and ensure these are carved in rock: these are the untouchables that the change must deliver. There can be discussion about other aspects – within reason – but the CDPs are not up for grabs. If there isn’t enough confidence in a solution or the impetus for change to establish such design principles and stick by them, it’s probably better not to undertake the change at all.
