Hiring a forward deployed engineer or buying it as a service

The question is not whether you need the profile, but in what form

You have understood what the forward deployed model is for: an engineer working in your offices, on your data, next to the people doing the work, shipping things people can use instead of recommendations. The next question comes fast. Do you hire that profile, or do you buy it as a service?

Both answers hold up. What separates them is neither the quality of the people nor the ambition of the project. It is the state of your organisation on the day you decide. This article gives you the criteria, and what to secure either way.

What the profile can do, and why it is rare

The role combines five things that are each, on their own, straightforward to hire for.

• Software engineering. Writing code that runs in production, gets tested, gets deployed, and can be picked up six months later by someone else. Not a demo notebook.
• Data. Going to find the information where it lives, in an ERP, a CRM, a mailbox, a folder of files, and accepting that it is dirty. Cleaning, reconciling, documenting what is missing.
• Applied AI. Knowing what a model can and cannot do, setting the guardrails, checking outputs, deciding what must stay computed by code rather than produced by a model.
• Listening to the business. Spending half a day inside a department, watching the real gestures, spotting the step nobody mentions because it seems obvious, and restating the need differently from how the sponsor stated it.
• Deciding on the ground. Arbitrating alone, in front of the user, without sending the question up to a committee. Saying no to a request that would derail the project. Saying yes on Tuesday to a change of direction after listening on Monday.

The rarity does not come from any single brick, it comes from the combination. Very technical profiles often prefer depth to fieldwork: they want a specification, not a meeting in a workshop. Profiles who are comfortable with the business rarely write production code. And the fifth point, decision autonomy, is acquired through exposure, not training. That does not show on a diploma.

Add a temperament constraint. The role means arriving in a department you do not know and producing something useful there before patience runs out. Many excellent engineers hate that situation, and that is what shrinks the pool.

Three conditions for a hire that holds

A successful hire on this role rests on three supports. If one is missing, the person leaves, or goes quiet, which amounts to the same thing more slowly.

1. A continuous flow of subjects

This profile lives on variety and pace. It needs one subject underway, one arriving, and one under observation. A company with a single identified project is hiring for a project, not for a role. Once it ships, the person ends up doing maintenance, which is not what they came for.

The test is simple. List on one page the subjects you would hand this person over the coming months. Not ideas, subjects: a department asking, a named user, a situation that costs time today. If the list fits in two lines, hiring is premature. If it overflows and you have to prioritise, the flow exists. A subject only becomes real the day someone from the business agrees to spend time on it.

2. Someone able to supervise the work technically

Supervising does not mean managing. The role needs a peer who can review an architecture decision, challenge a storage choice, notice an API key sitting in a file, and say «you are going too fast here». That peer can be an internal technical lead, an architect, a lead developer. It can also be held from outside, provided it is organised and not improvised.

Without that peer, speed becomes the problem. The person ships fast, ships a lot, and nobody sees the debt building. Production readiness, handover and security fall through the cracks, and you notice on the day a tool becomes critical. That is the subject of what separates a business POC from a production tool.

3. A company ready to let them work outside central IT

The model assumes the engineer settles into the department, takes their accesses, talks directly to users and ships without going through the full corporate project cycle. If your organisation requires a ticket for every access, a committee for every release and several weeks of queue before anything goes live, you will hire a fast profile and place them in a slow system. They will do a project manager's job and leave.

This does not mean working against the IT department. It means negotiating a frame in advance: which environments are open, which data is reachable, what level of tool can be put in a department's hands without heavy review, and above which threshold the project moves into the standard circuit. That frame is set before the hire, with IT in the room. Hosting and compliance get settled at that moment: see hosting an AI project in France.

Signs you should start with a service

Four situations make hiring risky and a service more reasonable.

• The first subject still needs framing. You know there is a problem, you are not sure of its shape or who should own it. Hiring into that fog means asking the person to define their own role during their trial period.
• There is no AI practice in house. Nobody at your company has put a model into production, nobody can review a decision on that ground. The new arrival would have no reference points, and neither would you to assess them.
• You need results before opening a headcount. Creating a role often takes long arbitrations. One deliverable that runs and that users ask for makes that discussion far shorter.
• Your subjects arrive in waves. Three projects in the first half, nothing in the second, then two in autumn. A service absorbs that irregularity. A permanent role endures it.

It is the same logic as choosing between custom software and off the shelf: you commit to a structure when the need is stable and known, and you keep flexibility while it is not.

The risk of the isolated hire

This is the most frequent and the most expensive scenario. A company hires a solid profile, the only one of its kind in the house. They ship. Users are happy. Requests pile up. And nobody ever reviews what they produce.

After a few months, several tools are running, all designed by the same person, with their conventions and their shortcuts. The documentation lives in their head. The accesses are in their name. When a user reports a problem, they are the only one who can answer. And you have no way of knowing whether what runs is well built, because nobody else can read it.

This is not about trust. A lone engineer, however good, makes decisions that are never contradicted. They stall, they isolate, eventually they leave because they stopped learning, and you inherit a set of orphaned tools.

The remedy is known. Never alone. Either you hire alongside an internal peer who reviews, or you attach the person to an external team playing that part, or you impose a regular cross review with a third party. And from day one you require every shipped tool to have a named second reader.

The mixed model, often the healthiest

In most mid sized organisations, the right answer unfolds over time.

First phase: a service. You take a forward deployed engineer as a service to handle two or three real subjects. The goal is not only to ship them. It is to measure something else: do the requesting departments follow through, do users adopt, do other subjects come up on their own. You are testing your flow under real conditions.

Second phase: the decision. If the flow is proven, hiring defends itself, with usage evidence in hand. If the flow does not confirm, you have not created a role you would have to justify for years.

Third phase: the handover. The critical part, and the one people forget. It is not organised when the hire arrives, but on day one of the service. The provider works from the start as if they had to leave: readable code, repository on your side, documented environments, written decisions, and a named internal contact who follows the work even without coding.

That third phase also raises the general level of the house. An engineer in service who explains what they do to business teams leaves more than tools behind: see bringing your teams up to speed on AI.

What to require from a provider so you are not trapped

A badly framed service creates exactly the dependency you were trying to avoid by hiring. Five requirements are enough, and they are set before you start.

• Code ownership. Code produced for you is yours, unconditionally and with no licence to renew. The repository is on your side, or under an account in your name where you hold admin access. Check that you can clone the project yourself, not that it is promised.
• Hosting in your name. Servers, domain names, databases and service accounts are opened in the company's name, paid by the company, with your recovery details. Hosting in the provider's name is a choke point the day the relationship ends.
• Documentation. Not a manual nobody reads. One short document per tool: what it is for, who uses it, how to restart it, where the data sits, which decisions were made and why. Require it at the first delivery, not at the end.
• Training an internal contact. Someone at your company must be able to explain each tool, know where to look when it stalls, and hold the relationship with users. Not necessarily a developer.
• Reversibility. Write the exit into the contract: what is handed back, in what format, within what timeframe, with a transfer session planned. Better: test it once, cold, on a tool already delivered. Reversibility never tested is a clause, not a guarantee.

A serious provider accepts those five points without argument, because they already work that way. Hesitation on any one of them tells you more than any reference.

Recognising the profile in an interview

If you hire, the classic interview will not help much. The skills that matter here surface through accounts of real experience.

Questions that make people talk

• «Tell me about a time you shipped something the user did not use. What had you misunderstood?» A good answer is precise and owns it. A bad one blames the user.
• «On your last project, which data was dirty, and what did you do about it?» This separates people who worked on production data from people who worked on test sets.
• «What did you refuse to do, and how did you tell the sponsor?» You are looking for the ability to arbitrate alone, without hiding behind a hierarchy.
• «Show me something still running today without you.» The most useful question on the list.
• «How do you know a model output is wrong?» Look for concrete verification methods, not a general opinion about the limits of AI. The subject is developed in the AI engineer role.

Warning signs

• They talk a lot about tools and never about users. Count technology names against job names in their answers.
• They have never put anything into production, or cannot say what became of what they shipped.
• They want a complete specification before starting. On this role, the specification is an output, not a starting point.
• They ask nothing about your organisation during the interview.
• They present AI as the answer before hearing the question.

One last point: bring a business person into the process, not only technical staff. Have the candidate explain how they would approach a real department at your company, in front of the person running it.

How to decide

Go back to the three conditions. A flow of subjects you can list. A peer able to review. An organisation that accepts a way of working alongside the standard circuit. If all three hold, hire, with the second reader planned from the start. If one is missing, start with a service and use that period to build what is missing.

Either way, the same requirements protect your company: code ownership, hosting in your name, living documentation, an internal contact, a tested exit. They cost nothing to set at the beginning and change everything at the end.

For the full picture of the model, go back to the pillar page: what a forward deployed engineer is. And if you want to lay your subjects flat before choosing between a role and a service, that is what the AI diagnostic does: we look at your use cases, your organisation and your data, and we tell you what stands up.

Frequently asked questions

Can we give this role to a developer already working here?

It is possible if the person actually wants fieldwork and accepts working inside departments rather than in front of a backlog. Two things usually block it: availability, because they stay attached to their existing projects, and authority, because colleagues keep pulling them back to the old scope. If you attempt the move, detach the person completely and announce it clearly internally.

Can a provider really work in our offices, among the teams?

Yes, and it is the condition of the model. The engineer takes a desk in the department concerned, joins team meetings and has lunch with users. What the company needs to prepare is the accesses and a contact who introduces them to the right people in the first week.

How do we keep the service from becoming a permanent dependency?

By setting the exit at the start and testing it once, cold. Repository on your side, hosting in your name, one short document per tool and an internal contact following the work are enough to stay in control. If you have never tried to pick up a tool without the provider, you do not know whether you can.

Does the internal contact need to code?

No. They need to understand what each tool is for, who uses it, where the data sits and who to call when it stalls. An attentive business manager often makes a better contact than a developer busy elsewhere. They do need dedicated time and the accesses, otherwise the role stays theoretical.

What if we hire and the person leaves after a year?

That is a scenario to plan for on day one, not to fear. If every tool had a second reader, short documentation and a repository on your side, the departure is manageable. If everything went through one head, the departure costs you the whole body of work. The difference is made by the habits set at the start.