Why This Book, Why Now
I'm currently in the middle of a large-scale merger between two companies. Unlike the typical acquisition playbook (buy competitor, consolidate, lay people off), this one has a clear and exciting destination: building a pan-European product together. The challenge is real, but so is the shared ambition.
That said, in my 20+ years in tech, this is my fourth major merger or acquisition. Every single company I've worked at was eventually acquired by a larger one.
The results varied wildly: some were smooth, some were brutal, most landed somewhere in between. After living through that many transitions, you start noticing patterns in what makes change stick and what makes it collapse.
"Switch" by Chip and Dan Heath finally put names on those patterns.
The Core Model: Rider, Elephant, Path
The authors use a metaphor borrowed from Jonathan Haidt: a Rider on top of an Elephant, walking down a Path.
| Component | Represents | Challenge |
|---|---|---|
| The Rider | Our rational, analytical side | Overthinks, overanalyses, gets paralysed by decision fatigue |
| The Elephant | Our emotional, instinctive side | Seeks comfort, avoids pain, needs motivation to move |
| The Path | The environment, context, and systems around us | If the path is unclear or difficult, even a motivated elephant with a focused rider won't move |
Change fails when you only address one of these. You need all three working together. Here's the full framework at a glance:
| Strategy | Tactic | One-liner |
|---|---|---|
| Direct the Rider | Find the Bright Spots | What's already working? Do more of that. |
| Direct the Rider | Script the Critical Moves | Don't think big. Think specific. |
| Direct the Rider | Point to the Destination | Show where you're going. Make it vivid. |
| Motivate the Elephant | Find the Feeling | Make people feel the need for change. Appeal to identity. |
| Motivate the Elephant | Shrink the Change | Make the first step tiny. |
| Motivate the Elephant | Grow Your People | Upskill, build confidence. The flip side of shrinking the change: make the people bigger. |
| Shape the Path | Tweak the Environment | Make the right thing the easy thing. |
| Shape the Path | Build Habits | Automate the new behaviour. |
| Shape the Path | Rally the Herd | Show that others are already on board. |
Now, the parts that really stuck with me.
What Looks Like a People Problem Is Often a Situation Problem
This is probably the single most important takeaway for me. And it applies everywhere: at work, in public, with your teenagers.
We fall into this trap constantly. When we mess up, we know the context. We were tired, under pressure, missing information, short on time. We rationalise. But when someone else does the same thing? We jump straight to character: they're lazy, careless, sloppy, or worse, malicious.
This is the Fundamental Attribution Error in action. We attribute other people's behaviour to who they are, not to what they're dealing with.
I've long believed in assuming best intent:
assume that people are doing their best given what they know, the skills they have, and the time available to them.
When you adopt this lens, the question shifts from "why is this person so unreliable?" to "what about the situation made this outcome likely?"
That said, I'm not claiming I always manage to see things this way. I'd love to, but I'm absolutely prone to the Fundamental Attribution Error myself. I get frustrated when colleagues are sloppy. I snap at my teenagers for being "lazy and ungrateful."
The default is strong. But at least now I catch myself more often.
This connects directly to blameless postmortems. If an incident occurs and your 5-whys analysis points to a specific person, you haven't found the root cause. You've found a symptom.
The real cause is almost always organisational: a missing guardrail, a process that allowed the mistake, a lack of automation, an environment that made the wrong action easy (or the right action harder).
That's "Shape the Path" from the Switch framework. If the path is poorly designed, blaming the person walking it is lazy thinking.
In platform engineering, when a team deploys a breaking change to production without testing, the real questions are:
- Was there a CI pipeline that should have caught it?
- Were there environment protections in place?
- Was the deployment process so manual that human error was inevitable?
Fix the path. The people are usually fine.
What Looks Like Resistance Is Often a Lack of Clarity
When you announce a change and people push back, the instinct is to label them as "resistant to change." But most of the time, they just don't understand where you're going or why.
As a leader, you've been thinking about a change for weeks or months. By the time you present it to your team, it feels obvious to you. But for them, it's brand new. They're hearing it for the first time in a 30-minute sync. They might be afraid to ask questions. They might nod along while internally thinking "but what does this mean for me?"
Our job is to be explicit about the direction and check for real understanding.
"Does this make sense?" is a weak question because nobody wants to say no. Better: "What questions do you have?" or "What's unclear about how this affects your work?"
If your people can't describe the destination back to you in their own words, you haven't communicated it clearly enough. And if they can't see the destination, of course they won't move. It's their rational response to ambiguity.
Knowledge Does Not Change Behaviour
This one is incredibly relatable for me. I'm a very logical person (or at least I like to think of myself as one). My default is to believe that if I provide the right arguments, the right facts, the right data, I can persuade people without resorting to manipulation. Just pure logic. That's naive.
There's a meme that captures this perfectly:
Painfully true.
Logic and data are not enough (often they are, sadly, even irrelevant).
You can be right about everything and still fail to create change, because being right only addresses one third of the equation.
They speak to the Rider. But the Rider is sitting on top of a six-tonne Elephant that doesn't care about your facts.
Below the surface lie emotional attachment to the status quo, fear of the unknown, identity, comfort, and social belonging.
See, Feel, Change
We assume change follows a rational sequence:
- analyse the problem,
- think about the solution,
- change behaviour.
But that's not how people actually change.
The real sequence is:
- see,
- feel,
- change.
You see something - a demo, an example, a consequence. It makes you feel something. And that feeling moves you to act.
Showing a team their incident count on a chart? Nothing happens. Walking them through the 2am Slack thread where someone was debugging alone for three hours while everyone slept? That moves people. Same information, completely different impact.
The Engineer's Bias: Pessimism and Bright Spots
Engineers are pessimists by design. We're trained to find flaws, anticipate failures, and fix what's broken. That's literally the job. And that's a good thing; the world needs people who think this way.
We need to push back on toxic positivity.
(I wrote a whole article about this: Are good software engineers Pessimists?. And a talk: Focus on the positive! - No! the world needs more pessimists! )
But this mindset, while essential for building reliable systems, is actively harmful when introducing change. When you ask an engineering team "how's our deployment process?", you'll get a list of everything that's wrong. The Rider loves this. Problems to solve!
The authors of Switch point out something counterintuitive: if you only focus on problems, you miss the bright spots. The things that are already working. The one team that somehow deploys daily without incidents.
Appreciative Inquiry
The book references Appreciative Inquiry, a formal methodology for changing organisations by studying what's working rather than what's not. It flips the question:
- Instead of "why do our deploys fail?" ask "when deploys go smoothly, what's different?"
- Instead of "why is onboarding so slow?" ask "who onboarded quickly, and what did their experience look like?"
When you focus on problems, you get a list of things to fix. When you focus on what's working, you get a blueprint to replicate. Often it's more effective to amplify something that already exists rather than fighting against everything that's broken.
Suddenly, if you focus on the bright spots, you are good to go on all 3 aspects of the framework:
For the Rider, it reduces complexity.
For the Elephant, it provides hope.
And for the Path, it gives you a real, working template to copy.
The Miracle Question
One of the most elegant techniques in the book, borrowed from solution-focused therapy:
Imagine you go to sleep tonight and a miracle happens. When you wake up tomorrow morning, all your problems are gone. What's the first small sign you'd notice that tells you the miracle happened?
You're not asking someone to describe the miracle itself. You're asking them to identify the tangible signs that it's been solved. "I'd open Slack in the morning and there wouldn't be a thread about a failed deploy." (yeah well, my tendency would be checking if alerting is actually working or if there is an issue in slack. but you get the point..)
It reminds me of a technique I've seen used in 1:1s and onboarding:
"If you had a magic wand, what's the one pain point you'd make disappear?"
Same mechanism. People don't answer with grand visions. They answer with small, observable things:
- "Teams would just adopt the security fixes without me chasing them for months."
- "I'd have the mandate to enforce governance standards directly, instead of begging and nagging."
- "We wouldn't be the gatekeepers for every infra change that teams supposedly own. They build it, they run it, but somehow we still review and carry the responsibility."
Those small signs tell you exactly what to fix first.
TBU: True But Useless
This acronym immediately entered my vocabulary. You present a plan for change and the feedback starts rolling in:
- "Not everyone on the team has the same level of Terraform experience."
- "Every product has a slightly different setup."
- "We've never had time to fix this, what makes you think we will now?"
Every single statement might be true. But they're useless in the moment. They're paralysing knowledge. They add weight without moving anything forward.
This is where the Elephant comes to a halt. When every conversation adds more complexity, more reasons it won't work, the Elephant gives up. "This is too big. We'll never get there. Why bother."
The antidote is "shrink the change." Yes, there are 47 things that need fixing. We're doing one. What's the smallest move that creates progress?
The art is acknowledging the complexity while refusing to let it become an excuse for inaction.
"True, noted, parked. Now: what's our next step?"
Lower the Bar to Raise the Bar
As leaders, we talk constantly about raising the bar. Higher quality. Better processes. More rigour. But to get the Elephant moving, you need to do the opposite: lower the bar on the first step.
You want your team to adopt infrastructure as code across 13 products. If you say "we're going to terraform everything," the Elephant sees a mountain and sits down. Instead: "Let's terraform one service in one environment. Just ECR. This week."
That's achievable. The Elephant starts moving. And once it's moving, momentum builds. The bar rises naturally because the team has seen it work and believes the next step is possible.
You're not lowering your standards or your destination. The destination postcard doesn't change, but the first step towards it needs to be small enough that people actually take it.
Inch Pebbles, Not Milestones
The book offers a lovely reframing: if milestones feel too distant, look for inch pebbles. Tiny markers of progress.
I love this kind of linguistic reframe. It reminds me of something I heard at InfoQ Munich last autumn about using your own platform as your users would. The common term for that is "dogfooding," which is inherently negative; who wants to eat dog food? The alternative someone proposed: "drinking our own champagne." Same practice, completely different energy. (and more focus about our valuable work).
Words shape how we feel about things. And how we feel determines whether the Elephant moves.
Furthermore, small wins compound. Each tiny success gives the Elephant evidence that progress is real, reduces the perceived distance to the destination, and creates social proof for the rest of the herd.
Growth Mindset and the U-Shaped Curve
This was my favourite chapter. The growth mindset versus the fixed mindset is something I connect with deeply as a climber. When you look at a wall, you know the top is the goal. But you don't think about the top. You think about the next move. One foot, one arm, the next hold.
It's the same with skateboarding, snowboarding, slacklining. Every sport I've loved shares this quality: they never end. There's always a harder version. You focus on the small move, you fail, you try again. Failure isn't a bug; it's the mechanism by which you improve.
The Emotional U
The book describes an emotional curve shaped like a U:
- At the beginning everything feels possible. There's Hope.
- At the end you gained Confidence - You've come through. Skills are built. You know you can do this.
- but in the middle, the dip: the challenge is bigger than expected, your motivation drops. This is where most change efforts die. But where all the Insights lie.
If you don't tell people about the dip in advance, they'll interpret it as failure rather than progress.
Unflaggingly Optimistic, Not Toxically Positive
The paradox of the growth mindset: it draws attention to failure, encourages seeking it out, and yet it's deeply optimistic.
Not "everything will be fine!" (the Rider won't believe you).
Not "this will be painful" (the Elephant gives up).
Rather: "This will be hard, and we're capable of hard things."
"Not Yet"
One of the most elegant examples in the book is about teachers of a difficult class who replaced bad grades with two words. Not yet.
An F says "you failed." Final. The fixed mindset hears: "you're not good enough."
"Not yet" says: "you're on the way. Keep going." It implies a trajectory, not a judgement.
Identity Over Goals
The identity piece connects directly to James Clear's Atomic Habits. People set goals: "I'll go to the gym once a week." Some succeed through sheer discipline, forcing themselves all the way to December 31st. But then the goal is achieved, the constraint removed, and they drift back to the default.
The alternative: connect the behaviour to an identity. Not "I want to go to the gym" but "I want to be a fit person."
I want to grow old and still play with my grandchildren. I want to spend retirement travelling the world, not in a care home. That's not a goal; that's an identity. And identity persists long after any specific goal expires.
In engineering teams:
- "We leave things better than we found them" (identity) vs. "close 10 tech debt tickets per sprint" (goal)
- "We're the team that makes other teams faster" (identity) vs. "reduce ticket response time to 24 hours" (goal)
- "We build infrastructure that lets people sleep at night" (identity) vs. "achieve 99.9% uptime this quarter" (goal)
- "We learn from incidents" (identity) vs. "write a postmortem within 48 hours" (goal)
We said already that data is irrelevant to the Elephant. The elephant cares about "this is who we are."
Reinforcement: Feed the Snowball
Finding the bright spots convinces the Rider that progress is possible. But to keep the switch going, you need sustained reinforcement.
As engineers and managers, our default is to notice what's broken. That's useful for debugging systems, but it's poison for sustaining change. If there's a change you're executing, you need to intentionally flip that default.
Identify every single thing that's getting better. Name it. Say it out loud.
Just be careful to not become condescending. It must be genuine and honest recognition of movement: "Last month we had zero modules in the shared library. Now we have three. That's real." (and that's good, although we might have expected 5 )
Change isn't an event. It's a process. And to lead a process, you need persistence. Without sustained reinforcement, entropy wins and people drift back.
As small wins compound, small changes snowball.
Once momentum builds, it becomes self-reinforcing.
The Framework, One More Time
What I loved about the book's structure: every chapter ends with the same clear repetition. It drills the pattern in until it becomes second nature. Three questions for every change:
Is the direction clear enough? (Rider)
-- Point to the destination.
-- Script the critical moves: not every step, just the key milestones that mark the route.
-- Find the bright spots.Is there emotional energy to move? (Elephant)
-- Find the feeling. Appeal to identity: "this is who we are."
-- Shrink the change so the first step is achievable.
-- Grow your people so they outgrow the challenge; the flip side of shrinking the obstacle is making the people bigger.Is the environment making it easy? (Path)
-- Tweak the environment.
-- Build habits.
-- Rally the herd.
If the answer to any of those is no, you've found your bottleneck. Fix that before blaming the people.
Final Thoughts
One of the best books I've read in a while, as both a manager and a parent of teenagers. It will stay on my desk, not buried in the bookshelf and it's something I'll come back to regularly.
One honest note: Like many books in this genre, it gets repetitive in places. There are plenty of extended examples from managers, professors, and operations people. Some of them drag. But if you push through, they illustrate the concepts well. The repetition is also part of what makes the framework stick.
Highly recommended. Especially if you're in the middle of a change. What are you trying to change?
Other articles that you might find interesting:
Top comments (0)