One question decides whether this hire works, and it deserves an answer before the advert is written: do you want somebody to build a platform, or somebody to operate one?

A company with two models in production needs somebody who can ship them, watch them and take them back out when they misbehave. A company with forty needs somebody to build the road everybody else drives on. Both answer to the same title and apply to the same advert, and hiring one when you wanted the other surfaces in month five.

Build the road, or drive on it?

The builder wants a blank cloud account and a mandate. They think in abstractions, and their instinct on meeting a hand-rolled deployment is to replace it with something generic. Give them two models and they will build a platform for two models, which takes nine months.

The operator wants something already running and a list of things wrong with it. They think in incidents and cost lines, and will keep an ugly thing alive because it earns money. Give them forty teams and a standardisation mandate and they will firefight instead.

Neither is the lesser engineer. Ask what they did in the first month of their last job, then in the last, then which they preferred: builders describe something that did not exist and now does, operators a number that was bad and is now good.

The ladder, and why you should hire one rung up

Rung one. Models are trained in notebooks and deployed by whoever trained them; nobody is certain which version is live. You need somebody who can containerise a model and write down what runs where — not a platform person.

Rung two. Deployment is repeatable, retraining is scheduled, and one place records what is serving. One engineer holds the estate in their head.

Rung three. Several teams deploy, so you need shared conventions, monitoring somebody reads, and a way to withdraw a model that does not depend on one named person. Most UK teams doing this seriously sit here.

Rung four. Self-service: teams ship without the platform group in the loop, and policy is enforced by the pipeline, not by a meeting.

Locate yourself honestly, then hire for the rung above. Two rungs up gets you somebody building for a problem you do not have; at your current rung you get somebody overwhelmed the moment the estate doubles.

The best probe is removal, not release

Everybody has a deployment story. Far fewer have one about taking something back out.

How long does it take to get a bad model out of production? Good answers are measured in minutes and involve pointing traffic at the previous version, which means that version is still there and warm. Weak answers involve retraining or a release window.

Has anybody rehearsed it? A path that exists on a diagram and has never been exercised will fail when it matters, usually because the feature code moved on and the old model no longer gets the inputs it expects. Candidates who have practised one tell you what broke the first time.

Who is allowed to press it

If only the platform group may withdraw a model, the people who see the damage first — analysts watching conversion, support reading complaints — must escalate to somebody who will ask them to prove it. If anyone at all may withdraw one, you get unexplained reversals and nobody trusts the numbers.

What you want is a small named group, a documented trigger, and a deliberate asymmetry: putting a model in requires approval, taking one out never does. Candidates who have lived through a bad release reach for that at once.

Draw the line before an incident draws it for you

The failure we see most often is not about technical ability. It is an undefined boundary between the data team that produces the features, the platform team that owns the cluster, and this person in the middle.

When a prediction goes wrong, the cause is an altered or stale feature table more often than it is the model, and “whose alert was that?” has no owner. Your hire chases data problems they cannot fix, and spends half a year translating between two teams.

Settle three things in writing first: who is woken when a prediction is wrong, who is woken when the feature job fails, and who may declare a model unfit to serve. If the answer to all three is “the person we are about to hire”, you are advertising a single point of failure.

If the data team already runs its own orchestration and registry, decide whether your hire inherits those or works around them — the MLflow engineer guide covers what a registry should do for you, the ML pipeline engineer guide the upstream half. Reliability without authority over the things that determine it loses good hires inside a year.

Pay, and the bigger market next door

Indicatively £75,000 to £110,000 for operating an existing estate competently, £95,000 to £135,000 for a record of building something other teams chose to use. Day rates indicatively from around £550, towards £750 for build work.

Then a figure that should change how you advertise rather than what you pay: exactly one employer puts this term in a job title anywhere in our crawl of 1.1 million UK careers pages. The work is plainly being done at hundreds of companies, advertised as platform engineer, site reliability engineer or machine learning engineer.

These candidates compete in the wider platform-engineering market, which is much larger and pays at least as well. You are bidding against every company that needs somebody good at deployment and reliability. Being concrete about what is unusual here beats another few thousand on the range.

Backgrounds that transfer, and one that usually does not

The conversion that works is the infrastructure or backend engineer who has become interested in models: instincts about blast radius, cost and reversibility, plus the lesson that a model degrades quietly rather than failing loudly. Those instincts take years; the model-specific part takes a few months and one bad week.

The conversion that usually disappoints is the data scientist who picked up the tooling. It can work, and when it does the person is unusually good, but the tell is whether they have ever owned the consequences of something they built being wrong in front of customers.

If your real difficulty is the cluster underneath rather than the lifecycle on top, the Kubeflow engineer guide is the closer match.