Not consulting
A consultant produces a recommendation and hands implementation back to the client. The engagement ends at the document. Here the engagement starts there, and the test is simple: who gets paged when the advice turns out to be wrong.
The role
What a forward deployed engineer actually does.
The title is new enough that it gets used for three different jobs. This is what it means, what separates it from consulting, and what to look for if you are hiring one. Written by someone who has been doing it since 2022.
The short answer
A forward deployed engineer writes production code inside the customer's environment: their repositories, their review standards, their on-call rotation.
The deliverable is working software running in the customer's production system. Not a recommendation, not a report, not a prototype handed to someone else to implement. That distinction is the whole role, and everything else follows from it.
Why the role appeared
A software team used to route a single change through a lot of hands. A business analyst wrote requirements. A delivery lead managed the engagement. An architect produced a design. An engineer implemented it. A QA engineer verified it. Each handoff was a translation, and each translation lost something.
Two things collapsed that chain. Tooling made the implementation step dramatically faster, which exposed the handoffs as the actual bottleneck. And enterprises kept discovering that software which worked in a demo did not survive contact with their production environment, their data, or their compliance posture.
What resolves both is one person who can sit in the customer's environment, work out what is actually wrong, and implement the fix without a translation layer. That is the forward deployed engineer. The analysis, delivery and architecture roles fold into it, not because those activities stopped mattering but because splitting them across four people was costing more than it bought.
The same consolidation is happening on the product side, where product management, design and QA are folding into the product engineer. Both roles are the same bet: fewer handoffs, more ownership.
What it is not
The title gets applied to three arrangements it does not describe. The difference is not seniority or price, it is where the code lands and who owns it afterwards.
Not staff augmentation
Staff augmentation supplies capacity against a defined backlog: tickets in, tickets out. A forward deployed engineer is expected to question the backlog, and is most valuable exactly when the tickets describe the wrong problem.
Not an agency build
An agency builds something separate and delivers it over the wall, usually greenfield, usually in their own stack. This is the opposite: someone else's codebase, someone else's conventions, and the constraint of not breaking what already runs.
What the work actually looks like
Less glamorous than the title suggests, and the first weeks are mostly reading.
Earning the right to change things
You are in a codebase built by people who are still there and who made their decisions for reasons you have not learned yet. The first job is understanding why the previous decision was made before proposing a different one. A lot of the value is knowing which parts not to touch.
Working in their process, not yours
Their standups, their design reviews, their pull request standards, their release cadence, their incident procedure. You do not get to import your own way of working. If you eventually change theirs, it is because you earned it, which takes months rather than weeks.
Reworking the brief
The request is frequently not the problem. Being the person who says so, with evidence, before anyone has spent a quarter building the wrong thing, is most of what distinguishes this from taking tickets. It is also the part that requires trust you have not been granted yet.
Carrying it afterwards
Out-of-hours on-call, live incident response, and migrations run against production rather than a staging clone. A recommendation is cheap and reversible. Being the person who has to answer for it at 3am is what makes the recommendation careful in the first place.
What to look for when hiring one
Four signals that separate the role from a senior engineer with a new title. They apply to me as much as to anyone else you are assessing.
- 01
Time inside a codebase they did not write
Greenfield work does not test the skill that matters here. Ask how long they have sustained work in someone else’s system and what they changed about how that team operates.
- 02
Production ownership, not advisory
On-call, incident response, migrations against live systems. If every engagement ended at handover, the hard half of the role is untested.
- 03
A specific example of pushing back
Not a philosophy of pushing back. A named occasion where they told a client the brief was wrong, what evidence they had, and what happened next, including the times it did not go well.
- 04
Willingness to say what they are bad at
An engineer who has no list of workloads they would decline has not thought about constraints. Ask what they would refuse and why.
Applying that to myself
The record behind this page.
Writing a definition of a role is easy. These are the figures behind my claim to it, measured 2026-08-21 from private repositories, so dated and self-reported rather than independently verifiable. The products are the part you can check yourself.
4 years
continuously embedded, since 2022
1,441
commits in the client codebase
50
services contributed to
525
days with commits
The embedded half
A UK enterprise ticketing platform, 80+ venues, billions of events a year, in a multi-tenant codebase built by a team of more than a hundred developers that I did not write. Their review standards, their pager. I ended up setting the pull request review standard for that team. The client is not named here by their preference and mine.
The product half
4 products built solo, where I was also the product manager, the designer and the QA. CostPatrol carries 127 detection rules across 38+ AWS services. Boody went concept to live in three days and holds 583 tests. Nobody handed me a spec, so I wrote 38 of them before the code.
And the limits, by the same standard
This model does not scale by adding people. If you need six engineers in parallel next month, it is the wrong fit and I will say so rather than staff up to win the work.
A commit count measures activity, not judgement. It is here because a four-year duration next to it means something, not because volume is an achievement in itself.
Common questions
What is a forward deployed engineer?
A forward deployed engineer is a software engineer who works inside the customer’s environment rather than from outside it: writing production code in their repositories, under their review standards, on their on-call rotation. The deliverable is working software in the customer’s production system, not a recommendation, a report or a prototype handed over for someone else to implement.
How is a forward deployed engineer different from a consultant?
A consultant produces a recommendation and leaves implementation to the client. A forward deployed engineer implements it in the client’s own codebase and then owns it afterwards, including when it breaks at 3am. The practical test is who gets paged when the advice turns out to be wrong.
What does a forward deployed engineer do day to day?
Reading an unfamiliar codebase before changing it, attending the customer’s standups and design reviews, opening pull requests against their standards, running migrations and upgrades in their production, responding to incidents, and reworking the brief when the requested thing turns out not to be the problem. Much of the value is in diagnosis rather than construction.
What is the difference between a forward deployed engineer and a product engineer?
They are two halves of the same consolidation. A product engineer absorbs product management, design and QA to own a product end to end and decide what gets built. A forward deployed engineer absorbs business analysis, delivery management and architecture to work out what a specific customer actually needs and ship it into their system. One owns the what, the other owns the where.
What should you look for when hiring a forward deployed engineer?
Evidence of sustained work inside a codebase they did not write, not just greenfield projects. Production ownership rather than advisory engagements, meaning on-call and incident response. A track record of pushing back on a brief. And the ability to say which workloads or approaches are a bad fit, since an engineer who says yes to everything has not understood the constraints.