The Two-Minute Change That Changes Everything
Small Moves That Shift Everything
Most change efforts fail for a simple reason. They ask people to do too much, too soon, in systems that quietly reward the old way of working.
New frameworks arrive. New language spreads. Training happens. People genuinely want to improve. And then real work shows up, pressure returns, and behavior snaps back to what the system already supports.
That does not mean people are resistant. It means the change never reached the level where behavior actually lives.
I’m focusing the next four posts on The Do for a reason. This is where theory becomes visible in action. Not through big plans, but through small moves that reliably show up in real work.
Why Two Minutes Matters
During the last series of posts, I focused on seeing systems clearly.
Once you start developing that “seeing” mindset that those posts discuss, you start paying attention to what actually happens rather than what people intend. You will then notice something important. Most meaningful change does not begin with a large intervention. It begins with a tiny adjustment to an existing loop.
Two minutes is not a motivational trick. It is a design constraint. If a behavior cannot survive two minutes of friction, it will not survive a stressful day, a deadline, or a production incident.
Two-minute changes work because they fit inside the system as it already exists. They do not require belief. They do not require permission. They do not require a meeting.
They show up quietly and repeatedly, which is exactly how real change takes hold.
Keystone Behaviors, Revisited
Last Autumn, I wrote about keystone behaviors. These are not habits in the motivational sense. They are leverage points. When one small behavior shifts, many other behaviors move with it.
Keystone behaviors are never abstract. They live in observable work.
In technical teams, they show up in pull requests, commits, reviews, handoffs, and how people respond when things go wrong. If you want to change outcomes, you have to work backward from those artifacts.
The mistake many leaders make is trying to change outcomes directly. Faster delivery. Better quality. Fewer incidents. Stronger ownership.
Outcomes do not change themselves. They are produced by loops of behavior to achieve an outcome.
How Loops Actually Work
Let’s look at pull requests. Every pull request is fed by inputs (the commits). Those inputs come from repeated loops that people move through dozens of times a week, often without noticing.
A loop might include how work is started, what signals safety or risk, what gets rewarded, and what gets quietly avoided. These loops shape behavior far more than any stated standard.
If you want to change what shows up in pull requests, you do not start by rewriting guidelines. Instead, change the input - the commits in the PR that people review. You start by noticing the loops that reliably produce the current state.
This is where microbehaviors matter.
A microbehavior is a tiny nudge inside an existing loop. It’s something that takes a couple of minutes and slightly alters what happens next.
When designed well, a microbehavior does not fight the system. It uses the system.
What This Post Is Not Going to Do
I am not going to give you a generic list of behaviors to copy. That rarely works because the leverage point depends on the system you are working in.
What I will say is this. If you can trace a line from an outcome you want to change, back to the repeated loops that feed it, you can almost always find a two-minute intervention that starts to shift the pattern.
That skill is learnable and teachable.
What Comes Next
This month is about doing, not discussing. Each post will stay grounded in small, field-tested moves that survive real-world pressure.
If you want structured support in learning how to identify keystone behaviors and design microbehaviors that work across teams, the public masterclass running in April and May is built specifically for that purpose.
We spend time observing real systems, practicing how to spot leverage points, and designing interventions that show up in actual work, not just plans.
Change does not start with a transformation roadmap. It starts with a two-minute move that quietly shifts the system underneath it.
Behind the paywall, I walk you through a short activity designed to help you find a two-minute change in your own context.
The activity starts with something concrete you want to change in real work, and how to nudge the system without disrupting it. The goal is not to fix everything. The goal is to find one move that actually shows up.
If you are a coach, a manager, or a technical lead, this is the kind of practice that builds real skill in designing change that sticks.
