5 lessons leaders should have on context for behavior change...so we stop blaming the individual
Most change is about adaptation because people will do things based on what makes sense given:
- time - tools - incentives -risks -workflows
If you don’t design to make those conditions better for the behaviors you want to change or encourage, then you are pretty much asking people to willpower away.
So here are 5 lessons I have learnt about behavior change in relation to context from all the projects I have helped leaders with in organizations:
Lesson 1: Define the behavior at the point of action
You need to be specific about what you want people to do, and ask: -who does what -when -where -with what -within how long
If you can’t say it in one sentence or statement, you are already getting an incomplete picture of the context.
Lesson 2: Treat context as the intervention
-workflows -permissions -handoffs -time pressure -governance
these factors aren’t the stuff in the background, they are the levers.
Optimizing comms but leaving some of these factors unchanged, is just playing change theater.
Lesson 3: Assume motivation problems are often system/environment problems
We forget the enabling conditions and how often we don’t account for the social and system costs of doing something new. We then use motivation and mindset as the scapegoats for an environment that makes the new behavior expensive to do.
Lesson 4: Make sure you have a solid hypothesis
At the end, what we’re trying to do is diagnose the dominant blocker and then pull the right lever. You’ll always find multiple blockers. The skill is prioritizing the one that matters most..and that you can actually influence
Lesson 5: Design for scale, not just adoption
Most initiatives or projects don’t live up to their potential because the conditions that made them work in a pilot don’t end up being exposed to the the real system.
At scale, context changes things like:
-governance and approvals adding weeks, not days -managers expected to reinforce things, but nothing gets removed from their workload -people leaving and taking the know-how with them
So if you can’t influence or change what will break things beyond a pilot you wont be ready to really scale it in the org.
Bonue: - Here is a quick 60-second context check: -Fit (does it work in real workflow?) -Readiness (capacity/skill/support?) -Delivery (where will it run into problems?) -Sustainment (what reinforces after launch?)
If your change work depends on people being unusually motivated, then you have to redesign some of the conditions.