Forward deployed engineer vs solutions architect

A solutions architect designs the implementation. A forward deployed engineer builds it. That is the whole difference, and every other distinction follows from it.

The test

Ask one question: who merges the pull request that puts this into production?

If the answer is the customer's team, or another delivery team, or a partner, the role you are describing is architecture. If the answer is the person you are talking about, it is forward deployed engineering.

This test works because it cannot be answered rhetorically. Repository access is a fact somebody has to provision.

What each role optimises for

A solutions architect optimises for repeatability. Their output is a design, an integration pattern, a reference architecture, and a set of decisions that will hold up across many customers. Success looks like the next five implementations going faster because the pattern existed.

A forward deployed engineer optimises for one customer reaching production. Their output is a running system. Success looks like the thing working on real data, for real users, inside an environment they did not build.

Those two goals conflict in a useful way, which is why mature organisations run both. The architect stops the company from re-solving the same problem eleven times. The engineer finds out what the architect's pattern gets wrong when it meets a company whose identity provider was configured in 2014.

Where they genuinely overlap

The first two weeks look almost identical. Both roles are talking to users, reading the existing systems, and working out what the constraints actually are. Both are producing sketches. Neither has built anything.

The divergence starts when the design is settled. The architect writes it down and moves to the next account. The engineer opens an editor.

There is a second overlap worth naming: at companies with fewer than about fifty people, one person often does both, and that is fine. The problem is when a company grows and keeps calling the combined role an architect, because the design half is the half that feels senior and the build half quietly stops happening.

The mistake this comparison exists to prevent

Hiring an architect when you needed an engineer.

The symptom is recognisable: a well-documented plan, an integration diagram everyone agrees with, a decision log, and nothing running. Three months in, the customer's own team was supposed to build it and has not, because they are busy with the roadmap they already had.

This happens because architecture is easier to buy. It is cheaper, it produces artefacts you can review in a meeting, and it does not require giving an outside party repository access. All three of those are reasons it feels safer, and none of them get the system running.

The reverse mistake exists and is rarer: hiring builders with no architectural view, then discovering after the fourth account that you have four incompatible implementations. The productization loop is how mature teams avoid it without hiring a separate architecture function.

How they show up in a vendor conversation

When a vendor proposes a solutions architect, ask what happens after the design is delivered, and who is contractually responsible if the implementation stalls. A vendor selling architecture will say the customer's team implements it. That is a legitimate model and you should know you are buying it.

When a vendor proposes forward deployed engineers, ask for the repository access their engineers will need, and for the production date. If neither answer is concrete, you may be buying architecture with a different label. The three jobs hiding behind the FDE title covers how often that relabelling happens.

Which one you need

You need a solutions architect when the customer has a capable engineering team with capacity, the pattern will repeat across many accounts, and the hard part is deciding the shape rather than building it.

You need a forward deployed engineer when nobody has spare capacity to build it, the environment will invalidate parts of any design written from outside, and you want the same party accountable for the plan and the result.

You need both when you are past a handful of accounts and the custom work has started to look repetitive.

Wikipedia's entry on the forward deployed engineer lists solutions architect among the roles whose responsibilities overlap with it, which is accurate and is exactly why the merge test is more useful than a duty list.

Next: FDE vs sales engineer, or FDE vs staff augmentation if the real question is whether you need hands or an outcome.