Forward Deployed Engineer vs Consultant vs Staff Augmentation

These three models are sold with similar language, priced in similar units, and written into similar contracts. They solve genuinely different problems, and buying the wrong one is expensive in a way that takes months to become visible.

Why these get confused

All three put an external technical person next to your team for a period of time, billed by day or month. From procurement's side they are nearly indistinguishable.

The difference is not what you are buying by the hour. It is what the engagement is allowed to change.

The one question that separates them

When this person finds that the plan is wrong, what happens next?

Consultant: they tell you, with evidence and a recommendation. You decide.
Staff augmentation: they raise it, then build what the backlog says.
Forward deployed engineer: they change it, and tell you what they changed.

Everything else follows from that.

Side by side

	Consultant	Staff augmentation	Forward deployed engineer
You are buying	Judgement	Capacity	Discovery + delivery
Primary output	Recommendations, designs, assessments	Shipped backlog items	Shipped changes to the right thing
Who decides what to build	You, advised	You	Substantially them, with you
Requirements	Often the deliverable	Assumed to exist	Assumed to be wrong
Writes production code	Sometimes	Yes	Yes
Needs deep environment access	Some	Moderate	Total - it is the model
Scales by adding people	Reasonably	Yes	Poorly
Cost per head	High	Lowest	Highest
Fails when	Advice is not acted on	Backlog is wrong	Access or authority is withheld
Best for	Unclear direction	Clear plan, not enough hands	Unclear problem in a complex environment

Consultant: buying judgement

You engage a consultant when you do not know what to do and want someone who has seen the problem before.

Works well when the question is genuinely strategic, an outside perspective carries weight internally, or you need an assessment before committing budget.

Fails when the recommendation lands in an organisation that cannot act on it. The classic failure is a good strategy document and no change, because implementation was always the hard part and it was out of scope.

Tell-tale that you have picked wrong: you already know what to build and are paying someone to confirm it.

Staff augmentation: buying capacity

You engage augmented staff when the plan is sound and you need more hands.

Works well when the backlog is genuinely well specified, the architecture is settled, and the work is parallelisable. This is the most efficient of the three by a wide margin when the conditions hold.

Fails when the backlog is wrong. Augmented engineers are structurally not positioned to challenge it - they were brought in to execute, they usually lack the domain context to know better, and raising it is not what they are measured on. So the wrong thing gets built, efficiently, and the problem surfaces at delivery.

Tell-tale that you have picked wrong: the team keeps hitting requirements that turn out to be based on a misunderstanding of how the business actually works.

Forward deployed engineering: buying discovery plus delivery

You engage an FDE when you are not confident the problem is correctly framed, and the environment is complex enough that you will only find out by being in it.

Works well when the deployment environment is genuinely idiosyncratic, the domain is complex, the cost of building the wrong thing is high, and you can grant real access - to systems, to users, and to the meetings where context lives.

Fails when access or authority is withheld. An FDE without environment access is a remote contractor. An FDE without permission to change things is a consultant. Either way you are paying the highest rate of the three for a cheaper model.

Tell-tale that you have picked wrong: the requirements really were clear, and you are paying a premium for discovery you did not need.

The mismatch that wastes the most money

By a distance: buying staff augmentation when the problem was discovery.

It is the natural default. It is the cheapest per head, procurement understands it, and every project believes its requirements are clear. So the team scales up, works the backlog efficiently, and delivers - and then it turns out the backlog encoded a misunderstanding of the operational reality. The efficiency made it worse, because more of the wrong thing got built before anyone noticed.

The reverse mismatch - FDEs on well-specified work - wastes money too, but visibly and fast. You notice you are overpaying within weeks. The first one hides until delivery.

A rough diagnostic: if the last three projects in this area shipped and then needed significant rework because of something nobody knew at the start, your problem is discovery. No amount of additional capacity fixes that.

How to choose

Four questions, in order:

1. Do you know what to build? No, and it is a strategy question → consultant. No, and it is an environment question → FDE. Yes → continue.

2. Do you know it from evidence, or from assumption? Be honest. Requirements written from a distance are assumptions. If nobody has watched the actual work being done, you know less than the document suggests.

3. Can you grant real access? If a vendor cannot sit with your users, reach your systems, and attend the meetings where context lives, an FDE model cannot work. Choose something else rather than paying for a model you cannot support.

4. Is the constraint capacity or insight? Capacity, with a plan you trust → staff augmentation. Insight → FDE.

Questions to ask a vendor

Regardless of which model you think you want, these expose what you are actually buying:

"What can your engineer change without asking us?" A vague answer means consultant pricing for consultant work, sold as something else.
"Who decides what gets built in week six?" If the answer is "your backlog", it is augmentation.
"What access do you need, and what happens if we cannot give it?" A vendor who says access does not matter is not offering forward deployment.
"How does what you learn here reach your product team?" For a product vendor, this separates a real FDE practice from a bespoke services arm.
"What does success look like at the end, and does the engagement shrink?" A healthy FDE engagement should reduce its own necessity.

The answers will usually tell you more than the proposal does.