# I don't consult. I operate. There's a difference.
People ask me what I do and I usually say "I fix systems." Which is true but incomplete. The more honest answer is that I stay until the system actually works, and that staying part is the whole difference.
A consultant arrives, interviews people, builds a deck, presents findings, and leaves. The deck is usually smart. The findings are usually correct. And three months later, the organization is doing exactly what it was doing before, except now there's a PDF on someone's desktop that everyone vaguely remembers agreeing with.
I'm not criticizing consultants. Some of them are brilliant. The problem isn't intelligence — it's the business model. When you're billing for the diagnosis, you have no economic incentive to stick around for the messy part. The treatment. The part where the patient doesn't take their medication, or the medication has side effects nobody anticipated, or the original diagnosis was right but the prescribed solution doesn't fit the patient's actual life.
The diagnosis is the easy part. The hard part is making the change survive contact with the organization.
The accountability gap
Here's what I've learned in thirty years: knowing what's wrong and fixing what's wrong are two entirely different skills. The first one requires analysis. The second one requires presence.
I worked with a distribution company that had hired three consulting firms in four years. Each one produced a report. Each report correctly identified that their routing system was costing them roughly 15% in unnecessary mileage and their dispatch process required too many manual interventions. Three firms. Same diagnosis. Nothing changed.
When I came in, I didn't start with a report. I started by sitting in the dispatch room for two weeks. Not observing from a conference room — sitting at the desk, watching the dispatchers work, asking questions when they had time, shutting up when they didn't.
What I learned in those two weeks was something no report had captured: the dispatchers didn't trust the routing software because it had failed them during a peak season three years earlier. They'd developed manual overrides that were slower but, in their experience, more reliable. The problem wasn't the software. The problem was a trust deficit that no technology upgrade was going to fix without addressing the history.
What operating actually looks like
Operating means your name is on it. Not in a liability sense — in a reputation sense. If the system I build breaks at 2 AM, that's my failure, even if I'm not the one who gets paged. If the process I redesign creates more confusion than it resolves, I don't get to blame the implementation team. I was there. I should have seen it.
This changes how you work. When your reputation depends on outcomes instead of recommendations, you make different decisions. You build simpler systems because you know you'll be around when they need maintenance. You document things because you've watched undocumented processes collapse when key people leave. You test with real data because you've seen demo environments lie.
You also develop a healthy suspicion of your own ideas. A consultant can fall in love with an elegant solution because they won't be there when it meets reality. An operator knows that reality has opinions, and they're rarely polite.
The deliverable is the running system
I don't produce decks. I don't produce roadmaps. Those things might happen along the way, but they're not the deliverable. The deliverable is a system that works — actually works, in production, with real people using it, generating real outcomes you can measure.
This means the engagement doesn't end when the plan is approved. That's roughly the halfway point. The second half is implementation, adjustment, training, dealing with the fifteen things nobody anticipated, and gradually transferring ownership to the people who will run the system after I'm gone.
That transfer is maybe the most important part. I've seen beautifully designed systems die because the people who were supposed to own them never felt like they were theirs. They felt like something that was done to them. An operator avoids that by building alongside the team, not above them.
Why this matters
The world has plenty of smart people who can tell you what's wrong. What's scarce is someone who will stay in the room while it gets fixed — who will sit with the discomfort of a plan meeting reality, who will adjust and adjust again, who will be honest when their own solution isn't working.
That's not consulting. That's operating. And the difference isn't semantic. It's the difference between a prescription and a recovery.