Forward-deployed engineering is a delivery model, not a technology. Engineers work close to the problem — with your product and operations teams, inside the real environment — rather than at a distance from a written specification.
What it looks like in practice
- Time spent watching the process before proposing what to build
- Direct contact with the people who will use the system, not only their manager
- Scope that can change when the environment reveals something the brief missed
- Accountability that continues through integration and adoption
How it differs from the alternatives
Outsourcing delivers against a specification: the specification is the contract, and correcting it is a change request. Staff augmentation supplies capacity into your existing process, where the problem definition remains yours. Forward-deployed delivery takes responsibility for the definition as well as the build, which is valuable when the problem is not yet fully understood and unnecessary when it is.
When it is the wrong fit
If you have a precise specification, an internal architect and a stable scope, you are paying for discovery you do not need. If your team cannot make time for access, context and decisions, the model cannot work — it depends on proximity, and proximity requires participation.
What the first two weeks actually look like
The model is easy to describe and easy to fake, so it is worth being concrete about the opening. Week one is mostly watching: sitting with the people who run the process, reading the tickets and messages the work generates, and listing every system it touches, including the spreadsheets nobody calls a system. No code is written, and the deliverable at the end of it is a description of the problem that the operations team agrees with.
Week two turns that into a shortlist of things worth building, each with a stated outcome and an estimate. Some of those recommendations will be process changes rather than software. If none of them are, that is usually a sign the first week was spent confirming the brief instead of examining the work.
What it asks of your team
- Access to the people who do the work, not only the person who owns the budget
- A named decision-maker who can settle scope questions within a day or two
- Credentials and environment access scoped and agreed in the first week
- Willingness to hear that part of the problem is organisational rather than technical
These are the conditions the model depends on, and they are the honest reason it sometimes fails. Proximity is not a service we can supply alone — it is a shared arrangement, and when an organisation cannot make time for it, a specification-driven supplier will genuinely serve them better.
How to tell whether it is working
The signal is not velocity. It is whether the scope changed for a reason you can name. In a healthy engagement, something the brief assumed turns out to be wrong within the first month, it gets raised rather than absorbed, and the plan adjusts in front of you. An engagement that delivers exactly what was described in the first meeting, with no revisions, has usually not looked very hard at the problem.
What to ask for
Ask how the problem will be examined before a solution is proposed, who will be available to your team and when, how scope changes are handled, and what handover includes. The answers separate a delivery model from a marketing label.