The forward-deployed and solutions engineer

Engineering, in the customer’s building

Some companies sell software that does not work on arrival. Not because it is broken, but because it must be connected to a customer’s data, configured to their process and argued about with their staff before it produces anything. The person who does that is called a forward-deployed engineer, a solutions engineer, an implementation engineer, or a field engineer, depending on the company.

This is one of the most open doors in the field for somebody without a conventional background, and one of the least discussed, because it does not sound like an AI job. It is an AI job. You are the person who makes the model produce value inside a specific organisation, which is the part nobody else has solved.

The week

You are at a logistics company. Their data lives in three systems and one of them is a mainframe report emailed as a fixed-width text file at 06:00. You write the parser. You discover the depot codes in system A do not match those in system B, and nobody at the company knew, because the humans mentally translated them. You build the mapping. You sit with a dispatcher for two hours and learn that the model’s recommendation is ignored every Friday, for a reason that is completely correct and appears nowhere in the specification. You go back to the product team with that.

Half the job is engineering. Half is anthropology.

What makes it different from consulting

A consultancy sells your hours. A forward-deployed engineer works for the product company and the hours are a cost, not the revenue. The consequence is important: your incentive is to make the thing work with less bespoke code each time, and to push what you learned back into the product so the next customer needs less of you.

That feedback loop is the career value. You see, at close range, why software fails in real organisations, and that is the knowledge product managers and platform teams pay for. A great many product managers and senior engineers in enterprise software arrived through this seat.

The skills

• Enough engineering to be dangerous alone. Python, SQL, APIs, some data plumbing, enough to build without waiting for anybody.
• Reading somebody else’s systems fast. Legacy databases, undocumented exports, an API written in 2011.
• Communication under pressure, in a room where you are outnumbered and something is not working.
• Written follow-up. After every session: what we agreed, what is blocked, who owes what by when. This single habit makes people trust you disproportionately.
• Restraint. Not every request should be built. Learning to say “we can do that, and here is what it costs and what it delays” is the senior version of the job.

Two routes in

From support or implementation. If you are already the person customers ask for by name, you have the hard half. Add the engineering.

From engineering. If you can build and you do not mind rooms, this pays better than an equivalent internal role at many companies and moves your career faster, because you are exposed to decision-makers early.

The evidence that works in the interview is not a portfolio project. It is a story, told precisely: a system somebody else built, a customer or user with a problem, what you found when you looked, what you changed, and what happened afterwards. Two of those, told in four minutes each, are worth more here than a repository.

The failure that ends the first year

Becoming a bespoke development team. Each customer asks for something reasonable, you build it, and eighteen months later there are eleven forks of the product and nobody can upgrade anybody. The discipline is to keep asking which of these requests is the same request wearing different clothes, and to push the general version into the product.

The limitation

Travel, and the emotional load of being the face of a product when it disappoints somebody. There are weeks where you are apologising for a decision you did not make. Companies vary enormously in how much they protect field staff from this, and it is worth asking directly: who talks to the customer when a deadline slips, and does the product team ever attend?

There is also a real risk of skill drift. Two years of parsing other people’s exports is not two years of building product, and if you want to move into core engineering later, keep one deep technical thing going deliberately rather than assuming the job will supply it.