The tool isn't the problem
Somewhere right now, a team just got assigned a new digital workplace platform. And somewhere in that same organization, someone is already thinking about ways to avoid using it.
This happens so consistently that it almost feels like part of the launch process itself. Resistance. Workarounds. The slow drift back to email because "it's just easier."
There's this common framing around tool adoption where resistance gets treated like a thing to overcome. Like the tool itself is solid, but people are just fighting change or being stubborn about it. And maybe sometimes that's true. But the resistance is often pointing at something more specific than just "people don't like new things."
The invisible infrastructure problem
Most people aren't actually attached to the tool they're currently using. They're attached to what they can do with it. The shortcuts they've built. The connections to other things. The way it fits into the actual work they do, day to day, in ways that don't show up in requirements meetings.
So when a new tool arrives, even a really nice one with great features, it sometimes arrives with a gap. The gap between what the tool can do, and what the old tool was doing quietly in the background. Maybe it was a integration that just worked. Maybe it was a specific workflow that took three clicks instead of seven. Maybe it was just muscle memory.
That gap doesn't feel like a feature gap. It feels like friction. And friction is exhausting when you're trying to get actual work done.
Why the shiny doesn't matter as much
New tools come loaded with things the old tool didn't have. Better analytics. Nicer UI. More automation. Deeper reporting. And all of that stuff is real and useful. But none of it matters if the new tool makes something harder that was working before.
There's an interesting dynamic where the team that selected the tool is often genuinely excited about it. They did demos. They looked at the feature matrix. They compared. It won on merit. And then the people who use it every day start quietly avoiding it, not because they didn't understand it, but because it introduced a new step they didn't have before.
The people who chose it are thinking about capability. The people who use it are thinking about friction.
Neither perspective is wrong. They're just solving for different things.
The context problem is real
When you put a new tool into an environment, it doesn't land in a vacuum. It lands in a context. There are other tools already there. There are workflows that depend on how things connect. There are ways of working that have calcified into being "just how we do things."
Sometimes the new tool is objectively better at the thing it's designed to do. But it's worse at fitting into the ecosystem where people actually work. It doesn't talk to the systems that feed it information. It requires manual steps that the old tool automated. It changes where information lives, and suddenly people can't find things where they used to look.
That's not a user adoption problem. That's a system design problem. And it shows up as resistance.
The quiet work that doesn't get measured
A lot of what makes a tool work for people happens invisibly. It's not a feature you can demo. It's not something that shows up in a feature comparison. It's just "I can make this work quickly," or "this connects to the other thing I need," or "I know where to find stuff in here."
When a new tool removes that invisible work and replaces it with something measurable and efficient but slower, people notice. Maybe not consciously at first. Just a tiny bit more friction on each task. A couple extra steps. A different place to look.
Multiply that across a hundred people across a hundred tasks and it adds up to an organization where everyone is vaguely frustrated with the new platform, not because it's bad, but because it made something harder that wasn't being measured anyway.
What actually happens
So people start keeping the old tool running. Or they build their own workarounds. Or they just stop using the new tool for certain things. The adoption stats might look fine. But the actual workflow is messy. The tool didn't fail. It just didn't fit the way work actually happens.
It's not dramatic or interesting to talk about. It's not a story about people resisting change or leadership issues or poor communication. It's just the friction of trying to make two systems work together when they weren't designed to.