Switch by Chip and Dan Heath: why users understand the new system and still go back to the old way

Every FDE knows this moment. The demo went smoothly, everyone nodded through the training session, and the system runs reliably on real data. Three weeks later you check the logs and find that most users have gone back to the old way of working.

Switch: How to Change Things When Change Is Hard, by Chip Heath and Dan Heath, was written for exactly that moment. Published in 2010, it spent 47 weeks on the New York Times bestseller list. Random House Business reissued it in the UK on 22 August 2024 in a 320-page edition, ISBN 9781847940322.

The book is not written for engineers. But FDEs should read it before many books on architecture, because after go-live, what decides whether a project succeeds or fails is whether users actually change how they work.

They understand it but still don’t do it: where is the fault?

According to the authors, the main obstacle is a conflict built into the human brain. They write that our minds are governed by two systems, the rational and the emotional, and that the two compete for control. The image they use is a rider (the Rider) on an elephant (the Elephant), and the path (the Path) both travel along.

This changes how you read a failed deployment. Some people go back to the old way because they genuinely don’t know what to do, and the Rider is for them. But others understand the system perfectly well and still go back, because the elephant finds the old way familiar and safer, and the rider lacks the strength to keep steering it.

Picture an invoice-reconciliation agent you have delivered to the accounts department of a logistics client. The agent proposes matching pairs; accountants only need to approve them. Yet many still export the data to a spreadsheet and check it line by line, as before. Apply Switch’s three parts to this case and each point of failure becomes clear.

Direction, motivation, environment: three different failures

The first part is directing the rider. Umbrex’s summary of the Switch framework contains a line worth taping to your monitor: the rider needs clarity, not just inspiration.

In that accounts department, instead of saying “trust the agent”, you write down a single step: every morning, approve the high-confidence pairs first, and leave the rest for the afternoon.

The second part is motivating the elephant: the users’ emotions, energy and instincts. The book tells the story of a home-organisation expert who devised a simple technique to help people get past their dread of housework.

The story does not say where that dread comes from. But a useful reading for FDEs is to treat it as the dread of a task that looks too big. So in the first session, have accountants approve ten pairs and see themselves finish early, rather than handing them the whole batch of three thousand lines.

The third part, and the one FDEs can use most, is shaping the path. Umbrex describes the path as the working environment: processes, norms, incentives, tools, defaults and the behaviour of colleagues.

The book tells of a manager who turned a listless customer-support team into an enthusiastic one by removing a standard industry tool.

In the invoice case, this is the part you control through configuration. You can make the review screen open by default at login. You can also move the spreadsheet export button into a secondary menu. If the new way is the path of least effort, the elephant will follow it on its own.

Change does not have to start at the top

Another example from the book is worth remembering: a group of junior medical interns defeated a decades-old medical practice that was putting patients at risk.

At a client company, the person with the most senior title is usually not the one who gets a system used. That falls to a few hands-on users whose colleagues turn to them for advice.

So in the first week after go-live, find two or three of these people, sit beside them and fix whatever trips them up on the spot. Their behaviour is part of the path the rest will follow.

Read it by the three parts, not as a story

The most rewarding way to read the book is to sort each story into one of the three parts, Rider, Elephant or Path, then ask which failure at your client it corresponds to.

Spend most of your effort on the path. Read with a pen in hand, and next to each story note a matching configuration change. If you like the style, the Heath brothers have two other bestsellers, Made to Stick and Decisive.

The book suits FDEs in the post-go-live phase best, along with engineers who want to move into FDE work but have experience only in building systems.

The invoice case also hands you a number to measure. Before and after changing the default screen, count what percentage of invoice pairs are approved inside the system rather than exported to a spreadsheet.

A CV line that states the configuration change and that number, or an interview answer that tells exactly that story, says more than a list of frameworks.

A working system is only half the journey. A deployment is truly finished only when users no longer want to go back to the old way.