The term is suddenly everywhere. Palantir coined “Forward Deployed Engineer” years ago, and now OpenAI, Anthropic, and a wave of AI companies are competing hard for the profile. Job boards are full of the title. But most of those posts describe a senior engineer who happens to travel to customers — which misses almost everything that makes the role rare and valuable.
A real Forward Deployed Engineer (FDE) is not a consultant who writes a deck, and not a coder who waits for a spec. They are dropped into a real environment — a customer’s business, a messy internal team, an actual factory floor — and made responsible for the outcome, not the ticket. To do that, they have to hold three very different skills at the same time.
Three muscles that rarely live in one person
- Deep technical ability — they can architect and ship production systems, not just advise on them.
- Executive fluency — they can sit with a CEO or board and explain what needs to happen, and why, in the language of the business — and actually hear what the business cares about.
- Field diagnosis — they can sit with the people doing the work, listen to the problem they describe, and find the real problem hiding underneath it.
Each of these is built in a different season of a career, and they tend to atrophy in each other’s presence. Engineers who go deep often lose the room. People who can command a boardroom usually stopped writing code a decade ago. The person you actually want is a senior leader who managed teams and shipped real systems — and kept both alive. Most people trade one for the other on the way up. The FDE refused to.
The uncomfortable truth
You are not looking for a great engineer or a great communicator. You are looking for someone senior enough to have led people and run delivery, who never stopped being hands-on. That intersection is small — which is exactly why these hires are so hard, and so valuable.
The skill nobody screens for: root cause vs. requested fix
The single trait that separates a real FDE from a strong senior engineer is what they do with a request. A stakeholder almost never hands you a problem. They hand you their best guess at a solution — “we need a dashboard,” “we need to move to microservices,” “we need an AI chatbot.” A great FDE respects that input, then quietly goes and finds the problem underneath it, which is frequently something else entirely.
Bad: the order-taker
The client asks for a dashboard. Six weeks later there is a beautiful dashboard that nobody opens — because the real problem was that three teams didn’t trust the underlying numbers. The dashboard just made the distrust prettier and more expensive.
Good: the root-causer
The FDE spends two days on the floor and discovers the numbers disagree because two systems define “active customer” differently. They fix the definition and the pipeline, then ship a much smaller dashboard that people actually rely on — because now the numbers can be trusted.
What good looks like — and what fools you
Because the title is hot, plenty of people now claim it. The tells are reliable once you know them. A strong FDE reframes the problem in the first meeting, asks who the user is and what breaks if nothing changes, and can sketch the architecture on a whiteboard and the business case on the very next slide. The impostors fall down on one of the two halves.
The confident impostor
Talks fluently about technology but can’t actually ship it — or ships beautifully but can’t tell you which business metric the work moves. Either half on its own leaves money, and trust, on the table.
Why this matters more in the AI era
AI projects rarely fail because the model is bad. They fail in the gap between what the technology can do and what the business actually needs — the place where a vague ambition (“use AI”) has to become a concrete, measurable system that fits how real people work. That gap is precisely where the FDE lives. As more capability gets commoditised into APIs, the scarce thing is no longer the model. It is the person who can translate a real problem into the right system, and stand behind the result.
The bottleneck in most AI projects isn’t the model. It’s the translation between a real business problem and a system that solves it. That translation is a person.
At JTS, this is the bar we hire and build to: senior people who can hold the boardroom and the codebase at the same time, who go to the floor and find the real problem before writing a line of code. It is genuinely hard to find. That is exactly why it is worth insisting on.