The AI engineering hire scaleups keep making - and unmaking

Every quarter we get a version of the same call. A well-funded Australian scaleup wants to hire their first “real” AI engineer. The brief is impressive. The compensation is generous. Six months after the hire lands, the team has not shipped, the founder is frustrated, and the AI engineer is quietly interviewing elsewhere. Six months after that, both parties give up.

We have run this search often enough to be able to describe the pattern precisely. And the failure is almost never the candidate.

What the brief usually says

The brief reads like it was written from a job description at a US frontier lab. Senior or Staff ML engineer. Publications preferred. Deep learning specialism. Experience with large-model training. Familiarity with distributed systems. The compensation is calibrated against the US frontier-lab market minus a discount for being in Sydney.

That profile - the research-heavy, publication-track ML engineer - is a real profile. It is not usually the profile the scaleup actually needs.

What the scaleup actually needs

Most Australian scaleups building AI features are not training foundation models. They are integrating existing models into a product, building the surrounding data infrastructure, and iterating on the parts of the product where model outputs meet user experience. That work is closer to product engineering with an ML component than to research.

The engineers who are good at that work are a different profile. They have shipped ML in production at somewhere serious. They have opinions about latency, cost, evaluation, and how to fail gracefully when the model does something unexpected. They can read a research paper and translate it into what would need to change in the current codebase to try the idea. They are not - and this is important - the same people who would be competitive candidates for a Meta or DeepMind research role.

Both profiles exist in the market. They are not interchangeable and they are not, on average, priced the same.

Why the wrong hire is the default

Two reasons.

First, the founders writing the brief have usually read a lot about AI over the last twenty-four months and their mental image of “the best AI engineer” is shaped by public frontier-lab work. That is what they think they are hiring against.

Second, the research-heavy candidate is easier to identify. Their credentials are legible: paper count, citations, thesis, brand-name lab affiliations. The applied-ML product engineer is harder to spot on a CV. Their strongest signal is often the specific product feature they shipped and how well it works, which is not on LinkedIn.

The result: the brief calibrates for the legible profile, the hiring process filters for it, the offer lands with a strong candidate against that spec, and the candidate joins a firm whose actual work is not what they were hired for. Six months later they are unhappy. Not because the firm did anything wrong, but because the profile does not match the work.

What the brief should say

The brief that produces a good hire in this category is usually shorter and more specific. It names the actual product feature the engineer will own. It quantifies the current state - “our model does X and gets Y accuracy, we need Z”. It is honest that the work involves the boring 80% of ML engineering: evaluation harnesses, cost management, dataset curation, the plumbing between the model and the rest of the product.

Candidates who are excited by that brief self-select in a way that a generic “Senior ML Engineer” ad does not permit. The offer lands with someone whose next twelve months are exactly what they wanted, and the firm gets an engineer who is still there in twenty-four months.

What we push clients toward at intake

We push three things on this class of search.

We push the founder to spend a serious hour before we take the brief describing the actual first product feature the hire will own. If they cannot describe it, the hire is premature - what they need first is clarity on the product, not the candidate.

We push against publication count as a filter for anything other than research roles. Publications are a signal, not a proxy. Two of the best applied-ML engineers we have placed in the last two years have zero papers.

We push for at least one interview stage that is a working session on the actual product, not a whiteboard puzzle. Whiteboards select for a different skill than shipping.

The scaleups that hire well in this category are the ones that treat the AI engineer like a product engineer with a specialist skill, not a research scientist who happens to be doing product work. It is a different mental model. Once a firm has made the mistake once, they usually do not make it again.