The Wrong Job Title Is Winning the AI Hiring Race

Searches for AI-related jobs on Indeed have grown 11 times since ChatGPT launched in November 2022. If you read that stat the way most hiring plans do, it sounds like good news: interest is up, the market is maturing, just go post the role. I think it is pointed at the wrong job.

The Searches Are Up 11x. The Job Posting Is Still Wrong

The direct answer: AI-role searches on Indeed are up 11x since late 2022, but they remain under 1% of all job searches even as nearly 5% of job postings now mention an AI-adjacent skill requirement. That gap, employer demand for AI skills outpacing job seekers who search for AI titles, is not the interesting part. The interesting part is what both sides of that gap are chasing.

Indeed’s Hiring Lab tracked the search growth against major model releases going back to GPT-4 and found the steepest jumps came after moments that broke into mainstream awareness, not the steady drumbeat of incremental updates. That tells you something about who is searching: people reacting to a headline, not people who have done the unglamorous work of figuring out what actually breaks when a company deploys AI into a real workflow. The job titles attached to those searches, AI engineer, ML lead, AI specialist, describe a technical builder. Almost none of them describe the person who has to live with what the builder shipped.

I wrote last year about treating AI agents as scatterbrained employees who thrive under careful management, a framing borrowed from a research-backed forecast called AI 2027. That essay argued the milestone everyone is waiting for, “is the AI good enough yet,” never arrives on its own. This one is about the hiring consequence of believing it will anyway. If you think the model is the bottleneck, you hire a model person. If you think management is the bottleneck, you hire something else entirely, and almost nobody is posting for it.

What a Technical Hire Actually Fixes

The direct answer: an AI engineer is good at the layer below the one where most rollouts actually fail. They choose models, wire integrations, tune prompts, and manage latency and cost. Those are real skills and a real bottleneck for some companies. They are not the skills that catch a brief going stale or an output quietly drifting off-tone, which is where most of the pain in AI in B2B sales deployments actually lives.

I watched this play out at a company I worked with early in my career, before founding Sendspark. We hired a genuinely strong technical lead to build an internal tool that would summarize customer calls for the sales team. He built it fast. The pipeline worked. The summaries were technically accurate, every fact traceable back to the transcript. The sales team stopped opening them within three weeks. Nobody had defined what tone the summaries should take, what a rep actually needed to see in the first two sentences, or who was supposed to spot-check the output once a week. The engineer’s job ended when the code ran correctly. The job the business actually needed, deciding what “good” meant and checking for it, belonged to nobody. We had shipped a tool. We had not shipped a result.

That gap is not a story about one bad hire. It is the default outcome of filling a technical role and assuming the management work handles itself.

The pattern repeats because the two jobs feel adjacent enough to blur together in a budget conversation. A founder or a VP of sales looks at a line item for “AI tooling” and reasonably assumes that whoever builds the tool also owns whether it works. That assumption would hold if the tool were static, the way a piece of traditional software is static once it ships. It does not hold for a system whose output changes shape depending on the data it sees that week, the brief it was given, and the two or three edge cases nobody anticipated at launch. A traditional software bug gets caught by a test suite. A tonal drift in a generated summary gets caught by a human who was specifically assigned to look for it, or it does not get caught at all.

The Job Posting Nobody Has Written Yet

The direct answer: the role most companies are missing is closer to an AI operations manager than an AI engineer, and its day-to-day work is brief-writing, chunking large jobs into checkpoints a reviewer can actually inspect, maintaining a no-list of what the agent cannot touch, and running a recurring review cadence instead of a one-time launch.

Go read ten “AI engineer” job postings. They ask for Python, for experience with model APIs, for comfort with vector databases and cloud infrastructure. That is a reasonable list for the builder’s job. Almost none of them ask for the skill that determines whether the thing the builder ships actually gets used: the discipline to write a brief precise enough that ambiguity cannot sneak in, and the patience to read the output line by line afterward. I made the case before that the no-list, not the yes-list, is the first artifact of any deployment. Nobody is hiring specifically for the person who owns that document, even though it is arguably the single highest-leverage artifact in the whole rollout.

The AI operations manager role, if anyone wrote the posting honestly, would read as follows. Owns the brief: defines tone, format, and the boundaries the agent cannot cross. Owns the checkpoint structure: breaks large jobs into pieces small enough that drift gets caught before it compounds. Owns the no-list: maintains it, updates it when a new edge case surfaces, and has the authority to say no to expanding the yes-list before the no-list is solid. Owns the review cadence: not a launch event, a recurring one, the same way every AI agent you deploy deserves the review cadence you already give human hires. That job description would not get many applicants from a search for “AI jobs.” It would get the right one.

Why the Person Who Gets Told They Micromanage Is Your Best Candidate

The direct answer: the temperament that wins at AI operations management is disciplined skepticism, not technical enthusiasm, because the job requires assuming every output is wrong until proven otherwise, and both deep technical sophistication and genuine excitement about the technology work against that default.

Here is the part that is counterintuitive until you have watched it happen twice. The most enthusiastic person on your team about AI is often the worst person to put in charge of reviewing it, because enthusiasm correlates with wanting the tool to be right. They skim the output for the thing they were hoping to see and move on. The most technically sophisticated person is a close second kind of wrong, because sophistication breeds trust in the system they built or chose, and that trust makes the review feel redundant. Neither temperament survives contact with a system that is, by design, a probability engine that hallucinates, averages, and smooths over the exact nuance a customer-facing output needs to get right.

I made this mistake myself, with a different team than the one above. I assumed that because someone was sharp technically, they could also own the editorial judgment for what our AI-assisted outreach drafts should sound like. They could not, not because they lacked the intelligence, but because the job asks for a completely different instinct: distrust the first draft, read every line, flag the sentence that sounds smart but would not survive a follow-up question from a prospect. We lost real time to tonal drift nobody caught for weeks, because the person reviewing it was optimizing for whether the system worked, not whether the output was right. My background includes operating roles where a misread brief cost a full quarter, which is exactly the instinct I should have hired for in that moment and did not.

The person who has been told they micromanage, who writes briefs colleagues complain are too thorough, who asks “what happens if this is wrong” before anyone else in the room does, is not a difficult personality to manage around. They are your AI operations manager, and they are probably already on your payroll.

Two Job Descriptions, One Open Role

The direct answer: laid side by side, the AI engineer posting and the AI operations manager job describe almost entirely different work, which is the clearest evidence that filling one does not fill the other.

Dimension	AI Engineer (what gets posted)	AI Operations Manager (what actually closes the gap)
Core skill	Model selection, integrations, prompt tuning	Brief writing, editorial review, no-list discipline
Day-to-day work	Debugging pipelines, tuning parameters, API wiring	Reviewing output line by line, running checkpoint reviews, updating the no-list
Success metric	Uptime, latency, cost per call	Output accuracy, stakeholder adoption, consistency over time
Failure mode	Integration breaks, pipeline crashes	Quiet tonal drift, hallucinations that reach a customer unreviewed
Winning temperament	Technical sophistication, comfort with ambiguity in the stack	Disciplined skepticism, comfort with being called a micromanager

Nobody reading that table should conclude the engineer role is unnecessary. Some companies genuinely need the technical build first, especially if there is no existing system to point an off-the-shelf model at. The point is narrower: the table describes two different jobs, and most hiring budgets this year are only funding one of them, while quietly hoping the person they hired will also do the other one on the side, unpaid and untitled, because nobody wrote it into the role.

That hope is where the cost hides. The engineer you hired for the technical build did not sign up to be the person who catches tonal drift in week fourteen. If they do it anyway, it is because they are conscientious, not because the job description asked for it, and conscientiousness is not a hiring strategy you can plan around. The moment that engineer moves to a different project, or leaves, the informal review work leaves with them, and nobody notices until the next incident.

What To Do Before You Post Another Requisition

The direct answer: before writing another AI engineer job posting, audit your existing team for someone already doing unpaid operations-manager work, brief writing, line-by-line review, style-guide maintenance, for human output, because that person’s temperament transfers directly and promoting them is faster than hiring externally for a title the market has not standardized.

Ask three questions before the req goes up. Who on the team already writes the brief other people follow when producing customer-facing work? Who already reviews drafts line by line rather than skimming for the gist? Who has been quietly told, probably as a mild criticism, that they are “in the weeds” too often? McKinsey’s research on enterprise AI adoption found that early pilots cluster around the same gap: the technology works in isolation and stalls the moment it needs sustained human judgment layered on top. The companies that moved past that stall point were not the ones with better models. They were the ones that found their internal brief-writer and put them in charge.

If nobody on the team fits that profile, that is a real finding, not a reason to default back to the technical hire. Look for project managers with editorial backgrounds, quality leads from regulated industries, or operations people who have been burned before by shipping something unreviewed. The job title you are hiring for should describe judgment and review discipline, not a tech stack.

The Compounding Cost of Hiring the Builder and Skipping the Manager

The direct answer: a company that fills the engineering seat and leaves the management seat empty does not just waste the engineer’s output, it teaches the rest of the organization that AI does not work, and that belief is harder to undo than the original hiring mistake.

Think about what actually happens inside the company during the months nobody is watching. The agent’s output drifts a little further from the original brief every few weeks, because nobody owns the brief anymore. Someone on the sales team notices a tonal problem, says nothing, and quietly starts ignoring the tool. A few more people do the same. By the time leadership asks why adoption is low, the honest answer, nobody was reviewing the work, gets replaced with a simpler and wrong one: the AI is not good enough yet. Harvard Business Review documented the leadership narrative that pushed managers toward “trust the team, step back” for most of the 2010s. That instinct, applied to an AI agent instead of a human report, is exactly how the review work gets skipped.

That wrong conclusion compounds. The company becomes more AI-skeptical than a competitor who never deployed anything, because skepticism built on a bad experience is stickier than skepticism built on inexperience. Rebuilding trust in the tool, once a team has decided it does not work, takes longer than building the review discipline would have taken in the first place. This is the sharper version of the point I made about why AI pilots fail for reasons that have nothing to do with the model: the postmortem blames the technology because the technology is the visible part. The missing manager is invisible by design, which is exactly why nobody puts them on the hiring plan until it is too late.

I have seen the recovery side of this too, and it takes longer than people expect even when the fix is obvious. One team I worked with took almost two full quarters to get a sales group back to using an AI drafting tool after a few unreviewed outputs went out with the wrong account details attached. The fix, once someone finally owned the review, took a week to implement. The trust took two quarters to rebuild, because by then the tool had a reputation inside the team, and reputations move slower than processes. That asymmetry, fast technical fix, slow trust repair, is the actual argument for hiring the manager before the incident instead of after it.

The Choice Hiding Inside the 11x

The 11x search growth is real, and it is not going away. It is a signal that interest in AI roles has moved from curiosity to something more durable, and companies that ignore it entirely will fall behind companies that act on it. The mistake is not in responding to the signal. The mistake is in assuming the signal is pointing at the job title that is easiest to describe.

I started this essay with a stat about searches, and I want to end on the choice sitting underneath it. Every company reading that 11x number this quarter has a hiring plan forming around it. Most of those plans will produce another AI engineer req, because that title is familiar, technical, and easy to defend in a budget meeting. A smaller number will produce something closer to the operations-manager role described above, unglamorous, hard to describe in a posting, and far more likely to be the reason the deployment actually works eighteen months from now. More essays on this exact tension live at dearmer.com.au, because I think it is the load-bearing decision most companies are getting wrong right now without realizing it is a decision at all.

When your company’s next AI req goes up, will it describe the person who builds the system, or the person who has been quietly doing the unpaid work of managing one for months already?