Like their previous book, “Made to Stick”, the Heath Brothers, Chip and Dan have another insightful title in “Switch, How to Change Things When Change is Hard”.
It’s really work reading in full but to summarise, it covers a strategy to manage the dichotomy of our minds: our rational side and our emotional side. The Heath Brothers prefer to use the more colourful analogy first introduced by Jonathan Haidt, in “The Happiness Hypothesis”, namely the emotional Elephant and the rational Rider.
The weakness of the Elephant, our emotional side is evident: looking for the quick payoff rather that the long term goal. When attempts to change fail, it’s usually the Elephant’s fault but it can also be as a result of the rider not being able to control the Elephant long enough to reach the destination.
The book sets out a three-part framework for change:
Direct the Rider: What often looks like resistance is in fact a lack of clarity. So there is a need to provide crystal-clear instruction.
Motivate the Elephant: What looks like laziness is often exhaustion - a put upon Elephant by a forceful Rider. It’s critical that you engage with people’s emotional side, get them connected and on the path to cooperation.
Shape the Path: what may look like a people problem is more likely a situational problem; what is the Path? When the path is clear and well defined change is more likely.
I’ve a background in IT and software development which could readily benefit from the framework. I’ve often heard developers say, “our biggest problem is users” but is it? Developers fall in love with their code and don’t like feedback from testers and as a result any changes arising from testing are mere “tweaks”. How does the framework effect the change and align software releases much closer to the customer’s needs?
Direct the Rider: Set the scene. Point to the destination of a celebration of a successful software package. This certainly floats the developer’s boat with the peer appreciation (and CV content) it brings. Set out the steps to get there: closer understanding of the end user, better appreciation of their needs, features that the customer needs not those the developer wants to develop.
Motivate the Elephant: Get out and get on. Get the developers out of their cubicle and next to users to experience the issues first hand. See the user’s pain. Experience their frustration. Put a name to the issue: Steve’s problem, Carrie’s confusion.
Shape the Path: Many developers have the best of equipment, unlike the end user who may have had his technology for a number of years. Swap the best for the common and then you are truly developing for your user and you will more easily create a solution that delivers.
There are many more gems in the book and here is Action University’s take.
As a friend of Action University, I’m privileged to be able to offer you the summary as a download. You can find it here.
So, have you made a Switch? Would the framework have helped? Do you have examples where you have motivated your elephant? I’d love to hear.