Years ago, I spent hours in an online forum with a group of smart, opinionated people trying to figure out what Enterprise 2.0 meant for the future of work. I typed out my argument carefully. Organizations needed a real plan to help people change their habits, I said, because a new platform on its own wouldn’t create adoption. It would just sit there, waiting for people to decide it was worth using.
I got ambushed. Their argument was that people already wanted to connect and collaborate, and that the right tool would simply unlock what was already there. Give people the platform, I was told, and they’ll find their own way to work together. Someone else went further and argued that a formal change plan would only slow things down, adding friction to something that should feel natural.
I sat there reading those replies, feeling certain they were wrong. It had nothing to do with intelligence. These were some of the sharpest people in that community, but their whole argument rested on an assumption I couldn’t accept, that handing people a new tool was the same thing as giving them a reason to change how they worked.
I stepped away from that collaboration not long after. From that point forward, every project I took on started with the same three questions. How do we want people to respond? What will hold them back from responding that way? How do we help them make that change anyway?
Looking back, we weren’t really arguing about technology at all. The debate was about whether organizations behave like predictable machines or like living, breathing systems that never sit still. The more I worked with different organizations over the years on digital transformation and communication strategy, the more I recognized what had been missing from the change management equation all along. Chaos theory.
Organizations Aren’t Machines
Chaos theory sounds like the study of disorder. It isn’t. It’s the study of complex systems that follow the rules, yet still resist precise prediction, because tiny changes create dramatically different outcomes.
Weather works this way. So do ecosystems, traffic patterns, and financial markets.
So do organizations, because organizations are made of people.
Here’s the belief sitting underneath most change management programs: organizations behave like machines.
That belief shows up in three assumptions leaders make all the time. Install the software, and people will use it. Announce the strategy, and people will align. Train employees, and behavior will change.
Every one of those assumptions depends on organizations behaving predictably. They don’t, because organizations are made of people, and people don’t respond to a rollout plan the way a machine responds to a command.
Most change plans are built around a clean, linear reaction, whether or not the leader running them actually believes it will happen that way. Announce the new system, and the plan assumes adoption follows within a quarter. Roll out the new values statement, and the plan assumes culture shifts within a few town halls. Train the team once, and the plan assumes old habits quietly disappear.
What actually happens looks nothing like that. People bring emotion into the room long before they bring compliance. They bring the memory of the last change effort that fizzled, the reorg that cost a colleague their job, the year they took a risk and got burned for it. Every new initiative lands on top of that history, and the emotional reaction almost always shows up before the practical one does. Even the best plan has to account for a version of the organization that includes all of that history, not just the org chart.
Gartner’s research on workplace change fatigue tells the same story. In a recent survey, the large majority of HR leaders said employees are worn out from the sheer volume of change coming at them, and most said their organizations need better tools to help managers lead people through it. The same research found that when managers build a psychologically safe environment, change fatigue can drop by nearly half. The history people bring into the room isn’t a distraction from the rollout plan. It’s the terrain the rollout plan actually has to move across.
The Butterfly Effect Inside Organizations
This is where chaos theory stops being an abstract idea and starts explaining things you’ve actually watched happen inside your own organization.
Think about the last time a single respected manager started experimenting with something new, like AI. It rarely stayed contained to just that person. Within weeks, an entire department was following the same path, not because anyone announced a new policy, but because one person’s behavior gave everyone else permission to try something different.
Or think about the employee who raised a genuinely good idea in a meeting, only to be told to stay focused on their actual job. That idea never went anywhere. Everyone else in the room watched it happen, and psychological safety across that entire team quietly closed off. It had nothing to do with one bad decision. It had everything to do with people now knowing exactly what would happen if they spoke up.
Harvard researcher Amy Edmondson has spent decades studying exactly this dynamic. Her original research, along with Google’s own internal study of what makes teams effective, found that psychological safety, whether people feel safe taking an interpersonal risk in front of their team, predicts performance more than the team’s composition, resources, or individual expertise. One meeting can build that safety or erase it.
The same pattern shows up with trust. One rumor starts on a Tuesday morning, and by Friday afternoon, trust across an entire team has quietly eroded, even though nothing about the underlying facts actually changed.
It shows up in workarounds too. One employee gets frustrated with a process that moves too slowly, builds a shortcut, and hands it to a coworker. Within a month, hundreds of people across the organization are using that shortcut instead of the official process, and no one ever approved it.
And it shows up in bottlenecks. One decision sits stuck with a single person or a single committee, and innovation slows across the entire organization, well beyond that one team or that one project.
None of these are isolated events. Each one is a ripple effect, and the ripple almost always travels further than the original action ever suggested it would.
Why Traditional Change Frameworks Struggle
Most traditional change frameworks trace back to a simple three-stage idea. Psychologist Kurt Lewin introduced Unfreeze, Change, Refreeze back in the 1940s, and that basic shape has echoed through change management ever since. Loosen up the current state, move people toward the new one, then lock the new behavior into place.
Later models refined the steps without changing the underlying assumption. John Kotter’s eight-step model, published in the 1990s, laid out a clear sequence that starts with building urgency and ends with anchoring new behaviors into the culture. Prosci’s ADKAR model, developed by founder Jeff Hiatt and still one of the most widely used change frameworks today, broke the individual change journey into five stages: awareness, desire, knowledge, ability, and reinforcement.
None of that work is wrong, and none of it is wasted. Kotter’s sequence still tells you how to build urgency and lock in a win. ADKAR still gives you the clearest map available for what one person needs, in order, to actually change. Any change effort that skips those questions is going to struggle no matter what framework sits on top of it.
What these models weren’t built to do is account for the ground shifting underneath the plan while it’s running. Each one assumes something close to a straight line: define the current state, define the future state, build a plan to close the gap, and execute it in order.
That’s where PATH™ comes in, not as a replacement, but as the layer that sits around that work. PATH starts with the assumption that the environment keeps changing while you’re moving through it. The destination shifts. The people shift. The technology shifts. The market shifts. Inside that constantly moving environment, Kotter’s steps and ADKAR’s stages are still exactly the tools you reach for. PATH just makes sure you’re reading the conditions correctly before you decide which of those tools to use, and how hard to lean on each one, as the ground keeps moving.
Prediction vs. Pattern Recognition
Once you accept that an organization keeps moving instead of holding still, a harder question shows up right behind it. If the environment never stops shifting, how does a leader actually know what’s coming next? Chaos theory offers a genuinely useful trade here. As systems get more complex, prediction gets weaker and pattern recognition gets stronger.
That changes the question a leader should be asking. “What happens next?” is the wrong question in a complex system, because the honest answer is usually “it depends.” The better question is “what patterns are emerging?” That question is exactly what the Assess step in PATH is built to answer, and we’ll get to the full framework shortly.
This is close to what researcher Dave Snowden has argued for years through his Cynefin framework. In complex environments, where cause and effect can only be entangled and non-linear, Snowden recommends leaders probe, sense, and respond, running small experiments to see what patterns emerge, rather than trying to analyze their way to a single right answer up front. That’s a very different posture than the one most change plans assume.
I wrote about this same principle last week in Don’t Predict the Future. Recognize the Patterns. That piece argued leaders waste too much energy trying to guess the next model, the next headline, or the next competitor’s move, instead of watching the wider patterns already forming in technology, culture, and human behavior. The leaders who get ahead aren’t the ones who guess correctly. They’re the ones paying enough attention across the whole system to notice a pattern before it fully takes shape. Patterns tell you where the energy in your organization is actually going, long before any dashboard does.
The Speed Limit
Technology moves at an exponential pace. Human systems don’t, and they never will, because human systems require adoption. Look at how fast AI capabilities have shifted in just the last two years. A feature that used to take a research team months to build now ships as a routine update, sometimes announced the same day it goes live. No workforce on earth adopts at that speed, no matter how good the tool is.
Adoption means people have to understand something, decide to trust it, and choose to act on it. All three have to show up together, or the whole thing stalls. Give people understanding and the ability to act, but skip trust, and you get compliance without commitment, people going through the motions until nobody’s watching anymore. Give people trust and the ability to act, but skip understanding, and you get enthusiasm without direction, people trying things that never quite solve the real problem. Give people understanding and trust, but never clear the way for them to act, and you get frustration, people who know exactly what to do and believe in it, stuck because the process, the approval chain, or the old system is still standing in the way. None of those three things can be forced onto an accelerated timeline just because the software shipped on schedule.
Research from Boston Consulting Group points to the same pattern. BCG has found that most digital transformations fail to meet their objectives, and that moving a company from the bottom third of performers to the top depends on how well it handles the people side of the equation, the operating model, the processes, and the culture, not on the quality of the technology itself.
Transformation moves at the speed of adoption. Not implementation. That’s the exact gap the Transition and Harness steps in PATH are designed to close, and it’s where we’re headed next.
Why PATH Starts with the Present
PATH doesn’t start with the present because it makes a better acronym. It starts there because it assumes organizations are complex adaptive systems, not machines waiting to be reprogrammed.
Present. Understand current conditions as they actually are, not as the org chart says they should be.
Assess. Recognize the patterns already in motion.
Transition. Guide experimentation instead of mandating compliance, often pulling in familiar tools like Kotter’s urgency-building or ADKAR’s individual stages once you know where the organization actually is.
Harness. Reinforce what’s actually emerging and working.
Look closely at those four steps and you’ll notice something. PATH isn’t trying to control change. It’s designed to influence the conditions change grows in. That’s precisely what complexity science tells leaders to do with any system they don’t fully control.
Twenty years ago, I thought I was arguing for better change management. Looking back, I was arguing for a different understanding of organizations altogether.
The biggest lie in change management is the belief that organizations can be run like machines, moving cleanly from Point A to Point B on command. A machine can be programmed that way. A person has to understand, has to trust, has to choose. Leaders who forget that difference risk more than a stalled rollout. They risk falling behind and becoming irrelevant because people, whether they’re leaders, employees, or customers, are what actually move a company forward. Any change effort that loses sight of them is building on the wrong foundation.
If you’re trying to figure out whether your organization is being led like a machine or like the living system it actually is, that’s the conversation I have with leaders every week. Let’s Talk.