FDE vs implementation consultant: nearly the same job
These two are the closest pair on this site. Both arrive after a decision has been taken, both work inside a customer's systems and approval queues, both are measured on whether something is live and used, and both spend more of the calendar on access than on building. Watch either for a week and you could not tell them apart. One fact separates them: the implementation consultant is paid by the customer, the forward deployed engineer by the company whose product is being deployed. That difference is invisible most days and decides the outcome in three specific moments. What happens to scope when something unexpected appears. Whether the handover is a deliverable or the first thing cut when the project runs late. And whether what the engagement learned reaches anybody who can change the product.
| Forward deployed engineer | AI implementation consultant | |
|---|---|---|
| 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. | Someone paid by the customer to make a decision that has already been taken exist inside their organisation. |
| Judged on | Whether the customer’s workflow changed, and whether it stayed changed after the engineer left. | Whether the system is live and in use when the engagement ends. |
| Works inside | The customer’s systems, data and meetings, often on their premises. | The customer’s systems and approval queues, on a statement of work. |
| Usually leads to | Leading a deployment team, or product management with unusual field credibility. | Delivery leadership, or the same work from inside a product company. |
| Time with the customer How much of the week is spent with the people who will use the thing. | High | High |
| Technical depth How deep the engineering expected of the role goes. | High | Medium |
| Business depth How well the role is expected to understand the customer’s own trade. | High | High |
| Hands on code How much of the job is actually writing and integrating software. | High | Medium |
| Owns the outcome Whether the role is judged on delivery, or on what the delivery changed. | High | High |
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.
Moment one: something unexpected appears
A fifth of the documents turn out to be scans. Nobody scoped extraction.
The consultant's correct professional response is to raise a change request, because a fixed-price engagement that absorbs unscoped work stops being viable and the discipline exists for good reasons. The process takes time and the project waits.
The vendor's engineer has a different calculation. Their employer is paid by adoption rather than by hours, so absorbing two weeks to keep the deployment moving can be the rational choice. This is not generosity; it is a different economic position, and it is why vendor-side deployments often move faster through surprises.
Moment two: the project runs late and the handover is due
Handover is unbillable, uninteresting and invisible in a status report, which makes it the first casualty of a compressed timeline in any engagement model.
On the consulting side there is rarely a counterweight: the acceptance criteria are met, the invoice goes out, and whether the customer can maintain the system is next year's problem for somebody else.
On the vendor side there is one, and it is self-interested rather than noble. A customer who cannot operate the system will not renew, so the handover protects the revenue. Customers should ask about this explicitly in either model, because it is the single best predictor of whether the system still works in eighteen months.
Moment three: the findings
Every deployment reveals things about the product: the onboarding that assumes access nobody has, the feature that breaks on real documents, the workflow that assumes a role the customer does not have.
The vendor's engineer can take those to people who can fix them, and often fixes part themselves. Over a year this is the main reason the role exists as an employee rather than being outsourced.
The consultant can write them in a report to a vendor with no obligation to read it. The same observation, the same quality, and no channel. Consultants who care about this build the channel informally, and it depends entirely on relationships rather than on structure.
Where the consultant is the better choice
Independence, on any project spanning several vendors or where the selection is not settled. A vendor's employee cannot credibly arbitrate between their product and another, and pretending otherwise damages trust more than admitting it.
Also where the customer wants the capability rather than the system. A consultant engaged to build alongside an internal team, explicitly to transfer knowledge, has no conflicting interest in that goal. A vendor does, quietly, since a self-sufficient customer needs less from them.
The arrangement that borrows from both, which is what we offer, is described on our service page: the deployment role engaged for one project, with the handover written into the scope rather than left to incentives. It does not resolve the independence problem, and we say so there rather than claiming to be neutral about a decision we have an interest in.
