Don't Hire an AI Expert.
Hire Someone Who Gets It Done.

AI has handed business owners a new exam question, and the question itself is written wrong.

Most companies reach a point where they make the same decision: it's time to hire someone who understands AI. The job ad goes out, the résumés come in, the interviews begin, and you usually meet two kinds of people. The first kind talks models brilliantly — which one is strongest, how to tune it, where the differences lie — and explains it better than you could. Ask them "how should we change our quoting process?" and they can't answer; that was never their question to begin with. The second kind is great with tools: their prompts are elegant, their demos run smoothly. Ask them "how does this plug into the systems we use now, and who signs off on it once it's live?" and they can't answer either.

One round of interviews later, the role is still open. Some companies just hire someone anyway, and three months later they have a few nice-looking demos while the business workflows keep running exactly as before.

The problem isn't the candidates. It's the question. "Someone who understands AI" misses the point from the start; what you want is the person who can put AI into your company's workflows and put their name on the result. The two sound close. In practice, they're two different kinds of people.

01The model isn't where you're stuck

The tools are bought and the workflows are mapped. The next question is who runs it. To answer that, you first have to see clearly where the company is stuck.

There's an implementation guide written for business decision-makers that lists the break points between "individuals can use AI" and "the organization can use AI." It names three, and it's more honest than most consulting reports:

First, individuals can use it, but the organization can't. One colleague has worked out a smooth way of doing things on their own, but it never became a process that still works when someone else follows it. The week they take leave, it stops.

Second, the business can't be spelled out. The rules hide in the exceptions, in "this client is a bit special." Nobody has ever written them down, so nobody can hand them off.

Third, the technology can't take the load. The data is scattered across four places, nobody dares touch the permissions, and nobody wants to go near the legacy system that's been in use for ten years. However good the proposal looks, it can't go live.

Three break points, and not one of them is the model not being smart enough.

That's also why deeper technology won't untangle them. What does is someone willing to sit inside your workflows and connect these three things, one at a time. The hard part isn't the algorithm. It's patience and communication.

02The industry gave this role an awkward name

Over the past two years, the English-speaking world has taken to calling it an FDE, short for Forward Deployed Engineer. The name is easy to misread, so let's head that off: it has nothing to do with frontline customer support, and it isn't the field technician who comes out to repair equipment. "Forward" here means where the business actually happens. Put plainly, it's an engineer sent to work right beside the people who actually use the thing, rather than staying in their own office waiting for request tickets.

Break their day down and it comes to four things. First, see clearly: get on site and understand how the workflow runs and where it gets stuck. Next, build it: connect the solution to the existing systems so it actually runs. Then, check it: see whether anyone is using it and whether the business numbers have moved. Finally, write it down: leave the method in a form someone else can pick up. The four lock together. Skip the last one, and the company has just gained an outsider's handiwork.

One write-up on who suits this role uses a very memorable ratio: sixty percent communication, forty percent technology. That line deserves an extra two seconds from small-business owners, because it's the exact opposite of the role you were planning to post. You think you need deeper technology. What actually needs thickening is the ability to translate: turning vague business requests into things a system can do, and turning technical limits back into words the business understands.

Another line draws the difference between this role and a consultant most cleanly. A consultant hands you a proposal and leaves once they've presented it. This role doesn't leave. They sit in your office, build the system, get it running, and stay with it until it produces value in your business.

03The best person for it may already work for you

At this point, most small-business owners reach a deflating conclusion: we can't afford someone like that.

That conclusion isn't wrong. As Chinese tech outlet 36Kr has reported, companies like Anthropic offer this role an entry-level total annual package of US$300,000 to US$500,000. Post a job at Silicon Valley rates, and Taiwan's small and mid-sized businesses were never in the same market to begin with.

But "we can't afford that person" and "we can't do that work" are two different things. The same guide for decision-makers actually offers two approaches. One is to have a vendor send someone in. The other is for the company to form its own small team of two to four people — no new department, no change to the org chart — and pick one high-frequency, high-value workflow to pilot first. The second is the version a small business can actually take on.

And the most important seat on that team doesn't necessarily have to be filled from outside. A long, contrarian essay offers a different answer: the best candidate is often a business expert, not a professional engineer. The reason is that the two face different kinds of difficulty. A technical person has to fill in an understanding of the industry, which is a moving target: industries change, clients change, and you never catch up. A business person has to fill in judgment about technical architecture, which is a fixed target: crack it once and it stays cracked. The latter is easier to get a handle on.

In an owner's terms: the veteran who's been there eight years, who knows which client needs a phone call first and which order can't just go through the system as-is, is closer to this role than a fresh engineering graduate. What they lack is technical support, and technical support can be bought. What they have is a body of judgment nobody ever wrote down, and that can't be bought.

There's a premise that often gets skipped here: they need the time. Putting your best business person on this means admitting that someone has to take over their current job. If you can't admit that, the role stays a side gig forever, and all that AI stays stuck at the demo stage forever.

04Four signals that you shouldn't be hiring yet

The difference between a consultant and a seller is whether they're willing to say "don't do it yet." The same guide lists four situations where hiring someone will only waste money:

The underlying systems don't exist at all. The data still lives on paper and on personal computers. There's nothing to connect to.

Only one department has the problem, and it won't come up a second time. That's a project, not a role.

The team has no foundation in using AI at all. If nobody has used it, nobody can ask the right questions.

You only want to put out fires, not change the workflow. What that kind of need ends up buying is outsourcing, not capability.

If two or more of the four apply to you, this article's value to you is the hiring round it saves. Get the data in order first, and get the team using AI first. Neither of those has to wait for a hire.

05Once you've found them, how do you know they're doing it right?

One last question, and the one most companies get wrong.

That guide has a line that reads almost like a warning written for owners: judge this role only by whether projects launch on time, and you'll end up managing it like an ordinary implementation job. Delivering on time is the minimum standard, not the result.

Look at at least four things at once. Did it save money or bring in more? That's business value. Is anyone using it every day? That's adoption, and plenty of projects die in this box: the thing passes sign-off, and three weeks later nobody opens it. Is what got built stable, and if it breaks, will anyone know? That's engineering quality. And the box most easily overlooked: can the next department take what was built this time, adjust it a little, and use it? The higher the score in that fourth box, the more what you bought looks like capability rather than one more project.

You're looking for a responsibility, not a title

Back to the beginning.

Before You were missing someone who could use the tools

Now You're missing someone who can connect the tools to your workflows and is willing to put their name on the result

In August we wrote that roles shouldn't be cut per person anymore, and the point there was how to re-cut the work internally. This piece is the other half: once the work is cut, someone has to stand on the seams. That position isn't called AI expert, and it doesn't necessarily need a new job title. It's a question of where responsibility sits: who is responsible for getting it running, who will be first to know when it breaks, and whether the method has been written down so the next person can pick it up.

So before you open the role, ask three questions. Of those three break points, which one is yours? Who's closest to it right now? Do they have the time? If you can answer, you may not need a new résumé at all. If you can't, hiring one more person just means one more salary.

Let AI move fast. Let people hold the anchor. Tools can be bought. The responsibility for getting the work done can't.

Rooted in craft. Built for the new wild.