What this document is. A one page role definition for a forward deployed engineer who joins an existing engineering team, plus the test that tells the job the best engineers want apart from the job they turn down. It is built from four published sources: The Pragmatic Engineer's deep dive on the role (August 12, 2025) and its follow up on why engineers decline it (March 26, 2026), an essay on job titles by a partner at Andreessen Horowitz (January 27, 2026), and the guide written by the person who built the program that trained the role at the company that named it (February 5, 2026). Where we say what we saw inside client teams, it is experience and it is marked as such.
1. The role, in the words of the people who defined it
The title was created in the early 2010s at the company that named it. The Pragmatic Engineer's deep dive (August 12, 2025) quotes the 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 piece quotes the distinction the company draws between its two kinds of engineers: a product developer's focus is "one capability, many customers"; a forward deployed engineer's focus is "one customer, many capabilities". Until about 2016 it had more of the second kind than the first.
Three traits recur across every job description The Pragmatic Engineer reviewed: solid software engineering fundamentals, time embedded with the customer (around 25% onsite at the originating company, up to 50% at others), and contributions back to the core product when it gets in the way. The piece also draws the line against consulting: consultants make one off recommendations; a forward deployed engineer works with the customer long term and owns the result.
Vinoo Ganesh, who designed the program that turned software engineers into forward deployed engineers at that company starting in 2015 (more than 250 engineers went through it), puts the definition in one sentence in his guide of 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 the fit, the forward deployed engineer makes sure the customer actually wins.
2. Why demand and supply moved in opposite directions
The Pragmatic Engineer reported on March 26, 2026, citing The Wall Street Journal, that job postings for the role on Indeed grew more than tenfold in 2025 compared with 2024, and that mentions of the role in public company earnings transcripts went from 8 to 50 over the same period. A recruiting executive quoted in the same reporting estimates that about 10% of the engineering market wants the job.
The reason, from two engineers who took it and were disappointed: in practice the role was sales engineering. Deploy what the product team built, integrate it at the customer, contribute nothing back, sit closer to the deal than to the code. One quit after four weeks.
The title essay from Andreessen Horowitz (Tom Hollands, January 27, 2026) explains what happened. In 2011 the company that created the role took two of the lower status roles in any engineering organization, solutions engineers and integration engineers, gave them a new title and, with it, real ownership. The title attracted high agency engineers who would otherwise have avoided client facing work. The essay's test for whether a new title is real or inflated: does it describe work that would have been unrecognizable five years ago? If the responsibilities are the same and only the name changed, the best people can tell.
Most postings today fail that test. They describe an integration job with a prestigious name. The 10% who want the real role are screening for ownership, and they read it in the first paragraph.
3. The one page role definition
This is the definition we use when a client 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 goes here | The failure mode when it is blank |
|---|---|---|
| Outcome owned | One result the engineer is accountable for, stated as a change the team can measure (review queue below one day, agent written changes passing the same gates as human ones, a capability in production) | The engineer becomes extra capacity for whatever is on the board |
| Where they sit | Inside the team: its repository, its standups, its on call, its pull requests | A person beside the team who advises and does not merge |
| What they decide | Which tools are configured to the stack, what the agent may do alone and with supervision, what the review standard is | Every decision escalates and the practice never forms |
| What they build with their own hands | Real tickets from the backlog, next to the team's developers, using the practice they are installing | A slide deck and a training |
| What they transfer, and to whom | The written stance, the context files, the delegation list, the review rubric, and the names of the developers who will own each | The practice leaves with the person |
| How long they stay | Through production and through the first incident caused by generated code | The team inherits a system nobody understands |
| How success is measured | Before and after, taken by the team: cycle time, time to first review, rework rate, share of developers with the agent in their daily flow | An argument about whether it worked |
Adaptation by Viaro Networks Research. The lines are ours; the criteria behind them (ownership of outcomes, embedding, contribution back, long term presence) come from the sources in section 1.
4. Six traits to interview for, and the questions we ask
Ganesh lists six traits that separated the engineers who became exceptional in the field from the ones who washed out. We use them as the interview rubric, one question each.
Curiosity about the customer's world. He describes noticing an analyst who spent 45 minutes every morning combining data from three systems by hand, for two years, without ever asking whether it could be automated. Question: tell me about a problem you fixed that nobody had filed a ticket for.
Calibration. His own failure in both directions: two weeks building a configurable deduplication engine when the customer needed one SQL query, and a "temporary" script that ran in production for eighteen months. Question: tell me about a time you built too much, and a time you built too little.
Communication across audiences. The same 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. Question: explain the last hard technical decision you made to me as if I ran finance.
Calm when things break. A product crashing during a customer's board demo, restored in four minutes over the phone because the root cause had been diagnosed earlier that week. Question: walk me through the last production incident you owned, minute by minute.
Owning outcomes without authority. Getting a product team to prioritize a fix in two days by stating the renewal at risk and offering a call with the customer, not by asking nicely. Question: tell me about something you needed from a team that did not report to you.
Pushing back with an alternative. Two days spent understanding why a customer wanted a three month custom feature, and a configuration change that solved it. Question: 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 the first half and adds a condition to the second: the engineer has to want to own the result before the growing starts. Some very good developers do not. They want the specification. That is a legitimate preference and a different job.
5. What we saw when we redefined the role at our own company
Earlier in 2026 Viaro Networks rebuilt its positions around this role. The title turned out not to be the hard part. Two things were.
The first was the test in section 2, applied to ourselves. Several of our descriptions read like the job engineers turn down: integrate, deploy, support. Rewriting them around one owned outcome per engagement changed who applied and who accepted.
The second was the transfer line of the template. Inside the client team where this has run longest, a SaaS company that has worked with us for ten years, the engineers who had been embedded for years as senior capacity became the people who put the agents into the daily flow: context in the codebases, review and QA skills, automated QA, practices shared with the client's own developers. None of that was in their original job description. Writing it down, with the names of the developers on the client side who would own each piece, is what made it survive rotation.
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 outcome line reads "help the team adopt AI", it is not an outcome yet; write the number that will be different in six months. If the transfer line is blank, you are hiring capacity, not a forward deployed engineer, and you should say so in the posting. Then read the posting against the test in section 2 and ask whether an engineer who wants to own a result would 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
About the sources. The figures and quotations in this document are cited from the sources listed above and restated in our own words beyond the short quotations marked as such; no chart, table or extended passage from those publications is reproduced here. The people and organizations cited did not take part in this document and do not endorse it; their names identify the sources and nothing more. The role definition template and the interview questions are our adaptation.