Writing an AI role when nobody in the room has built one

A first AI hire is usually specified by people who have not done the job. That is not a criticism — it is the ordinary situation, and it is exactly why the role is being hired. But it produces a recognisable set of job descriptions, and they are hard to hire against.

What that produces

The full-stack unicorn. Research depth, production engineering, data engineering, MLOps, and stakeholder management, at a salary that would be reasonable for any one of them. Everyone can spot this one in someone else's ad and nobody spots it in their own.

The tool list. Fourteen technologies, no description of the system. This attracts people who are good at listing technologies. It does not attract the engineer who has spent two years keeping one model working under real traffic, because nothing in the ad tells them the job involves that.

The undefined outcome. "Drive AI adoption across the business." Nobody can tell whether they would be good at this, so the people who apply are the ones most comfortable with ambiguity, which is not the same as the ones most likely to succeed.

Write the ninety days instead

The most useful thing you can do is describe what has to be true ninety days after this person starts. Not their responsibilities. The state of the world.

It is a harder document to write and it exposes disagreements inside your own team, which is the point. We have sat in briefings where two people who thought they agreed discovered they wanted different hires. Better to find that out before the ad goes up.

If you cannot describe what success looks like in ninety days, you are not ready to hire — you are ready to have a conversation about what you are trying to build.

Four questions worth answering first

• What already exists? A warehouse, some pipelines, a data team, nothing? An engineer who is good at building on top of a working platform is a different person from one who is good at creating the platform.
• Where does the data live and who controls it? If the answer involves another team's roadmap, that is the actual first six months of this job and it should be in the description.
• Who decides whether it is working? If nobody owns the measure, the engineer will end up defining it themselves, and you should hire someone capable of that.
• What happens if it does not work? If the honest answer is that the project quietly stops, say so in the interview. Senior people have been through that before and appreciate being told.

On salary

The gap between what a first AI hire is budgeted at and what the market pays is the single most common reason these searches stall. It is usually set by internal banding — the level the org chart says this role sits at — rather than by what the person you have described costs.

You do not necessarily need to move the number. But it is worth knowing early, because the alternatives are all easier to take in week one than in month three: narrow the role, split it in two, or accept a less experienced person and buy in support around them.