Your New Software Won't Fix a Broken Process

Why consultants can't work magic in a messy kitchen — and what to do about it before you call for help.

There's a common fantasy about bringing in a technology consultant. The client imagines someone with x-ray vision who walks in, puts a finger on the broken thing, and fixes it instantly. The reality is far messier — and far more instructive.

That's the conversation Toby and Chris unpacked on a recent episode of the Pro Podcast, drawing on their experience delivering systems implementations at Magic Button Labs. What emerged is a practical framework for thinking about process debt, technology adoption, and what it actually takes to get an implementation right.

The Kitchen Analogy

Imagine inviting someone over to fix dinner — but you haven't told them where you keep the measuring cups, the pots, or the silverware. Worse, the recipe you're working from is written in metric when all your tools are imperial. That's what it's like for a consultant walking into a disorganized technology environment.

Clients often arrive at a consultant relationship with two conflicting expectations: that the expert will instantly understand their environment, and that the problem is the software, not the process. Both assumptions tend to be wrong.

Most People Use Tools at 50% Capacity — at Best

Here's a humbling benchmark: even with familiar tools like Microsoft Excel or a CRM, most people use roughly half the available features. The more sophisticated the system, the lower that percentage drops.

People use Excel to make grocery lists and never write a formula. They use Word and glaze over at the mention of mail merge. CRMs get bypassed the moment a salesperson decides it's faster to text someone directly — losing every capability the system was designed to provide.

This isn't a failure of individuals. It's a natural consequence of having a day job that doesn't include "learn all the features of this software." The minimum viable path — the one that gets the boss off your back — rarely runs through the features that would actually transform how you work.

Process Debt Travels With You

One of the core insights from Magic Button Labs' work: you can go through an entire software implementation and simply recreate your existing problems in a new environment. If you don't examine your process before rolling it into new software, you're not solving anything — you're redecorating.

The motivation for seeking new tools is often a perceived performance gap — things aren't fast enough, errors are too frequent, response times are slipping. But the instinct is to go find new software rather than ask whether the underlying process is the actual culprit.

As Toby put it: the goal is to understand what the outcome actually is before touching the technology. Clarity about the outcome, and about how the process works today, is how you scrub process debt before it gets baked into your new system.

The High-Low Problem

Chris identified one of the most common failure modes in implementations: people struggle to move fluidly between the high-level view ("this is how it should work") and the tactical detail ("this is exactly what happens, step by step").

Most people are anchored at one level or the other. When you ask someone how they want their email tied to a software record, the conversation often breaks down — because translating an abstract desire into a specific system behavior requires moving up and down that ladder fluidly, and most of us can't do it on the spot.

The implementations that go well tend to have two people in the room: someone senior enough to make decisions, and someone hands-on enough to actually operate the tool. The magic happens when they can show each other what's possible and what's needed — in real time.

The AI Cuteness Problem

There's a particular trap that Chris named well: AI is very good at organizing things. It can categorize, list, sort, and arrange. It looks impressive on the shop floor. And then you take it home and realize you've now got a beautifully organized list of 500 things you don't want to do.

The question that cuts through: how does this help your customer right now? Transcripts, emails, categorization — genuinely useful. But the "cuteness" of aligning your world into tidy boxes can sell you on a solution that doesn't actually move the needle on what matters.

What to Do Before You Call a Consultant

If you're considering bringing in outside help to clean up a process or fix a technology configuration, there are a few things worth having in order first:

• Document the recipe. Be able to show the process you think you're following — even if it turns out to be in the wrong units or a language the consultant doesn't speak. Something is better than nothing.

• Know where the pain lands. Not just where the problem shows up, but where the benefit of fixing it would actually be felt — especially if those are different places.

• Listen to the squeaky wheels — but verify them. The person who's been raising an issue since 2014 might be right. Or the problem might have evaporated a decade ago. Either way, don't let longevity substitute for analysis.

• Swim in your own problem first. Before bringing in a technical resource, spend time really articulating what's broken and what you've tried. The sales cycle is not the right place to discover your own process.

Simplify. Verify.

Chris offered a deceptively simple framework for process improvement: simplify and verify. Not the flashiest advice, but it's the kind that actually sticks. Give yourself enough time to do the work. Make one real, maintainable change rather than ten cute ones. Block and tackle.

And then, when you've done all that — phone a friend.

Magic Button Labs helps organizations implement and optimize monday.com and related systems. Learn more at magicbuttonlabs.com.