This document defines the forward deployed engineer role on one page, for a leader who is about to hire or contract one. It covers what the role is in plain terms, why most job postings describe a different job, the seven lines to fill in before you post it, and six things to look for in the interview.
1. What the role is, in plain terms
A forward deployed engineer is a senior engineer who joins your team, takes one problem you name, and is accountable for the result in production. Not an advisor who leaves a document. Not extra hands who wait for tickets. One person who owns an outcome inside your code, next to your developers, and stays until the result you named is in production.
The title was created in the early 2010s at the company that named it. The Pragmatic Engineer (August 12, 2025) quotes that company's own definition: responsibilities that "look similar to those of a startup CTO", small teams, end to end ownership of high stakes projects. The same company draws the line between its two kinds of engineers in one phrase each. A product developer works on "one capability, many customers". A forward deployed engineer works on "one customer, many capabilities".
Three things appear in every job description The Pragmatic Engineer reviewed: strong engineering fundamentals, time spent inside the customer's team (about a quarter of the time onsite at the originating company, up to half at others), and improvements sent back to the product when it gets in the way.
Vinoo Ganesh, who built the program that trained more than 250 engineers into the role at that company from 2015, puts it in one sentence (February 5, 2026): a software engineer who owns customer outcomes. "Not customer relationships, not customer satisfaction scores, but outcomes." A sales engineer helps close the deal. A solutions architect designs how the product fits. The forward deployed engineer is accountable for the customer's outcome.
2. Why the title is everywhere and the engineers are not
The Pragmatic Engineer reported on March 26, 2026, citing The Wall Street Journal, that job postings for the role grew more than tenfold in 2025 compared with 2024, and that mentions in public company earnings calls went from 8 to 50. A recruiting executive quoted in the same report estimates that about 10% of engineers want the job.
Two engineers who took the job explained why. In practice it was sales work with a technical title: install what the product team had already built, connect it at the customer, send nothing back, sit closer to the deal than to the code. One quit after four weeks.
An essay from Andreessen Horowitz (January 27, 2026) explains where the gap comes from. In 2011 the company that created the role took two of the least valued jobs in an engineering organization, solutions engineers and integration engineers, gave them a new title and, with it, real ownership. The title attracted ambitious engineers who would otherwise have avoided customer facing work. The essay offers a test for any new title: does it describe work that would have been unrecognizable five years ago? If only the name changed, the best people can tell.
Many postings fail that test. They describe an integration job with a prestigious name. The engineers you want are reading the first paragraph for one thing: whether they will own a result.
3. The one page role definition
This is the definition we use when a client's engineering team adds a forward deployed engineer. It fits on one page on purpose. If a line cannot be filled in, the role is not defined yet.
| Line | What to write | If it stays blank |
|---|---|---|
| The result they own | One change you can measure in six months. Examples: review wait drops from days to under one; a feature your customers use is in production; agent written changes pass the same checks as human work | You hired extra hands, not a result |
| Where they work | Inside your team: your code, your meetings, your on call rotation | An advisor beside the team who never ships anything |
| What they decide | How your team uses AI tools day to day, what the tools may do on their own, and what gets reviewed by a person | Every decision comes back to you and the practice never forms |
| What they build | Real work from your backlog, next to your developers, using the way of working they are installing | A presentation and a training |
| What they leave behind, and with whom | Written rules, configured tools, and the names of the people on your team who will own each of them | It all leaves with the person |
| How long they stay | Until it runs in production and has survived its first real problem | A system nobody on your team understands |
| How you will know it worked | Numbers your team takes before and after: delivery speed, time waiting for review, rework, how many developers merge agent written code every day | An argument about whether it worked |
4. Six things to look for in the interview
Ganesh lists six traits that separated the engineers who became excellent in the field from the ones who did not last. We use them as the interview, one question each.
Curiosity about your business. He describes noticing an analyst who spent 45 minutes every morning combining data from three systems by hand, for two years, without asking whether it could be automated. Ask: tell me about a problem you fixed that nobody had asked you to fix.
Knowing how much to build. His own mistakes in both directions: two weeks building an elaborate tool when one database query would have done, and a "temporary" script that ran in production for eighteen months. Ask: tell me about a time you built too much, and a time you built too little.
Explaining the same thing to different people. A three month migration explained to a CTO as a risk to board reporting, and to an engineering lead as 847 columns across 12 tables with undocumented dependencies. Ask: explain your last hard technical decision to me as if I ran finance.
Staying calm when things break. A product crashing during a customer's board demo, restored in four minutes over the phone because the cause had been found earlier that week. Ask: walk me through the last production incident you handled, minute by minute.
Getting things done without authority. Getting a product team to prioritize a fix in two days by explaining the renewal at risk and offering a call with the customer, instead of asking nicely. Ask: tell me about something you needed from a team that did not report to you.
Saying no with an alternative. Two days spent understanding why a customer wanted a three month custom feature, and a configuration change that solved it. Ask: tell me about a request you turned down and what you offered instead.
Ganesh's conclusion is that you do not hire this profile, you grow it. Our experience agrees, with one condition: the engineer has to want to own the result before the growing starts. Some very good developers do not. They want a specification. That is a legitimate preference and a different job.
5. What we learned defining the role at our own company
Earlier in 2026 Viaro Networks rebuilt its positions around this role. The title was the easy part. Two things were hard.
The first was the test in section 2, applied to ourselves. Several of our own descriptions read like the job engineers turn down: install, deploy, support. Rewriting them around one owned result per engagement changed who applied and who accepted.
The second was the line about what they leave behind. Inside the client team where this has run longest, a SaaS company we have worked with for ten years, engineers who had been there for years as senior capacity became the people who brought AI tools into the team's daily work: written rules in the code, review and automated testing, and practices shared with the client's own developers. Writing it down, with the names of the people on the client side who would own each piece, is what made it survive when people rotated.
6. How to use this document this week
Fill in the seven lines for the role you are about to post or contract. If the first line reads "help the team adopt AI", it is not a result yet; write the number that will be different in six months. If the line about what they leave behind is blank, you are hiring capacity, not a forward deployed engineer. Then read the posting with the test from section 2 in mind: would an engineer who wants to own a result recognize the job?
Sources
- The Pragmatic Engineer (Gergely Orosz), What are Forward Deployed Engineers, and why are they so in demand?, August 12, 2025. https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers
- The Pragmatic Engineer (Gergely Orosz), Is the FDE role becoming less desirable?, March 26, 2026, citing The Wall Street Journal. https://newsletter.pragmaticengineer.com/p/is-the-fde-role-becoming-less-desirable
- Andreessen Horowitz (Tom Hollands), Forward-deployed Job Titles, January 27, 2026. https://a16z.com/forward-deployed-job-titles/
- Vinoo Ganesh, The Definitive Guide to Forward Deployed Engineering, published by Next Play, February 5, 2026. https://nextplayso.substack.com/p/the-definitive-guide-to-forward-deployed
Analysis and conclusions by Viaro Networks, based on the published reports listed above.