There's a surge of communication right now around the Forward Deployed Engineer. Every week another thread, another job posting, another hot take about the FDE as the role of the decade. And underneath most of it is the same excitement: someone stood up a proof of concept in front of a customer, and the room lit up.
I understand the excitement. I just think it's aimed at the wrong thing.
A proof of concept is the easy 20%. The demo works because the demo was built to work: clean inputs, a friendly audience, and nobody asking who's on call when it breaks. What makes the forward deployed model genuinely interesting isn't the POC. It's what becomes possible when the full stack of skills (strategy, implementation, operations, and hands-on engineering) compound in one person who's actually deployed inside the customer's environment. That compound is rare. The title, right now, is not.
This post is an attempt to answer four questions plainly: what is a forward deployed engineer, why does agentic engineering work, what experience does the job actually demand, and if you invest in the right person, what should you expect to see?
Where the Gold Rush Came From
The FDE wave didn't appear out of nowhere. It stems from a gap tech has been quietly living with for a decade: customer success was asked to augment implementation and services, because real services organizations were something software companies didn't want on the books.
The logic was reasonable at the time. Services dollars didn't scale. They dragged down gross margin, muddied the multiple, and made a software company look like a consultancy to investors who were paying for ARR. So implementation got thinned out, handed to CS teams with playbooks, or pushed to partners. "We're a product company" was a compliment precisely because it meant we don't do services.
Flash forward to 2026, and the incentive has inverted. Now everyone wants the services motion, not for the services revenue, but for what riding shotgun on deployment buys: the rights to first deployment. To be the ones trusted with the software that gets built. Because whoever lands that first deployment decides what's underneath it.
And that's the real prize. Embed a frontier lab's model behind the technology at deployment time (Anthropic, OpenAI, whoever) and it disappears from the conversation. Nobody in the customer's building asks which API key is running behind the services. Nobody re-opens the model bake-off. Switching costs now live inside a production system the customer depends on, wrapped in workflows the FDE built.
Services went from margin poison to the distribution channel for the most valuable technology on earth. That's why the title is suddenly everywhere.
The Experience Question, Honestly
Here's the part I'll say carefully, because I don't mean it to be exclusive: I don't believe someone can be a successful forward deployed engineer without a diversified base of experience supporting companies of different sizes, up to and including the enterprise.
The reason is that the two common paths into this work each produce half the skill set, and each half looks complete from the inside.
The consultancy path produces breadth on a compressed clock. Someone who came up through consulting can have fewer years under their belt and still have real exposure to strategy, management, and a dozen different environments in the time a product engineer sees one. That breadth teaches the most valuable diagnostic skill in deployment work: knowing what's standard across every environment and what's genuinely unique to this one, which is exactly the skill that keeps you out of rabbit holes. But that same person, with limited hands-on development work, has usually never supported what they designed in production. They haven't been paged. Strategy without production scars produces beautiful decks and fragile deployments.
The growth-stage path produces the opposite. An engineer who came up inside startups at the growth stage has genuine hands-on deployment experience: they've shipped, broken, and carried systems that real customers depended on. What they usually haven't had is the formal side: the strategy and management reps a consultant collects, the exposure to how procurement, security review, and risk actually move inside a large organization. So every enterprise quirk looks unique, everything becomes a custom build, and every rabbit hole looks like the critical path.
What I've found actually covers the job is the union of both, and a few things neither path teaches on its own: understanding technical product implementation end to end; being able to read engineering risk operationally, the way an enterprise reads it; knowing how enterprises need to move and mitigate risk; and having lived the differences between growth-stage, pre-IPO, and public companies, ideally including a successful exit, because an exit teaches you what "done" means at the level of a whole company.
I'll be honest and, I hope, modest about the next part: I've had those experiences. Fourteen years of professional career, spent roughly two to three years at a time across each of those seats. I'm not claiming that's the only path. I'm claiming the compound is the qualification, and that when you have it, something changes: you can compress timelines because you're doing the delivery and the consulting management as the same person. There's no handoff between the person who scoped it, the person who built it, and the person who reports on it. They're one head.
