You know you should log the call notes before you close the meeting record. You built the workflow yourself — you know exactly where they go, why it matters, what happens downstream if they're missing. And still, at the end of a long day, with three other things pulling at your attention, the meeting record sits there with a blank notes field and a mental promise to come back to it later. You often don't.
This is not a knowledge problem. This is not a discipline problem. This is not a character flaw. This is just how human beings work — and it's exactly what Dan and Chip Heath unpack in their book Switch: How to Change Things When Change Is Hard.
Their central metaphor is one of the most useful I've encountered in years of thinking about why some operational changes actually stick and others evaporate within weeks. I use it constantly, whether or not I name it out loud. I want you to understand it, because it explains a lot about how we approach the work together.
The Rider, the Elephant, and the Path
Psychologist Jonathan Haidt first described the mind as a rider on an elephant. The Heaths adapted it as the framework for their entire book on change. Here's the basic picture:
The part of you that plans, analyzes, and knows what the right thing to do is. The Rider can build a workflow, draft an SOP, and articulate a clear strategy. But the Rider has limited willpower — it gets fatigued. When things are ambiguous or overwhelming, the Rider freezes up entirely, which looks a lot like procrastination.
The emotional, instinctive side. The Elephant has enormous power — it's what actually moves. But it resists change, seeks comfort, and takes the path of least resistance almost every time. The Elephant doesn't respond well to logic or instruction. It responds to feeling. When the Elephant doesn't want to do something, the Rider exhausts itself trying to force the issue — and usually loses.
The environment and situation — the terrain the Elephant walks through. Shape the Path well and even a reluctant Elephant moves in the right direction, not out of discipline but because it's the natural way through. This is the most underrated lever in change, and the one most operational redesigns completely ignore.
The reason most operational changes fail isn't that people don't want them to succeed. It's that the change was designed for the Rider and ignored the Elephant and the Path entirely.
What This Looks Like in Practice
"Update your CRM after every client interaction." That's a directive to the Rider. The Rider fully agrees. The Rider wrote it in the SOP and nodded at the training. But updating the CRM requires opening a second application, navigating to the right record, typing out a summary, remembering to tag it correctly, and setting the next action — when the Elephant is already gravitating toward the next task, the next email, the next thing that feels more immediately urgent. The Path runs directly away from the CRM, and the Elephant follows it every time.
Or: "We're going to change our onboarding process." The Rider builds the new flow, excited and clear on why it's better. But the Elephant has been doing onboarding the old way for four years. The old way is familiar. The new way requires learning a new sequence, filling out forms that feel redundant, and holding the discomfort of not quite knowing what to do next. The Elephant finds the new path exhausting before week two and quietly reverts.
"What looks like a people problem is often a situation problem." — Chip Heath & Dan Heath, Switch
The Three Levers That Actually Drive Change
The Heaths' prescription is direct: if you want change to stick, you have to work all three levers simultaneously. Address only one and the other two will undo you.
Direct the Rider — be specific, not motivational
The Rider doesn't need inspiration. It needs clarity. Vague directives like "be more consistent with client communication" paralyze the Rider because there are too many ways to interpret them and no clear first step. Specific directives move things: "Before you close a meeting record, type three sentences: what was decided, what the next action is, and who owns it." That's something the Rider can do. Ambiguity is the enemy of the analytical mind — the more specific and concrete the instruction, the less energy the Rider wastes figuring out what to do.
Motivate the Elephant — connect to something that matters
The Elephant moves toward things it cares about and away from things it dreads. Telling your Elephant that logging call notes is good practice doesn't move it. Connecting it to something viscerally real — like the clarity you feel when a client calls and you can pull up exactly what you discussed, exactly what you promised, exactly where things stand — that moves it. Shrinking the change helps too: the first version of any new process should feel almost embarrassingly easy, so the Elephant builds momentum before it encounters resistance.
Shape the Path — design the environment for the behavior you want
This is where most operational work either succeeds or quietly dies. If the right behavior requires more steps than the wrong behavior, the Elephant will choose the wrong behavior every time. No amount of Rider instruction overcomes a poorly designed Path. This is why I spend real time on how a CRM is configured — not just what fields exist, but where they are, what's required, what happens automatically, what prompts you to take the next step without having to remember that you should. A well-shaped Path makes the right thing the easy thing.
Why This Shapes the Way I Work With You
When I ask about the friction in your current process — "What feels annoying about this step? What's the reason people skip it?" — I'm mapping the Path. When I push back on a change that's technically correct but requires too many manual steps to be sustainable, I'm protecting the Elephant. When I insist on writing processes at a granular, concrete level rather than high-level conceptual descriptions, I'm directing the Rider.
A useful lens for any new process you're considering: Before we build it, ask — will this work for someone who is tired, distracted, and running fifteen minutes behind? If the answer is no, the process needs to be simpler. The right process works on a bad day, not just a good one.
This is also why I'll sometimes push back when a client wants to add more steps to a process that isn't working. Adding steps to a process the Elephant already resists is rarely the answer. Usually the answer is removing steps, or moving them, or making the default state the right state so that nothing extra is required at all.
You are capable of change. Your team is capable of change. But sustained change isn't a willpower achievement — it's a design achievement. Build for the Elephant, shape the Path, and the Rider can finally rest.