The skills nobody puts in the job ad

Take the standard list seriously first. It usually reads: full-stack fundamentals, meaning Python or TypeScript, SQL, databases and API integrations; then AI and cloud fluency, meaning model APIs, retrieval pipelines and vector databases; then high agency and communication, meaning stakeholder management and explaining trade-offs in business terms.

None of that is wrong. It is just sorted by what is easy to write down, not by what decides whether the work lands. So here is the same list, re-sorted by what it costs you when it is missing.

What skills does a Forward Deployed Engineer actually need?

The published list is real but badly weighted. Full-stack fundamentals and SQL are table stakes, model APIs are the easiest thing on it, and the deciding skill is judgement: knowing which problem is worth solving, and being willing to say out loud that something should not be built at all.

Which skills on the standard list are overrated?

Model APIs and vector databases. They are the newest items and the most exciting to list, so they end up at the top of every ad. In practice they are the fastest part to learn and the least likely part to fail. A capable developer picks both up in a fortnight and then never thinks about them again.

Retrieval pipelines are a slightly different case. The technique is simple; the hard part is that the documents you are asked to search are contradictory, out of date, or written by four people who disagreed. That is not an AI skill. That is knowing which of the four was right, which is a question for someone inside the business.

Cloud architecture belongs in the same bucket for most of this work. If you are building inside one company’s process, you are not designing for scale you will never reach. Being able to run something reliably is enough. Being able to run it for millions of users is a different job with a different title.

What is genuinely table stakes?

SQL, API integrations and being comfortable in somebody else’s codebase. None of these are impressive and all three are non-negotiable. If you cannot get the data out, join it correctly and put a result back where the business already looks, nothing else on the list gets a chance to matter.

Add one item the ads leave out: reading a database you did not design, with no documentation and column names in a language you may not speak. That happens constantly. Half the work of a first week is working out which of three tables is the one people actually use.

Why is SQL more useful here than any model API?

Because almost every request turns out to be a data question wearing a different hat. “Can AI write our quotes” nearly always resolves to “our prices live in two places and disagree”. You find that with a query, not a prompt. The best hour of most projects is spent counting things nobody had counted.

Counting also settles arguments. When someone insists a situation is common and the data shows it happened twice last year, the scope of the project changes in a single sentence. This is why I go looking for numbers before I go looking for a design.

What is the hardest skill of all?

Saying that something should not be built. It is hard because it disappoints the person in front of you, it usually ends the conversation that pays you, and you have to defend it with reasoning rather than enthusiasm. Almost everyone finds it easier to build the thing and hope.

It is also the skill with the clearest failure cost. Build the wrong thing and you do not lose a fee. You lose the trust of everyone who has to use it, and the next honest suggestion you make gets treated as sales. That is expensive for years, which is why I now write the reasoning down before I write any code: the argument for building nothing.

How do you explain a technical trade-off to someone who does not care about technology?

By translating it into what it costs when it goes wrong. Not “this needs a queue”, but “if the connection drops during a busy hour, either you lose the order or the customer waits — pick one”. People with no technical background make excellent decisions when the choice is expressed in consequences they own.

The mistake is simplifying the technology. Do not. Simplify the decision. Anyone running a business is used to choosing between two imperfect options with real money attached; that is most of their week. What they cannot do is guess which two options exist.

There is a second half to this, which is listening in a way that survives contradiction. The person who does the work daily and the person who signs the invoice will describe the same process differently, and both are telling the truth about their own view of it. Your job is not to pick the more senior version.

Does any of this need a big-company background?

No, and the assumption gets in the way. Small companies show you the whole chain: the quote, the order, the installation, the complaint, the invoice, the repeat customer. In a large organisation you are handed a slice of that and rarely find out what happened downstream of your work.

What you do need is to have watched a process end to end more than once, and preferably to have been responsible when it failed. That is what people mean when they say these roles are senior. It is not years. It is having been on the hook.

You can see the shape of it in a small case: a man who climbed down a ladder fifteen times a day did not need a platform. He needed one screen in the right place, and the reason it worked had nothing to do with the technology in it.

Who tends to be good at this?

People who are used to finding a way round. What do you do if you cannot tell certain colours apart? You memorise the order, you count the position, you invent something that makes it work anyway. Do that for years and you become practised at finding a door that does open.

That is an observation, not an explanation. Why the two coincide as often as they do, I do not know, and I am not going to invent a study to support it. What I can see is that the habit is what remains, and the habit is exactly what this work asks for.

Two things belong in that sentence explicitly. You do not need anything of the sort to be good at this: most of the people who are good at it have nothing unusual about them. And it works no better in reverse. It does not automatically make you someone who sees how things connect.

So what a client is buying is not a trait but a habit. Someone who has never been able to take the easiest route is practised at looking for the second one. As Marc puts it: if it were easy, anyone could do it.

What can you not learn from a course?

The moment of recognition. Knowing, ten minutes into a conversation, that the problem being described is not the problem that exists. That comes from having been wrong about it before, in a situation where being wrong cost you something. There is no exercise that reproduces the feeling of your own money being involved.

Which is also the honest answer to a question people keep searching for: no certificate covers any of this. It is not snobbery about qualifications. It is that the thing being tested is judgement under real stakes, and a syllabus cannot supply the stakes.

If you want the concrete version of how these skills get spent across a week, that is what the day actually consists of.

Marc Herdes, Almere, 4 September 2026. Five companies, and every one of them has taught me a different thing on this list.