The Sensemaker’s Guide to Change Management
Change management gets a bad rap. Maybe it’s because the words themselves sound like corporate speak. Or maybe it’s because most of us have been on the receiving end of badly managed change and we’re still scarred from the experience. But here’s the thing: if you’re doing information architecture work, you’re doing change management work. Every taxonomy you build, every metadata scheme you implement, every content model you design, all of it requires people to change how they think, work, and make sense of their world. And if you ignore that human side? Your beautifully designed system becomes shelfware faster than you can say “user adoption.”
This article covers:
What is Change Management in Sensemaking?
Change management is how you help people move from their current way of making sense to a new way of making sense.
Notice I didn’t say “how you force people to use your new system.” That’s not change management, that’s wishful thinking.
Real change management acknowledges that people already have ways of doing things that work for them. Even if those ways drive you crazy. Even if they’re inefficient or outdated or make no sense to anyone else. They work for the people using them, and that matters.
When you’re doing sensemaking work, whether that’s building taxonomies, designing metadata, or restructuring how information flows, you’re asking people to change their mental models. You’re asking them to see their work differently, organize their thinking differently, and trust a new structure that doesn’t yet feel natural to them.
Change management in this context means:
- Understanding what people are currently doing and why it works for them
- Showing them what the new way looks like and why it’s worth the effort
- Supporting them through the messy middle where everything feels harder before it feels easier
- Checking in to see if the change is actually sticking
It’s not a project phase that comes after implementation. It’s the work that makes implementation possible.
Reasons to Think About Change Management
Let me be blunt: you need to think about change management because people problems are harder than technical problems.
You can design the most elegant taxonomy in the world, but if the people who need to use it don’t understand it, don’t trust it, or don’t see how it helps them do their jobs better, it won’t get used. Period.
Here are the most common reasons change management becomes critical:
Your users are stuck in their ways.
They’ve been doing things a certain way for years. Maybe decades. They have workarounds for the workarounds. They know where all the bodies are buried. Asking them to abandon that hard-won knowledge feels threatening, not helpful.
The stakes are high.
When people get metadata wrong in your new system, it doesn’t just create a small headache, it breaks critical workflows, makes content impossible to find, or creates compliance risks. The higher the stakes, the more resistance you’ll face.
Multiple groups are affected differently.
Your new content model might make life easier for marketing but harder for legal. Your metadata scheme might solve problems for one team while creating new problems for another. When change creates winners and losers, you need to manage that tension.
The change is invisible to users.
Sometimes the best information architecture is invisible, it just works. But that means people don’t see the value of what changed. They just see that they have to learn something new. You need to make the invisible visible.
Trust is broken.
Maybe the last three “improvements” made things worse. Maybe leadership promised one thing and delivered another. Maybe IT has a history of implementing systems and then disappearing. You’re not just managing change, you’re managing skepticism.
If you’re nodding along to any of these, you need a change management strategy. Not a plan to convince people they’re wrong. A strategy to help them see what you see.
Common Use Cases for Change Management
Change management shows up everywhere in sensemaking work. Here are the situations where you’ll need it most:
Implementing a new taxonomy.
You’re asking people to tag their content differently, think about categories differently, and trust that your structure will help them find things better than their current system of organized chaos.
Rolling out new metadata requirements.
Now people have to fill out six fields instead of two. Or they have to be more specific. Or they have to think about their content in ways they’ve never had to before. Each new required field is a change to manage.
Migrating to a new platform.
Everything people knew about where things are and how to find them is about to become obsolete. The muscle memory they’ve built up over years? Gone. That’s terrifying.
Changing governance models.
You’re shifting who makes decisions about what, who’s responsible for maintaining structure, and how conflicts get resolved. This is change at the process level, and it usually comes with a side of power dynamics.
Consolidating or restructuring content.
You’re telling people that the site they’ve lovingly maintained for five years needs to merge with another team’s site. Or that the folder structure they understand needs to be completely rethought. This feels personal because it often is.
Introducing new workflows.
People have to do things in a different order, check in with different stakeholders, or use different tools. Even small workflow changes ripple through everything else people do.
In every single one of these cases, the technical work is only half the battle. The other half is helping people understand why the change matters, what’s in it for them, and how to succeed in the new world you’re building.
Types of Change Management
Not all change is the same, and not all change needs the same approach. Here are the main types you’ll run into:
Structural Change
This is when you’re changing how things are organized. For example: new taxonomy categories, different metadata fields, restructured navigation, new content types. The change is in the architecture itself.
Process Change
You’re changing how work gets done. Important things like who does what, in what order, and with what approvals. The structure might stay the same, but the workflows around it are different.
Behavioral Change
You need people to do things they weren’t doing before. Maybe it’s asking for people to tag content consistently, fill out metadata completely, or use controlled vocabulary instead of free text. The systems might support the old behavior, but you need the new behavior to make things work.
Cultural Change
This is the deepest level. You’re changing underlying assumptions about how information should be managed, who’s responsible for what, or what “good enough” looks like. This is change at the belief level.
Most real-world projects involve all four types at once. You’re not just changing the taxonomy (structural), you’re also changing who maintains it (process), how people tag content (behavioral), and what the organization believes about the value of consistency (cultural).
The types build on each other. You can force structural and process changes through policy and tools. But behavioral and cultural changes? Those require buy-in, practice, and time.
When you’re planning your change management strategy, be honest about which types of change you’re actually asking for. If you need cultural change but you’re only planning for structural change, you’re setting yourself up for failure.
Approaches to Change Management
There’s no one-size-fits-all approach to change management, but there are some patterns that work better than others.
Start with the “why” not the “what.”
Before you explain your new taxonomy structure, explain the problems it solves. Show people what’s broken right now. Help them feel the pain of the current state before you ask them to embrace a new one.
Find your champions.
Don’t try to convince everyone at once. Find the people who get it, who are excited about the change, who can see the potential. Support them, give them resources, and let them spread the word to their peers. Peer influence beats top-down mandates every time.
Make the change visible.
If people can’t see what’s different or what’s better, they won’t value it. Show before and after examples. Track metrics that matter to them. Create moments where the benefit of the change becomes obvious.
Plan for practice.
People don’t change overnight. They need time to try the new approach, mess it up, ask questions, and try again. Build in training, yes, but also build in forgiveness. The learning curve is real.
Address the losses.
Change always involves loss, even good change. People lose efficiency (temporarily), lose expertise (their old knowledge becomes less valuable), lose comfort (everything feels harder). Acknowledge these losses instead of pretending they don’t exist.
Connect change to daily work.
The faster you can make the new way feel like the normal way, the faster adoption happens. Embed the change in the tools people already use, the workflows they already follow, the conversations they’re already having.
The biggest mistake I see is treating change management like a communications campaign. It’s not about crafting the perfect message and sending it out. It’s about ongoing dialogue, adjustment, and support.
Tips for Getting Started with Change Management
If you’re staring at a project that needs change management and you don’t know where to begin, start here:
Map who’s affected and how.
Make a list of every group that will experience this change. For each group, write down what they’re being asked to change, what they’ll gain, and what they’ll lose. Be specific. “Content creators” is too broad, break it down by team, by role, by how they actually work.
Talk to people before you plan.
Don’t assume you know what people’s concerns will be. Ask them. What do they worry about? What do they need to feel confident? What support would actually help? Their answers may surprise you.
Create clarity about what’s changing and what’s not.
People fill information voids with worst-case scenarios. If you don’t tell them what’s staying the same, they’ll assume everything is changing. Reduce the uncertainty by being specific.
Build in feedback loops from day one.
You need to know what’s working and what’s not. Set up ways for people to ask questions, report problems, and suggest improvements. And then actually respond to what you hear.
Start small and prove value.
If you can pilot the change with one team or one use case, do it. Let people see it working before you roll it out everywhere. Success stories from peers are more convincing than any deck you could build.
Document the new way.
People need something to refer back to when they’re confused. Quick reference guides, cheat sheets, examples of good tagging, whatever will help people remember how to do this new thing when you’re not there to help them.
Plan for the long haul.
Change doesn’t end at go-live. Plan for ongoing support, refresher training, and continuous improvement. The first six months after launch are when adoption either sticks or falls apart.
One more thing: get real about your own capacity. Change management takes time and energy. If you’re already underwater with the technical work, you can’t also carry the full weight of change management. Figure out who else can help and what you can let go of.
Change Management Hot Takes
Here’s where I get a bit spicy:
Most “change management” is actually just announcement management.
We send emails, hold town halls, record training videos, and then wonder why nothing changes. Real change management is messy, ongoing, and requires actual conversation: not broadcast communication.
Resistance isn’t the enemy.
People who push back are giving you valuable information about what’s not working. They’re your early warning system. Like canaries in your coal mine. Listen to them instead of trying to overcome them.
You can’t change manage your way out of a bad design.
If your taxonomy doesn’t make sense, no amount of training will fix it. If your metadata scheme creates unnecessary work, people will work around it. Change management amplifies your design, it doesn’t cover for it.
Leadership support is necessary but not sufficient.
Yes, you need executive buy-in. But executive buy-in doesn’t translate into middle manager buy-in or frontline adoption without a lot of work in between. Don’t assume top-down support means bottom-up compliance.
The people doing the work know things you don’t.
They know the workarounds, the edge cases, the reasons things are the way they are. If your change management plan doesn’t include learning from them, it’s incomplete.
Change fatigue is real.
If your organization has been through three restructures in two years, people are tired. Your change might be good, but it’s still change. Factor exhaustion into your timeline.
Calling something “intuitive” doesn’t make it so.
Just because your new structure makes perfect sense to you doesn’t mean it will make sense to people seeing it for the first time. Test your assumptions.
Change Management Frequently Asked Questions
How long does change management take?
Longer than you think. Real behavior change, the kind where people consistently use new approaches without thinking about it takes months not weeks. Plan for at least three to six months of active support after go-live, and ongoing check-ins after that.
What if leadership won’t give me time for change management?
Make the cost of skipping it visible. Show them what happened with past projects that didn’t include change management. Show them the support tickets, the workarounds, the abandoned systems. Frame change management as risk reduction, not nice-to-have polish.
How do I deal with people who refuse to change?
First, understand why they’re refusing. Is it fear? Is it that the change genuinely makes their job harder? Is it that they don’t understand the why? Different reasons need different responses. If someone truly can’t be moved, sometimes you need to go around them but that should be your last resort, not your first move.
What if the change is mandatory?
Mandatory doesn’t mean you skip change management: it means you adjust your approach. You’re not trying to convince people whether to change, you’re helping them change successfully. Focus on building competence and confidence rather than building buy-in.
Can I do change management after implementation?
You can try, but it’s harder. You’re now asking people to unlearn bad habits they’ve already formed. It’s not impossible, but it’s more work. Build change management into your project timeline from the start.
–
Here’s the truth: change management isn’t optional in sensemaking work. It’s not the thing you do if you have time. It’s the thing that determines whether your work actually works.
You can have the most brilliant taxonomy, the most elegant metadata scheme, the most thoughtfully designed content model and none of it matters if people don’t use it. Or worse, if they use it wrong because nobody helped them understand how to use it right.
The good news? You don’t need to be a change management expert to do this well. You need to be curious about why people do what they do. You need to be honest about what you’re actually asking them to change. You need to be patient with the learning curve. And you need to stick around long enough to see if the change actually sticks.
Most importantly, you need to remember that you’re not managing change: you’re supporting people through change. There’s a difference.
If you want to learn more about my approach to Change Management, consider attending my workshop on December 19th from 12 PM to 2 PM ET. Change Management Strategies for Data, Content and Knowledge — this workshop is free to premium members of the Sensemakers Club.