A Swiss watch does not lose a second, not because someone hopes it will work, but because every single gear is measured, tested, and built to move exactly the way the next gear needs it to. Most change management projects do not run that way. They run on hope wearing a project plan: training gets scheduled, the communication strategy is all set up, the leadership says the right things on the townhall call, and then everyone crosses their fingers after go-live and hopes adoption happens.
But, can change management run with a Swiss watch precision? Yes. How? Well, it starts by getting a lot more specific than most change plans ever bother to. And if you have ever led a change initiative, you know exactly what I mean, because you did everything the playbook said, hit every milestone on the plan, and it still did not run like a Swiss watch. It ran more like hope. That gap between what should have happened and what actually did is real, and it has a name: I call it a microbehavior.
What do I mean by Microbehavior?
Every established change framework hands you a clean, well-tested set of instructions. Prosci’s ADKAR model breaks individual change into five building blocks: Awareness, Desire, Knowledge, Ability and Reinforcement[1]. Kotter’s model, first published in his 1996 book Leading Change, lays out eight steps from establishing urgency to anchoring the change in culture[2]. Both are well-tested, widely used, and as far as they go, correct. Both also tell you what conditions need to exist for a change to succeed but what they lack is a way to state, in the smallest possible terms, what a person is supposed to do differently on an ordinary Tuesday, and that is what I mean by microbehavior: the change written at the resolution of an actual action, not a goal.
The term itself is not new and I am borrowing it. It traces back to Mary Rowe’s work at MIT on “microinequities,” the observation that formal equal-opportunity policy could not explain persistent workplace inequality because the real mechanism lived in thousands of small, often unconscious daily interactions no policy could see[3]. That idea later became “micro-messaging” and eventually “micro-behaviors” in diversity and inclusion practice. I am applying the same logic to a different problem: change adoption instead of inclusion.
Let’s deep dive into this: if the goal is “Sales Team to adopt the new CRM.” One possible microbehavior tied to it could be “Log the call outcome in the new CRM before starting the next call, instead of writing it on a sticky note first.” Another example could be: “Procurement Team to use the new approval process within the tool” is the goal, then the microbehavior could look something like: “Issue the PO only after the tool shows approval, instead of issuing it with a verbal confirmation from the manager.”
The test I use with clients is simple: if you can’t write the microbehavior down as a specific, observable action, you haven’t finished diagnosing the change. You’ve described an outcome you want, but skipped the step where you figure out what has to happen differently inside someone’s actual workflow to get there. That is usually where the diagnosis breaks down, because your new microbehavior has to compete with an old habit that is already built into the ordinary Tuesday workflow.
This is not a replacement for ADKAR or Kotter. It is a layer underneath them. Awareness and desire tell you whether someone is willing. The microbehavior tells you whether you have actually specified what “willing” is supposed to produce.
You do not need all of them, just the right few
The moment people hear “define the change at the level of individual behaviors,” they brace for a nightmare: a spreadsheet with ten thousand rows and no one left with time to actually run the change. That reaction is fair, and it is also based on a wrong assumption, that specificity means exhaustiveness.
Well, it does not. Because you do not need to map every microbehavior a change touches, but you do need to find the handful that are blocking adoption from happening and leave the rest alone.
Stanford researcher BJ Fogg’s Behavior Model gives a clean way to find them. His formula, B=MAP, says a behavior happens when Motivation, Ability, and a Prompt converge at the same moment[4]. His most useful finding for this purpose: raising Ability, making a behavior easier to do, is almost always a more reliable lever than raising Motivation, because motivation fluctuates and ease does not. So, you do not need to redesign every behavior in a rollout; you just need to find the ones where Ability is lowest today, where the new way is still harder than the old habit, because those are the only ones actually at risk of losing.
That also answers the sequencing question: some microbehaviors are prerequisites for others: a rep has to log a sale in the new system before a manager can approve anything through the same system. Map those dependencies and the priority order mostly falls out on its own; you fix the behavior something else depends on first, not the one that looks most important on a slide.
That short list pays off twice: at execution, it is the only version of this that is actually usable before a go-live date and at measurement, each microbehavior on it answers one question: does it leave a trace in the system? “Log the call outcome in the CRM” does, so you pull it from the system of record and catch a deviation in days, not six months later in a survey. “Raise a concern with your manager instead of staying quiet” does not, so it does need a qualitative check instead: an interview, a pulse survey, something built for judgment, not counting. A vague adoption plan produces a vague metric. A short prioritized list produces exact ones: a specific number from a specific system for what can be counted, specific questions to specific people for what can’t.
The point is not to add another framework
The point of finding specificity is not to complicate the workload or add pointless work. It means being able to find the few behaviors where the old habit still wins, defining those precisely, and letting the rest of the change take care of itself. That is the piece that tells you whether your plan is actually ready to succeed, or just ready to look finished. It is also the argument I make at length in my book, on why organizations so often mistake compliance with a framework for actual transformation.
This is the first cut into a much larger piece of fabric, not the whole garment. Ideas like this don’t get sharper by one person defending them. Instead, they get sharper when other practitioners bring their own cases, push back on the parts that don’t hold, and add what is missing. I would rather see this framing improved by people smarter than me than treat it as finished.
Notes
- Prosci, “The Prosci ADKAR Model,” prosci.com/methodology/adkar ↩
- John Kotter, Leading Change (Harvard Business Review Press, 1996); Kotter Inc., “The 8-Step Process for Leading Change,” kotterinc.com/methodology/8-steps ↩
- Mary P. Rowe, “Barriers to Equality: The Power of Subtle Discrimination to Maintain Unequal Opportunity,” Employee Responsibilities and Rights Journal, Vol. 3, No. 2 (1990). ↩
- BJ Fogg, Tiny Habits: The Small Changes That Change Everything (Houghton Mifflin Harcourt, 2019); “Fogg Behavior Model,” Stanford Behavior Design Lab, behaviormodel.org ↩
Want help mapping the microbehaviors in your own program?
This is the same lens I use in the Behavioral Adoption Diagnostic — finding the handful of behaviors actually blocking adoption, before a program burns its go-live date on the wrong ones.