FDE vs software engineer: what leaving the codebase costs
A software engineer builds the product, for every customer at once. A forward deployed engineer builds for one, inside that customer’s systems, and is judged on whether that customer’s work changed rather than on whether the software is elegant. The move between the two is the most consequential one in this comparison set, because it changes what you are rewarded for at a fundamental level. Product engineering rewards generality: the right answer is the one that serves the next thousand customers as well as this one. Deployment engineering rewards specificity, and will frequently reward a solution a product team would reject on sight. Neither instinct is wrong. But an engineer who carries the product instinct unchanged into a deployment role will spend six months building the general version of something the customer needed in three weeks.
| Forward deployed engineer | Software engineer | |
|---|---|---|
| In one sentence | An engineer employed by the product company, working inside the customer’s organisation to make the product solve that customer’s actual problem. | An engineer who builds and maintains the product itself, for every customer rather than for one. |
| Judged on | Whether the customer’s workflow changed, and whether it stayed changed after the engineer left. | Whether the software is correct, maintainable and shipped. |
| Works inside | The customer’s systems, data and meetings, often on their premises. | The product codebase and its tests, reviews and deployment pipeline. |
| Usually leads to | Leading a deployment team, or product management with unusual field credibility. | Senior, staff and principal engineering, or engineering management. |
| Time with the customer How much of the week is spent with the people who will use the thing. | High | Low |
| Technical depth How deep the engineering expected of the role goes. | High | High |
| Business depth How well the role is expected to understand the customer’s own trade. | High | Low |
| Hands on code How much of the job is actually writing and integrating software. | High | High |
| Owns the outcome Whether the role is judged on delivery, or on what the delivery changed. | High | Medium |
These levels describe where each role sits on average, not a rule. Job titles are not standardised across companies, so a given posting can sit well away from its column. Read what a posting says the person will build rather than the heading.
What you give up
The losses are real and they are usually underestimated by people considering the move, because they are losses of things engineers stop noticing once they have them.
The first is the review. In a product team, work passes through other engineers who will say that a decision is wrong before it reaches production. That mechanism is largely absent in deployment work. There is often nobody from your company qualified to review the integration you just wrote against a customer’s system, and the customer’s own engineers, if any, have their own priorities. The discipline that review used to supply has to come from somewhere else, and for most people that somewhere is a hard-won habit of writing down why they did something, for a version of themselves who will read it in nine months.
The second is the accumulation. Product engineers build on their own previous work. A feature shipped last year still runs, still has their name on it, and the codebase carries the imprint of decisions they made. Deployment work does not accumulate the same way. A deployment finishes, the account moves to support, and the next one starts somewhere else with different systems. Some engineers find this liberating. Others find, around year three, that they miss having a body of work.
The third is technical depth in a specific stack. Breadth grows fast in deployment work, and depth in any one thing grows slower. An engineer who has spent three years going forward deployed will know a great deal about how a dozen organisations actually operate and slightly less about the internals of the system they left.
What you gain
The gain that matters most is also the one hardest to describe on a resume: you find out what software actually does to an organisation.
Product engineers work from artefacts. Tickets, research summaries, dashboards, occasionally a recorded user session. These are genuine information and they are also filtered, several times, by people who had to decide what mattered. A deployment engineer gets the unfiltered version, which is frequently uncomfortable. The feature everyone was proud of goes unused because it sits one click past where people stop looking. The performance work nobody wanted to do turned out to be the whole objection. Watching that happen changes how an engineer thinks about their trade permanently.
The second gain is access. Deployment engineers routinely sit with people several levels more senior than they would meet inside their own company, because they are the one who understands what is being built and the customer wants to hear it from them. Two years of that produces a working knowledge of how decisions get made in large organisations that most engineers never acquire.
The third is a straightforward market observation: the supply of engineers who are strong technically and comfortable in front of a hostile stakeholder is much smaller than the supply of engineers who are strong technically. Scarcity is a real asset.
How to tell which instinct you actually have
There is a question that sorts people reliably, and it is not about technology. Imagine you have written a script that solves a customer’s problem completely. It is ugly, it hardcodes three things, and it will never be used again after this month. Do you feel finished, or do you feel like you have not done the job yet.
Engineers who feel finished will be happy in deployment work. Engineers who feel the second thing are not worse engineers, and in a product team they are exactly who you want. But they will fight their own instincts every week in a deployment role, and that fight is tiring in a way that reads, after a year, as dislike for the job.
The corollary is worth stating too. An engineer who genuinely cannot stand writing throwaway code should not take the role and should not feel bad about it. The two dispositions are both legitimate, and the industry needs more of the second than it admits.
Making the move without burning the bridge
If you are moving from product engineering into a deployment role and want to keep the return path open, three things help, and none of them is difficult.
Keep shipping something into a shared codebase, however small. An internal tool, a library the deployment team reuses, a contribution back to the product. It keeps the habits alive and it keeps the resume legible to a product hiring manager.
Write the deployments down. Not a status report: an account of what the customer’s real problem turned out to be, what you built, and what you would do differently. This is the artefact that converts three years of deployment work into a case for a product role, and nobody can reconstruct it afterwards from memory.
Finally, be deliberate about the second year. The first year in the role is absorbing and it is easy to let it become five without deciding. The engineers who get the most out of the role are the ones who decided, at some point, that they were choosing it rather than drifting.
