Forward deployed engineer vs consultant

A consultant delivers what the contract says. A forward deployed engineer delivers a working system. Most of the time those produce the same activity, and they diverge sharply at one specific moment.

The test

Ask what happens on the day somebody discovers the agreed approach will not work.

In a consulting engagement, that triggers a change request. The scope is the contract, so changing the work means changing the document, which means a conversation about time and money before anybody writes different code. This is correct behaviour. It is what the contract is for.

In a forward deployed engagement, the engineer changes the approach and keeps going, because what they are accountable for is the outcome rather than the scope. The conversation about time and money still happens, and it does not block the work.

That day arrives in most non-trivial engagements. Which model you are in decides whether it costs you three weeks or an afternoon.

Why the difference exists

It comes from what each model assumes about knowledge at the start.

Consulting assumes the scope is knowable in advance. Somebody can describe the work well enough to price it, and the discipline of the model is delivering that description faithfully.

Forward deployment assumes the scope is discovered by doing the work in the real environment. The specification is an output rather than an input, which is why the engineer has to be inside the environment and why they need the authority to change direction.

Neither assumption is generally correct. They are correct about different situations, and picking the wrong one is expensive in both directions.

The criticism of specification-taking

Marty Cagan made the sharper version of this argument in his September 2025 piece on the role. His contrast is with traditional consulting, which accepts client specifications without accountability for whether the result works, and often produces failed implementations in which every party met their contractual obligations.

That is the failure mode worth naming, because it is invisible while it happens. The consultant delivered the scope. The client signed off each milestone. The system does not produce the outcome anybody wanted, and no clause was breached.

Forward deployment is one answer to that. It is not the only one: a consulting engagement with an outcome-based contract and a client who will change the scope when the evidence says to gets most of the same benefit. Outcome-based pricing covers how to write that.

Where consulting is the better buy

We sell the embedded model, so this section matters more than the rest of the page.

When the scope is genuinely knowable. If you can describe the work in enough detail that a competent team could deliver it without you in the room, buy delivery. Discovery you do not need is expensive.

When the problem is a known category. A migration between two well-documented platforms, a compliance implementation against a published standard, an integration with a vendor whose API is stable. These have been done before, the unknowns are small, and a firm that has done it forty times will beat a team discovering it once.

When you need breadth over depth. Consulting firms field large teams across many disciplines quickly. If the work is wide and shallow rather than narrow and deep, that shape fits better.

When procurement requires a fixed price. Some organizations cannot buy an outcome, structurally. A fixed-scope, fixed-price engagement is what their process is built to purchase, and fighting that costs more than it saves.

Where the embedded model is the better buy

When nobody can specify the answer. This is the original condition and it still decides the question. If the honest answer to "what should this do" is "we will know when we see it running on our data", a specification written in advance is a guess you will pay to implement.

When the environment will invalidate the plan. Large organizations contain systems nobody documented and processes that differ from the description. A plan written from outside meets those in week six.

When you want one party accountable end to end. Splitting the plan from the build creates a seam, and the seam is where responsibility goes missing. FDE vs solutions architect covers that seam directly.

What about professional services teams

A vendor's professional services group sits between the two. It delivers scoped implementations of that vendor's product, usually against a statement of work, with product expertise a general consultancy lacks.

The thing to check is whether the group can build outside the product's supported surface, and whether findings from the field reach the product roadmap. Cagan's warning is that a separate professional services unit kills the feedback loop and drifts the company toward a pure services business. From a buyer's side, the symptom is being told your requirement is on the roadmap for three consecutive quarters.

Reading a proposal

The words in a proposal do not settle this. Two questions do.

What happens, contractually, if the approach we agreed turns out to be wrong in month two? And what is the deliverable: a system in our production environment, or a set of artefacts we then implement?

A consulting proposal answers the second question with artefacts and a handover. A forward deployed proposal answers it with a running system and a production date. Both are honest answers. Only one of them is what you thought you were buying if you did not ask.

Next: FDE vs systems integrator for the procurement version, or when the embedded model is the wrong answer.