Forward Deployed Engineer or business analyst?

The blunt version of this question turns up on every forum where the role is discussed: have these positions not always existed? The people asking are usually not being cynical, and they are mostly right. I want to concede that properly before arguing with the small part of it that is wrong.

Is a Forward Deployed Engineer just a business analyst with a new name?

Mostly it is the older job, and the people saying so are not being cynical. In daily practice I call this a business analyst: somebody analytical who can turn what a person means into a functional design and a working solution. Two things genuinely changed, and neither of them is the title.

I have written elsewhere that the work is old and the label is new. This page is about how much of it is old, which turns out to be nearly all of it, and what the remainder actually consists of.

What did the older titles already get right?

The important word in “business analyst” is analyst, and it names the real task: take a situation nobody can describe cleanly and work out what is going on. That has not changed. Nor has the half that comes after it, which is handing the result to whoever has to build the thing.

Systems analyst, implementation consultant, application consultant, solutions engineer — each of those names somebody standing between a business and a system, and not one was invented as marketing. Each described something a company genuinely needed. Waving them away makes you sound like you arrived last week, and the people who held those titles will notice.

So is anything about it genuinely new?

Two things, and both are smaller than the marketing while still being real. A model now sits inside the workflow rather than beside it, which moves the bottleneck. And what gets made is no longer delivered at the end; it is built in front of the customer while they are still deciding what they want.

Neither is exactly a new skill. Both change what a day looks like enough that the old title stops describing it accurately. That is a fair reason for a new word and a poor reason to announce a new profession.

Why does a model in the workflow change the role rather than the tools?

Because it makes building cheap and describing expensive. A model produces whatever you describe, quickly and without arguing, and asked a second time it produces a better version of the same misunderstanding. The scarce thing is no longer an ability to build. It is knowing what to describe.

Models are yes-men, which is not a complaint; it is what they are for. But nothing complicated ever came out of a thing that agrees with everything, so somebody has to be the part that disagrees. In a longer delivery chain that job was spread about: a developer pushed back on the specification, a tester found the gap, somebody fought over scope. Compress the chain and every one of those objections has to come from the same person, which is the scarce part of the skill list.

What changes when you build alongside somebody instead of delivering to them?

The solution usually does not exist yet. It has to be invented, made and then kneaded: you cross a threshold, you test it, you have to feel whether it is right, and sometimes you have to convince a whole team. However good a thing looks on paper, that is still not the same as it working.

The older arrangement kept a document between you and the work, and the document was protection. Sign here, and if it turned out wrong, it had been specified. Build alongside somebody and there is nothing to stand behind: you show a half-finished thing to the person who has to use it and change it while they watch. Here is a build that happened in front of the person using it.

Then why did the older titles lose their meaning?

Because in a great many organisations the analyst stopped being allowed near the system. The title survived and the access did not, so it came to mean somebody who writes a document that a developer later reinterprets. That is a drift in how companies are arranged rather than a fault in the word.

This is the fair concession to the people using the newer term. They are not renaming the old job; they are naming the version of it that still touches production. And a fresh label is sometimes the cheapest way to win back access that an old one quietly lost, which is cynical and also works.

Does the label matter at all, then?

Only where it decides access. The word on your contract changes nothing about the work and a great deal about who answers your emails, which desk you are given, and whether you are in the room when the decision gets made. That is not vanity. Access is the raw material of the job.

Any process has three sides: the person who cannot see why it takes so long, the person doing it every day, and whoever will have to program the replacement. A title that reaches two of the three is worse than one that reaches all three, whatever either says on paper.

How do you tell which one you are being offered?

Read the advertisement for permissions rather than for skills. Will you touch production or hand over a specification. Who has the authority to retire one of two overlapping systems. Is “we should not build this” an acceptable outcome. A list of technologies tells you almost nothing; a reporting line tells you almost everything.

Ask the question directly and listen for names rather than roles. If nobody can say who you will sit beside on the first Monday, the title is decoration and the job underneath it is documentation. That is the same test from the employer’s side, where the checklist is theirs to fill in rather than yours.

Which word should you use yourself?

Use whichever one your listener already knows. I say business analyst, because everybody I work with has a rough idea what that means, whereas the English term makes people ask what it is before they hear what I actually do. Take the newer label where it opens a door and the older one where it saves a paragraph.

None of the argument about naming touches the part that is difficult. This job asks for creativity, for the ability to take a problem apart, for the ability to translate it twice — once technically and once in ordinary language — and then to stand up and present it. None of that is taught anywhere as a subject. Which decade invented the title is a poor use of an afternoon by comparison.

Marc Herdes, Almere, 4 September 2026. I have used both words this week, to different people, on purpose.