You Cannot Change the Fruit Without Changing the Seed

Every situation you face — a market shift, a difficult report, a resignation letter on your desk — is just raw data. What turns that data into a decision is a pattern: the lens you use to interpret what your senses, your intuition, and the facts in front of you are telling you. Two executives can look at the same falling number and reach opposite conclusions, because the number itself carries no meaning. The pattern supplies the meaning.

This matters more than it sounds like it should, because our patterns don’t just interpret events — they define who we are and where we’re headed. The way you perceive, decide, and learn today sets the trajectory of your future, given your unique lens and whatever your environment throws at you next. Change the pattern, and you change the trajectory. Leave the pattern alone, and you can rearrange everything around it — org charts, reporting lines, software, policy — and still end up back where you started.

This is why change management is so hard, and why it’s hard for the same reason it doesn’t stick. Most change programs work on the branches: new process, new dashboard, new escalation policy, mandatory training. All of that operates downstream of the pattern. The seed — how people actually interpret risk, what “bad news” means to them, what gets rewarded when they stay quiet — never gets touched. So the new process gets adopted for a quarter, and then the org quietly reverts to the pattern it always had, because the pattern was never the thing being changed. You can’t grow a different fruit from the same seed.

What this looks like when it works

Look at history’s clearest cases of pattern change. Ashoka, Mother Teresa, Gandhi — all ordinary people for most of their lives, who became extraordinary only after an event extreme enough to alter them at the core. Ashoka didn’t become a different kind of ruler because someone handed him a new policy manual after Kalinga. The devastation he’d caused rewired how he interpreted power itself — what it was for, what it cost, who it served. Once the pattern changed, the decisions that followed changed on their own. No one had to enforce them.

That’s the marker of a real pattern shift: the new behavior stops needing enforcement. It’s no longer compliance. It’s just how the person now sees things.

What this looks like in your organisation

Take a change program you’ve actually run — a new operating model, a new ERP, a new reporting cadence, doesn’t matter which. If it only changed what people were told to do, you got compliance for as long as you were watching, and drift the moment you weren’t. I’ve watched this play out in program after program: leadership rolls out a new escalation policy after a project blew past budget, everyone follows it for two steering committee cycles, and by the third, status reports are green again — not because the underlying risk disappeared, but because nobody actually changed how they interpreted what “on track” means. The policy changed. The pattern that produced the last failure didn’t.

Now compare that to the rare case where it holds. The organisations where a change actually sticks are the ones where leadership went after the pattern first — what does bad news cost the person who reports it, what does a real answer to “how’s it going” actually sound like, what gets someone promoted here. That’s a harder and slower conversation than rolling out a new template. It usually only happens after something extreme enough to force the question — a program failure big enough that no one can pretend the old pattern still works. Which is, uncomfortably, the same mechanism as Ashoka’s.

So the question worth sitting with isn’t “what should we change.” It’s: what pattern produced the thing you’re trying to change — and are you willing to work on that, or just on what grows from it?