FDE vs AI consultant: who signs the paycheque
Put a forward deployed engineer and an AI consultant on the same account, with the same problem and the same stakeholders, and they will often propose similar work. What differs is who pays them, and that is not an administrative detail. A consultancy is paid for an engagement, so its structural interest is a next engagement. A product company pays a deployment engineer so that a customer adopts the product and keeps paying for it, which means the engineer succeeds by making themselves unnecessary in the building. An FDE who has worked themselves out of a job has done exactly what their employer wanted. A consultant who has done the same has lost an account. Neither incentive is dishonourable and both can be served with integrity, and only one of them pays for leaving.
| Forward deployed engineer | AI 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. | An adviser on where AI is worth applying and in what order, usually stopping before anything is built. |
| Judged on | Whether the customer’s workflow changed, and whether it stayed changed after the engineer left. | Whether the recommendation was accepted, which is rarely the same as whether it worked. |
| Works inside | The customer’s systems, data and meetings, often on their premises. | Workshops, assessments, business cases and steering meetings. |
| Usually leads to | Leading a deployment team, or product management with unusual field credibility. | Practice leadership, or a move into delivery where the advice has to hold up. |
| 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 | Low |
| 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 | Low |
| Owns the outcome Whether the role is judged on delivery, or on what the delivery changed. | High | Low |
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 the consultant can do that the engineer cannot
Recommend anything, including a competitor's product or no product at all. That independence is real and it is the strongest argument for buying advice separately from delivery.
A deployment engineer employed by a vendor cannot credibly recommend a different vendor, and everyone in the room knows it. On questions of selection, their input is discounted and should be, however honest they are being.
The caveat is that independence is often claimed and less often structural. A consultancy with partner agreements on one side of a decision has an interest too, and it is less visible than the vendor's because it is not in the job title. Asking about it directly is a reasonable thing to do and is rarely done.
What the engineer can do that the consultant cannot
Change the product. This is the underrated half of the comparison and the reason the role exists as an employee rather than a contractor.
When a deployment reveals that the product's onboarding assumes data access nobody has, or that a feature breaks on real documents, the deployment engineer can take that back to people who can fix it and frequently fix part of it themselves. A consultant can write it in a report to a vendor who has no reason to read it.
Over a year that difference compounds. The organisations that get the most from these engagements are the ones where the engineer's findings reached the product, which is a channel a consultancy structurally does not have.
The failure each one is prone to
The consultant's is a recommendation that is correct and unexecutable. A plan assuming access the organisation cannot grant, or a target operating model no team has authority to reach. Defensible on paper, and it produces nothing.
The engineer's is the opposite: building something well that should not have been built at all, because questioning the premise is awkward when your employer sold it. An FDE who never tells a customer that the project is not worth doing is not exercising the judgement the role is hired for.
Both failures have the same cure, which is talking to the people who would have to execute before deciding what to propose. It is the cheapest hour in either job and the most commonly skipped.
Moving between them
Deployment first, advisory later, is the sequence that produces the better adviser. Someone who has spent three years making designs work in hostile conditions prices their own recommendations accurately, which most advisers cannot.
The reverse works and takes longer. The habit to unlearn is stopping at the recommendation, and it is deeply trained: consultancies reward scope discipline because that is how a fixed-price engagement survives. In deployment the equivalent instinct is protecting the outcome, which sometimes means absorbing work nobody scoped because the alternative is a project that does not land. Consultants making this move describe the first six months as uncomfortable for exactly that reason, and the ones who get through it are unusually good at the part of deployment that is neither engineering nor advice.
