A Forward Deployed Engineer is not the answer to every problem. Sending one at the wrong problem wastes a senior person and a lot of money.

So let's be honest about the fit. An FDE is a builder who embeds with your team, works the problem in the room, and ships a real system. That is expensive, and it should be. You do not spend that on work that a good vendor or a clear spec would handle just as well.

Here is where the role earns its cost, and where it does not.

Send one when the last mile is the risk

The FDE fits when the problem is ambiguous, high stakes, and cuts across functions. That describes most serious AI and cybersecurity work.

The data backs this up. An MIT NANDA report from August 2025 found that around 95 percent of enterprise generative AI pilots produced no measurable profit-and-loss impact. The report has taken some methodological criticism, so treat the exact figure with care. The cause it named is the important part. The failures came from the "learning gap," the hard work of fitting AI into how a business actually operates, not from weak models. Gartner points the same way. It predicted at least 30 percent of generative AI projects would be dropped after proof of concept by the end of 2025, and more than 40 percent of agentic AI projects canceled by the end of 2027.

Those failures share a pattern. The technology worked in a demo. It died on contact with the real org. Approvals, data access, edge cases, who owns the output, what happens when it is wrong. That is the last mile, and the last mile is where an FDE lives.

Send one when the following are true.

  • The problem is not yet well defined, and defining it correctly is half the work.
  • A wrong answer is costly. A breach averages 4.88 million dollars by IBM's count. A bad AI action against live payment or customer data can be worse.
  • The work crosses engineering, security, legal, and the executive team, and no single group can solve it alone.
  • You need a decision and a running system, not a report that recommends both.

In those cases the FDE reads the ground truth, decides, builds, and stands behind the result. That is the job.

Do not send one for well-scoped commodity work

Now the other side, because it matters just as much.

If the work is clearly specified and routine, an FDE is the wrong tool. Standing up a standard website. A known integration with a documented API. A migration with a runbook. Reporting dashboards on clean data. This is real work and it needs to be done well. But it does not need a startup-CTO-grade builder embedded with your board. A capable vendor, a contractor, or your own team will do it faster and cheaper.

The signal is simple. If you can write a tight spec and hand it off with confidence, hand it off. The value of an FDE comes from absorbing ambiguity. Give one a fully defined task and you are paying a premium for judgment the task does not require.

Two more cases where you should not send one.

  • The problem is purely organizational. If the real issue is that two executives will not agree, no engineer fixes that. Solve the human problem first.
  • You are not ready to ship. If the organization will not let anything reach production for another two quarters, an FDE will sit idle. The role is defined by shipping. Without that, you are paying for a very expensive advisor.

The honest tension

There is a fair objection to all of this. The FDE label is having a moment. Andreessen Horowitz called it the hottest job in tech in 2025. OpenAI built a team, posted base pay between 162,000 and 280,000 dollars plus equity, and in May 2026 launched a deployment company with more than 4 billion dollars behind it and roughly 150 forward deployed engineers. When a role gets hot, everyone renames their existing service to match it.

So screen for the real thing. A real FDE ships production systems, not slides. A real FDE will tell you when your problem does not need one. That second point is the tell. Someone who says yes to every engagement is selling a title, not doing the work.

I have sat on both sides of this. As a CEO, CIO, and CISO, I have hired the wrong help for well-scoped work and overpaid for it. I have also watched high-stakes AI and security programs stall for want of one person who could hold the boardroom and the codebase at the same time. The skill is not just building. It is knowing which problem is in front of you.

What to do

Before you engage anyone, sort your problem into one of two buckets. Well-defined and routine, or ambiguous and high stakes. If it is the first, write the spec and hire accordingly. If it is the second, and the last mile is where your risk sits, that is when an FDE is worth it.

If you are not sure which bucket you are in, that uncertainty is itself a sign. Let's talk it through. Reach me at marklynd.com.

Sources