The Ultimate Guide to Organizational Behavior Change - Part 2: Mastery
Robert Meza · Feb 2026
Hi there, I’m Robert. I write about behavior change in organizations.
For more: aimforbehavior | Training | SHIFT Method
This is Part 2 of a series for people working on change and transformation in organizations. Part 1 covered Meaning — the sense-making mechanism that makes a change feel legitimate. If you haven’t read it, start there. The three conditions build on each other.
In Part 1, we ended with this: Meaning provides the ‘why,’ but for change to sustain, it must be supported by Mastery and Belonging. When either is missing, organizations compensate with pressure, monitoring, or incentives, and the change becomes less sustainable.
Now we’re picking up exactly where we left off.
We’re covering Mastery second because once people understand why a change matters, the next thing that determines whether they move from understanding to action is whether the system makes them feel capable of actually doing it.
To clarify, Mastery is the psychological state of feeling effective, capable and in a state of progress during organizational change. In Self-Determination Theory terms, it’s closely related to the need for competence.
Training isn’t the enemy here... it’s necessary but insufficient. If Mastery is weak, training becomes the messenger for incompetence.
Let’s start with simple example:
Two equally resourced teams receive the same training for a new workflow. One team starts experimenting within a week, asking practical questions, making mistakes, adjusting. The new behaviors start becoming part of the routine … the other team goes quiet, and while people attend trainings, they end up going back to doing things the old way… why does this happen?
It’s clear that many things are needed for change to sustain, one of the things that is very important after Meaning is established is Mastery, specifically, whether the environment makes the change feel achievable or whether it feels like something that will make it impossible.
That distinction matters because even when people understand and accept the why of the change (strong Meaning), they will not move to action if they don’t believe they can actually do it. Mastery is the thing that moves people from “I see why this matters” to “I can do this, and I’m getting better at it.” I always like to give a video game analogy here, if the game is too easy you get bored, if its too hard you get frustrated… in an organization, understanding without capability produces anxiety, not adoption.
Your Mastery Tools (copy/paste)
If you want to use this as an actual playbook (not just an article), here are the things to take from it:
Mastery roadblocks audit: the fastest way to stop competence frustration and prevent learned helplessness.
Role-level capability map: the template that forces you past “we did the training” and into daily readiness.
Learning check-in: a meeting structure that surfaces real capability gaps without turning into a complaints session.
45-minute Mastery session: a one-team working session that produces outputs you can act on.
Feedback language swaps: scripts for informational feedback without judgment or surveillance.
You’ll find each tool in the sections below.
What I mean by Mastery
Mastery is the moment someone moves from following instructions to actually knowing what they’re doing to getting really goo at it, and it happens when the environment provides the right combination of challenge, support, feedback, and room to fail safely.
A key distinction here is to avoid The Training Trap, in which organizations frequently treat training as the entire competence strategy… the deliver a workshop, send some e-learning, tick the box, and move on… but training is just one input. If we are focusing on Mastery, then we can see it as the output Mastery… the gap between them is where most change projects end up losing people.
One important thing: Mastery during organizational change is not about deep expertise, because we are in a change process, our goal is functional confidence, what the behavior change literature calls self-efficacy: the belief that you can perform the new behavior well enough to get through the transition. You don’t need people to become experts on day one, instead you need them to believe they can get from here to there, and that the system will support them while they do.
Quick note on the system
Same as in as Part 1. This isn’t a recipe, and change is never linear…. Organizational systems may take interventions, normalize workarounds, and create the appearance of adoption while people quietly go back to old behaviors. Treat what follows as foundations and experiments: try one play with one team, see what the response is, and adjust…remember Mastery isn’t something you deliver, instead It’s something you keep to sustain change.
Diagnosing Mastery Quickly
If you’re unsure whether Mastery is missing you can start by answering the 6 questions below:
Six questions you can ask
Can people describe what they need to do differently in their actual role (not in theory, at their desk)?
Do they know what “good enough” looks like during the first few weeks, or are they measuring themselves against the end-state?
Is there protected time and space to practice the new behavior without real consequences?
When someone makes a mistake with the new way of working, what happens next? Learning conversation or escalation?
Help-seeking frequency: are people asking how-to questions openly, or going silent?
Unprompted experimentation: is anyone trying the new behavior without being monitored, incentivized, or told to?
Capability confidence
When the environment around Mastery is weak, the system defaults to avoidance as its primary coping mechanism.
If people are saying things like:
Nobody showed us how this actually works.
I’ll just keep doing it the old way until someone forces me.
I tried it once and it didn’t work.
Then Mastery is unstable.
However, if what you’re hearing is more operational:
I’m still slow but I can feel it getting easier.
I got stuck here… can someone walk me through this part?
I figured out an upgrade that might help the team.
Then Mastery is starting to form.
Tool: Mastery audit
Ask two questions for each item below: (1) Are we doing this? (2) Where is it showing up (exact meeting / policy / system / timeline)?
High-risk Mastery-blockers:
· No protected practice time: expecting people to learn the new system while maintaining full output on the old one.
· Unrealistic performance expectations: measuring people against end-state standards during the learning curve.
· Shame after early mistakes: treating errors during transition as performance failures rather than expected learning.
· Training-then-abandonment: delivering training weeks before go-live, or with no follow-up support afterward.
· Surveillance-as-competence-strategy: monitoring adoption metrics without providing feedback or removing barriers.
· Everything-at-once rollout: launching all components simultaneously instead of sequencing what people need to learn first.
The Mastery playbook
Most change programs try to build Mastery by adding more training, more documentation, more e-learning modules… when Mastery is actually a dual job: what happens when the system supports competence, and what happens when it frustrates it.
This is the same “dual process” point from Part 1: the psychological conditions that build capability and the conditions that undermine it operate in parallel. If you invest in training but leave the Mastery-blockers in place, you’ll see some adoption, but it will be fragile. People will perform when being supervised and go back when nobody’s looking, because the system tell them that mistakes aren’t safe.
When there is Mastery frustration in organizations, it usually shows up as going to old tools (hi excel) and processes (hi many extra unneeded steps), doing the minimum to appear compliant, avoiding situations where the new behavior would be tested, and going quiet in meetings about the change.
Below are 7 plays you can use right away, like Part 1: they are not steps. They are plays you need to contextualize, test, iterate, and when validated, scale.
Play: Surface and address barriers at the role level
A lot of change plans assume barriers are obvious, but that is not usually the case… and I have written about the diagnostic problem here.
In any case… you need to ask at role level:
What’s the first thing that got harder when you tried the new way?
What did you need that wasn’t available?
What are you still doing the old way, and why?
The reason it works is simple: when people name their obstacles, the obstacles change from invisible threats to solvable problems and that change is itself a competence-building move.
One tip: revisit barriers at different points in the change, because the barriers at week 2 won’t be the same as the barriers at week 8.
Play: Set realistic expectations for the learning curve
Many change implicitly promise that things will feel normal immediately, but we know they won’t… this leaves open a gap between expectation and experience, as people attribute the difficulty to their own incompetence rather than to the normal reality of learning something new.
Name the learning curve explicitly:
“For the first 2–3 weeks, this is going to feel slower, that’s not because you’re doing it wrong. That’s because you’re learning..by week 4–6, most people report it starts feeling more natural. We’re not expecting end-state performance during the learning period, and if you need support we are here to help.”
This prevents false competence frustration: people feeling incompetent when they’re actually progressing normally.
Make sure you separate process expectations from outcome expectation…
-Process: You’ll feel clumsy with the new tool for two weeks.
-Outcome: Improvements usually show up around week 6–8. If you only talk about the outcome timeline, people spend weeks feeling like failures before results happen.
Play: Adjust the pace to what teams can absorb
Not every team starts from the same place, so making sure you are matching difficulty to current capability, is one of the strongest predictors of sustained engagement…as with my video game example… too easy and people disengage, too hard and they feel overwhelmed. The goal is the zone where effort produces visible progress.
In practice, this means:
Sequence what people need to learn. Don’t launch everything at once. What’s the minimum viable behavior change for week one?
Let teams choose their rollout pace within defined boundaries: These three components need to be live by month-end, you decide the order and the weekly targets.
Base progression on success rate, not the calendar: You’ve stabilized on Phase 1, ready to add Phase 2? is better than…It’s week 3, time for Phase 2.
Tool: the role-level capability map
Write one version per key role… if you can’t fill the role line, training isn’t ready.
· What changes for this role: the specific behaviors, tools, or processes that are different.
· What stays the same: the things that don’t change (people need anchors).
· First thing to learn: the single most important new capability for week one.
· What “good enough” looks like during transition: the realistic standard, not the end-state.
· Where you’ll get stuck: the known friction points and who to go to for help.
· What support exists: practice time, coaching, peers, documentation, and for how long.
One worked example for you to see how it works:
What: A new project management tool replacing spreadsheet-based tracking.
What changes: daily task updates move from the shared spreadsheet to the new tool, weekly status reports auto-generate instead of being manually compiled.
What stays the same: the project scope, the team structure, the reporting cadence, client communication channels.
First thing to learn: how to log a task update (5-minute walkthrough, one screen).
Good enough during transition: Tasks are logged in the new tool by end of day. Formatting and tags can wait until week 3.
Where you’ll get stuck: the integration with the invoicing system isn’t live until month 2, so you’ll need to double-enter billing tasks for now. That’s a known workaround, not a failure.
Support: 30 minutes of protected practice time daily in week 1. A Slack channel with two trained champions who respond within 2 hours. Weekly 15-minute troubleshooting drop-ins.
Play: Build feedback loops that inform without judging
Feedback is how people understand their progress. Without it, they’re flying blind, and worse, with bad feedback, they’re flying scared.
The critical distinction here should be between informational feedback and controlling feedback. Informational feedback tells people where they stand and what to try next, while controlling feedback tells people they’re being watched and scored.
Same data, different framing:
Controlling: Your team’s adoption rate is 43%…the target is 80%.
Informational: Your team has 43% of workflows in the new system, the most common issue across teams is the approval routing, here’s a 2-minute fix.
Research on feedback and competence is clear: feedback that provides specific, actionable information about what to do next builds self-efficacy, but feedback that simply reports a score without direction creates anxiety, and feedback delivered at unexpected moments (the new process worked exactly as designed) feels like genuine recognition rather than surveillance.
Every piece of feedback during a change should include a next step, because data without direction is just pressure.
Play: Create protected space to practice and experiment
Competence is built through doing, not through understanding, yet most organizations over-invest in instruction and under-invest in practice.
Protected practice means:
Time carved out specifically for trying the new behavior, where mistakes don’t count against performance.
Graded tasks which start with the simplest version of the new behavior and add complexity as confidence builds.
Permission to experiment with how the new process works in their specific context, not just follow the playbook exactly.
One practical move: pilot the change with a volunteer team before rolling it out, the pilot team builds competence first, generates real examples of what works, and becomes a source of vicarious learning for the teams that follow. When people see peers, not consultants, not leadership, but people in the same role succeed with the new way of working, it directly boosts their own self-efficacy.
Tool: a simple learning check-in (try it in a team meeting)
· 5 min: Where are you with the new [tool/process/workflow]? Quick round - one sentence each.
· 10 min: What’s working? What’s confusing? Where are you stuck? (Focus on specifics)
· 10 min: Pick the single biggest barrier, problem-solve it together and assign one action to remove or reduce it before next week.
Keep it small, keep it practical. This is not a feedback session for leadership, but a learning session for the team.
Play: Sharpen the Feedback Language
Mastery isn’t about lowering the bar, it’s about giving people clear information about where they are and what to do next, without making them feel surveilled or judged.
One way to do this is with the language of your feedback systems, because if feedback sounds like evaluation, people optimize for safety rather than learning.
Tool: feedback language swaps
Replace controlling feedback with informational, growth-oriented feedback:
Replace: Your adoption rate is 43% with - Here’s where you are and here’s the specific thing to try next.
Replace: You’re behind schedule with - The most common issue point is X here’s a 2-minute fix.
Replace: This team hasn’t completed training with What questions came up after the session? Let’s address them.
The goal is feedback that builds self-efficacy rather than triggering learned helplessness, which occurs when people feel that no amount of effort will lead to competence.
Play: Recognize effort and progress, not just end-state compliance
Most adoption tracking celebrates the finish line: 100% of teams migrated, but Mastery is built through the journey, not the destination. If you only recognize completion, you leave the entire learning period unacknowledged, which is exactly the period when people need the most reinforcement.
Recognize:
Effort during the learning curve: This team ran three experiments with the new process this week.
Progress relative to starting point: You’ve gone from 2 workflows in the new system to 8 in three weeks.
Help-seeking: This team asked the most questions in the first week, that’s a leading indicator of fast adoption.
Recovery: This team struggled in week 2, troubleshot it, and got back on track, that’s harder than getting it right the first time.
Remember that relying too heavily on tangible rewards for change adoption can undermine the internalization process. Recognition that highlights growing capability (you’re getting better at this) is more durable than recognition that highlights compliance (you did what was asked).
What to track (leading indicators)
Don’t wait for adoption dashboards, instead track competence signals.
· Unprompted experimentation: people trying the new behavior without incentives, surveillance, or instruction to do so.
· Realistic self-assessment: people can accurately name what they can and can’t do yet (not overconfident, not helpless).
· Help-seeking without fear: people ask questions openly, in meetings, in shared channels, not just privately or not at all.
· Error recovery speed: when someone makes a mistake with the new way of working, how quickly do they try again versus reverting permanently?
· Capability narrative shift: the story moves from I don’t know what I’m doing toward I’m still learning but I can see it getting easier.
One thing to try next week
Run a Mastery session with one team.
Agenda (copy/paste)
· 5 min: The change in one sentence, what’s actually different for this team?
· 10 min: Role-level capability map: what changes, what stays, first thing to learn, what good enough looks like now.
· 10 min: Surface barriers: what broke, what’s missing, what are people still doing the old way and why?
· 10 min: Learning check-in: what’s working, what’s confusing, where are people stuck?
· 5 min: Pick one barrier to remove this week and one experiment to run.
· 5 min: Name the support that exists (time, coaching, peers, documentation) and if it doesn’t exist, name what’s needed.
What to capture (so it doesn’t become another meeting)
· The capability map per role (what changes, first thing to learn, good enough standard).
· The top barrier and the action to remove it.
· The one experiment the team will run next week.
· The support gap, what’s needed that isn’t there yet.
You’ll learn more from that than another round of training.
While we focused on Mastery, remember that the three conditions are interdependent. Meaning provides the why, and gives you the autonomy to act, Mastery provides the can I, but for change to truly sustain, it must be supported by Belonging, the social fabric that makes new behaviors normative and gives people models, feedback, and the safety to keep going when things get hard.
Next up in the series: Belonging.
I write about behavioral science for organisational change and advise companies on how to diagnose and design for behavior change.
if you’re working on a change program where the behavior isn’t changing, I’d be curious to hear what you’re seeing… reply to this email or find me on LinkedIn.
Very best, Robert