Forward deployed engineering in the Netherlands

What is a forward deployed engineer?

A forward deployed engineer builds inside your organisation instead of advising from the outside. In the Netherlands that role has an extra requirement most buyers discover too late: the people who know how the work really happens speak Dutch, while the decision and the reporting happen in English. Scoping fails in that gap.

The role itself is not new. It became widely known through American software companies whose products were too unusual to explain in a manual, so they sent engineers in alongside them. What is new is that the same translation problem now surrounds AI, which is why the title suddenly appears everywhere.

Why does language matter more here than you would expect?

Because the useful information sits with people who will not volunteer it in a second language.

The planner who knows why one field is always left blank. The operator who does a step in a different order than the manual says, for a reason nobody ever wrote down. The person in accounts who keeps a spreadsheet beside the system because the system cannot do one particular thing.

None of that surfaces in a workshop held in English. It surfaces standing next to someone while they work, in their own language, at the moment they feel comfortable enough to say “we never actually do it that way”. If your engineer cannot have that conversation, the specification will be tidy and wrong.

The reverse matters just as much. Once it is understood, it has to be explained upward in English, to people who need the trade-off in business terms rather than technical ones. Those are two different skills and you need both in the same person, because every handover between them loses something.

What does this mean for a Dutch operation?

Three practical consequences.

Do not accept a scoping phase that happens only in meetings. Ask where the engineer will physically be, and for how long. If the answer is “workshops with the stakeholders”, you are buying a document.

Check who actually turns up. At agencies that supply engineers by the day, the person in the sales meeting is frequently not the person on your site. Ask by name.

Expect the first finding to be uncomfortable. Almost every time, scoping turns up something that has been done the hard way for years. How that is handled decides whether the project survives — it should arrive as information, with the context of why it once made sense, not as somebody’s mistake.

What should you check before you sign?

Five questions, none of which require you to be technical.

1. Does this person build, or only configure? Production code, databases, integrations. Someone who can only set up existing packages is a consultant with a newer title. 2. Can they break a vague problem down? “Our quoting is too slow” is a complaint, not a brief. Watch whether they turn it into concrete steps inside one conversation — and whether they say out loud which part they will not do. 3. Will what already runs keep running? New software has to live alongside old systems. “We’ll just replace that” is a bigger risk than the problem you hired them for. 4. Are they experienced? The engineering community is broadly agreed that this is not an entry-level role; it asks for breadth rather than one speciality. 5. Do they explain in your words? A choice between two designs should be explained in what it costs and what it returns. This is the most important test and the only one you cannot verify in advance — which is exactly why a short first assignment beats a long meeting.

Do you need one at all?

Often not, and it is cheaper to find that out now.

If a standard package covers your need, buy the package. If you already know precisely what has to be built, buy a fixed scope from a builder. This way of working exists for the case in between: the problem is real, it is not yet sharp, no package covers it, and somebody has to come and find out what actually needs to happen.

How do we work?

We are a small Dutch company based in Almere. The engineer who spends those first days on your floor is the one who builds it afterwards, and they work in Dutch downstairs and English upstairs without either version being a summary of the other.

We start with a short, bounded assignment: a few days on site, then a written proposal stating what we would build and what we would deliberately leave alone. You can say no to it without being committed to anything, and the description is yours — take it to another supplier if you prefer.

More about the company: what we do and the two founders. The subject is covered at greater length in Dutch, in the full Dutch explainer and on de Nederlandse pagina over inhuren.

Call +31 36 52 98 447 or email info@cloudzicht.nl.