A few months ago I had coffee with Michael Housman. Michael does around 50-60 AI talks a year — enterprise clients, corporate workshops, serious organizations. We were comparing notes on the consulting business and stumbled onto the same frustration.
Both of us had been through a period of doing heavy implementation work. And both of us had independently arrived at the same conclusion: it does not scale, and it drains you in ways that are hard to explain until you’ve been through it.
“It sucks up a ton of time and bandwidth,” Michael said. “You both kinda learn… we don’t wanna do implementation because it’s the most painful aspect and you end up doing a lot of things you don’t want to be doing.”
That word “painful” stuck with me. Not hard. Painful.
What Makes Implementation Consulting Different
There’s a version of AI consulting that’s strategy and education. You help people understand what’s possible, figure out where the leverage points are in their business, and point them toward the right tools and approaches. That work scales. One workshop can reach 20 people. One article can reach 2,000.
Then there’s implementation consulting. You’re inside someone else’s systems. Their Salesforce instance, their IT policies, their staff who have been doing things the same way for ten years. You’re writing code or building agents or configuring tools in an environment you don’t control, for a team that may or may not be bought in.
Both are real work. But only one of them multiplies.
Every implementation project is basically a custom build in a custom environment. You solve the same class of problems over and over, but in slightly different configurations. The institutional knowledge you build stays locked in that one client’s system. You can’t reuse it next week with a different client.
And there’s a subtler cost too: the context switching.
I describe it to clients using a pilot analogy. Takeoff and landing are the most stressful parts of flying. Once you’re at altitude, cruising is relatively easy. Implementation consulting keeps you in constant takeoff and landing mode. You finish one phase, start another, switch clients, start over. Your brain never gets to cruise.
The Multiplier Problem
When I was teaching my first AI sprints, I noticed something interesting. People who’d heard about AI for months would come in skeptical. They didn’t really know what was possible. But once I showed them a few real examples — actual use cases from actual businesses — the light bulb would go on. Almost immediately. And then they’d start seeing applications everywhere in their own work.
That one workshop reached 15 people. Then some of those people went back to their companies and showed their teams. Then those teams started experimenting. The impact multiplied.
That doesn’t happen with implementation work. When I build an agent for a client, that agent helps that client. Full stop. There’s no natural spread. No multiplier.
Teaching has a multiplier built into it. The “real work vs. fake work” concept I talk about in workshops is relevant here: both strategy and implementation feel productive. But only one of them moves your business and your clients’ businesses forward in a compounding way.
What Strategy-First Consulting Actually Looks Like
Michael is moving toward mastermind groups and peer learning formats. I’ve doubled down on full-day workshops. Different formats, same principle: get people to a place where they can do the work themselves, or at least supervise it intelligently.
That means a few shifts:
Teach principles, not just steps. If you show someone how to use a specific tool, they’re stuck when the tool changes. If you show them how to think about automation — what to automate first, how to evaluate a workflow, how to write a good prompt — that knowledge transfers everywhere.
Demos beat documentation. One of the consistent patterns I see in workshops: when I actually demonstrate a tool live, something clicks that reading about it never produces. The goal isn’t to give people a manual. It’s to give them a visceral sense of what’s possible so they can go figure out the specifics themselves.
Clients who own their systems get better results. Counterintuitive but true. When a client’s team builds something themselves (with your guidance), they understand it. When they have a problem, they debug it. When it breaks, they fix it. When you hand them a finished system, they treat it like a black box and get frustrated when anything goes wrong.
The Honest Part
I want to be clear: I still do some implementation work. For the right client, at the right scope, it makes sense. If there’s a specific automation that’s genuinely complex and the client’s team isn’t positioned to build it, I’ll take that on.
But it’s not the core of the business model. And it shouldn’t be.
The sustainability test I use: could this scale to 10x clients without me working 10x harder? Strategy and education: yes. Implementation: no.
Michael and I both arrived there independently. Two different backgrounds, two different client bases, same conclusion. That kind of independent convergence usually means something.
If you’re building an AI consulting practice and you’re spending most of your time inside clients’ systems… that’s worth examining. Not because implementation work isn’t valuable. It is. But because there’s a better use of your expertise.
Teach. Show. Equip. The multiplier is in the education, not the execution.
Thanh Pham runs AI workshops and consulting for entrepreneurs, investors, and business teams in Austin and beyond. If you’re interested in bringing a workshop to your team, get in touch.
