From Backend or Product Engineer
You can build. The gap is customer context, framing, and delivering inside an environment you don't control.
The sequence
- 01
Learn to read an organization
Your first system is the org chart, not the codebase. This is the largest gap for engineers moving into the role and the one nobody tells you about.
- 02
Practise framing before building
Product engineers receive specs. FDEs are handed guesses at solutions and have to find the problem underneath, often by declining the request as stated.
- 03
Widen the stack deliberately
Many capabilities for one customer means range beats depth. If you're backend-only, the fastest wins are data plumbing and putting a usable interface on your own work.
- 04
Ship into a hostile environment
Build something end to end against a system you don't control, with real auth, real rate limits, and no ability to change the other side. That constraint is the job.
- 05
Get in front of people
Run a working session that ends in a decision. This is where strong engineers most often fail the role, and it only improves with reps.
Why this route is the most common one
Most people arriving at forward deployment come from a product or backend engineering job, and most of them are already technically qualified on day one. The engineering bar is real, but it's rarely the thing that stops them.
What stops them is that the job stops being about the code.
In a product role, someone else absorbs the customer. A product manager translates, a support team filters, a sales engineer handles the room. The specification arrives already processed. Forward deployment removes every one of those layers. You get the raw signal: a director who describes a problem in terms of a solution they have already decided on, a process document that doesn't match what anyone does, and a stakeholder who is polite in the meeting and blocking in private.
What to expect
The uncomfortable adjustment is that your throughput stops being the measure of your value. A week where you wrote no code and instead worked out that the project was aimed at the wrong department can be the highest-value week of the engagement. Engineers who measure themselves in commits find this genuinely disorienting.
The second adjustment is throwaway work. A meaningful share of what you build in the field is scaffolding — it exists to make something visible early, and it dies. Building deliberately disposable things well is a skill, and treating everything as if it must be durable will make you slow in a role where early visible progress keeps a sceptical customer engaged.
The honest assessment
If you've shipped production systems and can hold a conversation with a non-engineer without retreating into jargon, you're probably closer to FDE II than you think.
The framework is a mirror, not a bouncer. Take the assessment and find out.