The Forward Deployed Engineer — Peter Idah

There is a job title spreading through the market right now faster than almost any other in the history of software engineering.

Forward Deployed Engineer.

Job postings grew over 800 percent in a single year.[1] In the first half of 2026 alone, Microsoft committed $2.5 billion to embed 6,000 engineers at customer sites.[2] AWS followed with $1 billion and a programme to place thousands more.[3] OpenAI acquired a pure-play FDE firm in Edinburgh, launched a heavily-funded deployment subsidiary, and then released a managed FDE product to enterprise customers.[4] Databricks formalised a function it had been running quietly for a decade. Deloitte became the first Big 4 firm to formally brand a service line as Forward Deployed Engineering.[5] Combined, the largest technology companies in the world committed somewhere north of $7 billion to this model in the space of six months.

Every company that wants to look serious about enterprise deployment wants FDEs. Recruiters are pushing engineers toward the role. Hiring managers are writing job specs for it without being entirely sure what they are writing.

The mistake is not a small one. Not a nuance mistake. It is structural: companies are paying for one thing and getting another, engineers are building careers that may be leading somewhere they did not intend to go, and the entire function is being measured by the wrong output.

This document explains that mistake. Then it goes further, into what the role actually costs engineers who take it, how to tell which version of it you are walking into, and the single question that cuts through everything.

By the end, you will see the role differently. That is the point.

The moment that explains everything

Imagine you are the person who first put a software engineer inside a customer's environment. Not to demo a product. Not to answer support tickets. To actually live there for an extended period and figure out what needed to exist.

Something unexpected happens.

The engineer starts seeing things that nobody at headquarters has ever seen. Not because the customer was hiding them. Because they were invisible until someone with the right technical lens was standing in the right place.

They see where the product breaks in conditions the product team never imagined. They see what the customer actually needs versus what they said they needed during the sales process, which turns out to be two different things. They see workarounds that have been running for years, invisible to everyone, representing features the product should have built but never did.

That engineer goes back to headquarters carrying something extraordinary: unfiltered contact with reality.

Now here is the question that determines everything about whether this function creates lasting value or just expensive consulting.

What happens next?

The two steps, and why almost everyone stops at one

A real forward deployed function has two steps.

Step one

01

Deploy and deliver

The engineer deploys. They solve the customer's problem, get the product working in a difficult environment, and the customer goes live.

Most companies do this.

Step two

02

Bring it back

Everything discovered in the field flows back into the product. The broken thing becomes a feature. The workaround becomes a roadmap item. The gap becomes the next version.

Most companies stop at step one.

When step two works, every hard deployment makes the product stronger for every deployment that follows. The most difficult customers produce the most product learning. The pain one engineer absorbs in the field becomes the moat against every competitor who has not been in that field.

The practitioners who have lived this role have a phrase for it: the pain is the moat.

When companies only do step one, they have a deployment team. A useful team. A team that generates revenue. But a team whose value is entirely transactional. Customer goes live, FDE moves on, the product is identical to what it was before. Nothing compounded. Nothing built.

That is where most companies running this function right now are. They hired the title. They built step one. They measured deployment speed. And they called it a forward deployed engineering function.

The question worth asking

The $7 billion committed to FDE-style deployment in the first half of 2026 is mostly funding step one at industrial scale. Faster deployments. More clients per engineer. Lower cost per seat. Every enterprise will have AI deployed by the end of 2026 because the deployment machinery is now enormous and cheap.

So where is the competitive advantage if every company deploys the same models, using the same platforms, through the same FDE playbook?

"You don't uniquely benefit from AI. The ultimate beneficiary of AI will be our customers. In a competitive capitalist world, we all will use AI to do a better job for the customers."

Jamie Dimon, JPMorgan Q2 2026 earnings call. His analogy:...