Hiring a Forward Deployed Engineer

I sit on both sides of this. I do the work inside my own companies, and I have also written the advertisement, read the applications and been wrong about somebody. Nearly every page about this role answers the applicant. This one is a checklist for you.

What are you actually hiring for?

Your advertisement tests knowledge and the work tests behaviour, which is why the two so rarely meet. You are hiring for translation: someone who can take what is in a person’s head, half-said and half-contradictory, and give it back in a shape that person recognises. Tools are learnable. That is not.

Everything below follows from that gap: four of the five things I look hardest at are behaviour, and none fits in a competency grid.

Why does the standard skills list give you the wrong shortlist?

Because it filters on what is verifiable rather than on what is scarce. A language, a database, a model API — each can be checked in an afternoon and picked up in a fortnight. Filter on those and you get a shortlist of capable builders, sorted by nothing that predicts whether the thing they build will be the right thing.

A list of technologies also attracts people who like technologies. The person you want has probably spent recent years arguing with a warehouse manager about which of two spreadsheets is correct, and reads as the less impressive application. Which parts of the list are genuinely rare: which parts of that list are scarce.

What should you screen for instead?

Communication, and then communication again. Not as a line beneath the technical requirements, but as the heaviest item on the page. Half of this job is making something complicated understandable to a person with no reason to care. The other half is making a business understandable to whoever has to build for it.

The practical version is a translation test. Describe a real problem of yours badly on purpose, out loud, the way a manager would, then watch what comes back. You are not measuring whether they solve it, but whether your own situation returns to you in a form you recognise, with the two questions attached that actually decide it.

Watch how much your interview rewards agreement. Reward it and you hire the human version of a model: something that does precisely what you asked and never says the request was wrong. Ask a model twice and the answer improves, but it still answers the question you gave it. Somebody here has to be the part that disagrees, and it will not be the software.

How do you know when you have found the right person?

Almost never from the curriculum vitae, and rarely from a prepared answer. The moment arrives when they hit something they do not know, or when you contradict them. Watch the ten seconds that follow. That reaction is the closest thing to a reliable signal this role offers you.

What you want is somebody who says they do not know, then asks the question that would settle it. What you do not want is a fluent recovery: anyone senior can talk past a gap, and the ones who do it well sound like competence.

Pushing back tests the other half. Somebody who folds at once will fold in front of your finance director on the day it matters, and somebody who cannot be moved is worse. Listen for a person who asks what you know that they do not.

Does this person fit your company?

There is no universally good candidate for this, which is uncomfortable to accept when a strong application is in front of you. The whole role exists because somebody is standing next to the people doing the work. Excellent technically, and unable to spend an afternoon on a warehouse floor, adds up to nothing here.

Fit is narrower and easier to test than the word suggests. Can they be understood by a fitter, an administrator and a director in the same hour? Bring somebody who does the work into the interview for twenty minutes and let the candidate question them while you watch.

What does it mean when somebody makes a simple thing complicated?

Take it as a warning rather than as depth. In a role where half the work is making complexity plain, hiding behind vocabulary contradicts the job. The candidate who explains your own process back to you in ordinary words has already demonstrated the thing you are buying.

A second tell sits in one grammatical join. Listen for the difference between “that was not possible because” and “that could not be done that way, so I”. The first hands the problem back with reasons attached. The second is the person you are looking for.

Who will they be allowed to talk to, and who is allowed to decide?

Every useful thing this person finds will come from somebody who was not in the meeting that hired them. There are three sides to any process: the people who cannot see why it is slow, the people living inside it, and whoever has to build the replacement. Block one side off and the work stops.

Write the names down before you advertise. Not roles, names: who does this daily, who owns the numbers, who maintains what gets built. Then name whoever can decide which of two systems is the true source. If that is a committee, add its meeting cycle to every estimate.

Whose judgement decides what happens too often?

Somebody has to say which tasks come round too often, and that word is a judgement rather than a measurement. How often something happens is a fact you can count. Whether it happens too often belongs to the person doing it. Supply that judgement from above and you get a list of your own irritations.

The method is six columns, filled in beside an employee rather than written about them: what they enjoy, what they enjoy less, what they do often, what they do too often, what comes back to everybody, where mistakes happen. The first two matter most: the enjoyable parts are the ones you must not remove by accident.

Are they allowed to tell you something you do not want to hear?

Sooner or later they will find that something has been done the hard way for years, and that whoever designed it is still in the building. That is the most valuable output of a first month, and the least welcome. Decide now, in writing, who it goes to.

Delivering it well is their job: good information rather than a verdict, given to the person before it reaches their manager. Receiving it is yours. The larger version of that sentence is that nothing should be built, and if that outcome ends the engagement you have instructed everybody you hire to find a reason to build: the honest answer is that nothing should be built.

What does it cost you when the hire is wrong?

Not money — access. A wrong hire spends your people’s goodwill, and goodwill here is close to a one-shot resource. After a badly handled first round the person on the floor stops mentioning the workaround, the department head starts routing questions through a manager, and whoever you send in next gets the official version of everything.

Say in advance what the freed-up hours are for, because your team reaches that question before you do and they are not being paranoid. A proper conversation with a customer, ringing somebody back to check the job went well, helping a colleague. Resistance is legitimate: a long-serving colleague can read automation as a threat and be right about the risk. Aim for the middle, where the company stays viable and the people worth keeping feel valued.

If it were easy, anyone could do it, which is why I would not hand the judging of it to somebody who has never been on the hook for a live process. The questions I would ask, with a real answer set against a rehearsed one: the questions that do the actual work. And one thing to settle before you advertise: whether you are advertising a new job at all.

Marc Herdes, Almere, 4 September 2026. I do this work and I hire for it, which is the only reason this page is written from your side of the table.