There is no certification. Here is what you need instead

This page could have been a course. It is not, and that is deliberate.

Is there a Forward Deployed Engineer certification?

No recognised Forward Deployed Engineer certification exists, from any standards body or vendor-neutral institute. The role has no agreed syllabus because it is judgement work inside somebody else’s business. What employers look at instead is evidence: a process you changed, a system you connected, and someone willing to confirm it.

Why does no certificate exist for this role?

Because there is nothing stable to examine. A certificate works when the body of knowledge holds still and the right answer is the same in every company. Here the right answer depends on the business you are standing in, and half the skill is deciding which question to answer at all.

You can certify a tool. You can test whether someone knows a query language or a cloud platform, and those exams are honest about what they cover. What no exam can put in front of a candidate is a room with two managers who disagree, an export that changes format on the last Friday of the month, and a decision about whether to build anything.

What about the training courses being advertised?

Some are genuinely useful, but read what they teach. Almost all of them cover the tools: model APIs, retrieval, a cloud stack. That is worth learning and it is the easiest part of the job. None of them can teach the part that gets people hired, because that part needs real stakes and a real business.

A short test before you pay for anything: does the course end with a project of your own choosing inside an organisation that will still be using it next month? If it ends with a graded exercise, you have bought tooling knowledge. Buy it knowingly, at the price of tooling knowledge, and do not expect it to open a senior door.

How much do Forward Deployed Engineers get paid?

I do not know, and I am not going to guess. The figures circulating online come from a handful of self-reported posts across wildly different markets, company sizes and contract types. Averaging them produces a number that looks authoritative and describes nobody. If you need a real figure, ask three people doing the job in your own market.

What I can tell you is what moves the number, which is more useful than a false average. Scope moves it: someone who is handed a specification is paid differently from someone who decides what gets built. Risk moves it too, because carrying responsibility when a live process breaks is a different job from delivering a feature.

Why does this page quote no rate?

Because I would have to make one up. There is no reliable public data for this role, and a number invented for the sake of completeness is worse than an admission, since people plan around it. Any page that gives you a confident range for a job title this new is guessing with a straight face.

The same applies to my own work, which is why you will not find a price list here either. What something costs depends on what breaks if it is wrong, and that is a conversation, not a table.

What do you need instead of a certificate?

Three kinds of evidence, and they are all things you did rather than things you attended. A process you measurably changed. A working connection between two systems that had no reason to talk. And a moment where you argued against building something and can explain why you were right.

The third one surprises people. It is the strongest item on the list, because anyone can point at a thing they made and very few candidates can point at a thing they prevented. It shows you understand the cost side, and it is the difference between a builder and someone trusted near a business. I have written the reasoning behind advising against a project out in full.

How do you prove it without a qualification?

By describing one piece of work in enough detail that it could not have been faked. What the situation was, what you measured before, what you changed, what it cost, and what you got wrong on the way. The wrong parts do more work than the successes, because they show you were actually there.

Two rules make this land. Use numbers you can defend and leave out the ones you cannot; a vague “significant improvement” reads as decoration. And name the thing that did not work. Every real project has one, and every invented project is suspiciously clean.

Here is the format applied to a real case, including the number I refuse to dress up: one finished piece of work, with the numbers.

Where do you start if you are already a developer?

Go and sit with the people who use what you build, for a full day, without a laptop open. You are looking for the workarounds: the sticky note on the monitor, the spreadsheet kept alongside the official system, the step everyone does twice. Those are the real requirements, and they are never in the ticket.

The technical gap for most developers is smaller than they think. The habit gap is larger. You will have to stop optimising the thing in front of you long enough to ask whether it should exist, and that is uncomfortable for anyone who takes pride in the craft. Which parts of the standard skill list matter here is covered separately: the skills that actually decide it.

Where do you start if you come from the business side?

Learn SQL first, and learn it properly rather than as a party trick. Being able to count things yourself changes every conversation you have, because you stop relying on other people’s summaries. After that, learn to make one API call and put the result somewhere useful. That combination already puts you ahead of most people who only talk about processes.

You will hit a wall where you can see exactly what should exist but cannot build it reliably. That wall is fine and it is where partnerships form. Knowing the difference between a demo and something a business can lean on is itself a piece of judgement, and it is worth admitting where yours currently ends.

If you want the honest picture of the work before deciding to aim at it, this is what the work consists of day to day.

Marc Herdes, Almere, 4 September 2026. I run five companies and sell no courses, which is the only reason I can afford to write this page.