Technology Is the Easy Part

Getting a room full of people to agree that there’s a problem is usually pretty easy.

Too much manual work. Too many things falling through the cracks. Too much time spent chasing updates. Everybody has an example. Everybody wants it fixed.

Then you build something that addresses the problem, and the harder conversation starts.

Because now someone has to change how they work.

They have to put the request somewhere different. Check a queue before opening a spreadsheet. Record a decision they used to keep in their head. Follow a process even when sending a quick message would feel faster.

The agreement was real. So is the reluctance.

Agreeing that a process needs to change is much easier than changing your part in it.

Technology is the easy part. Relatively speaking. Building reliable software still takes work. But a working tool gives you something you can test and fix. Getting that tool into the way a team actually operates takes a different kind of effort, and it’s easy to underestimate.

Consider a familiar agency problem: campaign issues get passed around in messages. Someone spots a problem, tells someone else, and assumes it’s being handled. Later, everybody has a slightly different understanding of who owned the next step.

A shared queue makes sense. Every issue gets an owner, a deadline and a record of what happened. You can build that. You can demo it. People can look at it and agree it’s better.

Then a client needs an answer in twenty minutes.

Someone messages the person they know will respond. That person fixes the issue. The client gets an answer. The queue never gets updated.

From the perspective of the two people involved, they did their jobs. They solved the immediate problem using a method they trusted.

From the perspective of everyone else, the work disappeared.

That tension is where adoption gets difficult. The old way often works well enough for the person doing it, even when it creates problems for the team. A message is quick to send. The cost shows up later, when somebody else has to reconstruct what happened.

And the new way has an immediate cost. You have to learn it. You might be slower at first. You might have to make your work visible before you feel ready. If the tool adds steps without removing any, your skepticism may be justified.

Calling all of that resistance doesn’t help you understand what needs to change.

I’d start by watching someone do the work under normal pressure. Where do they leave the new process? What are they trying to accomplish at that moment? Is something missing, confusing or simply more work than it needs to be?

Then get specific about the behavior you’re asking for. “Use the new system” leaves a lot open to interpretation. “When you pick up an issue, assign it to yourself so the next person can see it’s covered” gives someone a concrete action and a reason.

The team also needs time to practice. If every hour is already committed, learning a new process becomes something people are supposed to squeeze in while meeting the same deadlines. Expecting an immediate productivity gain makes that harder.

Leaders have a part in this too. If I ask everyone to use a shared queue, then keep assigning work through private messages, I’m teaching people how work really gets done. They’ll follow the behavior that gets a response from me.

Eventually, something about the old way has to end. A short period of running both processes can help people check that the new one works. Keeping both indefinitely means maintaining two places and deciding which one to trust. That’s extra work, and people will feel it.

The useful measure is what happens on a busy day. Does the issue get an owner? Can the next person find the decision? Can someone take over without chasing a conversation?

A successful demo doesn’t answer those questions. Neither does a room full of people agreeing there’s a problem.

The work continues after the tool ships, in the small decisions people make while trying to get through their day. That’s where a better process has to prove it belongs.