The Hard Part Is No Longer Buying the Software, It Is Getting Anyone to Use It

Enterprise technology investment has followed the same playbook for a long time. Buy the most advanced platform available, hire back-office developers to build custom models or integrations, and wait for value to appear.

David Rai, chief executive and founder of Sparta Global, argues that the playbook is now solving the wrong problem. Buying or building sophisticated software is no longer the main obstacle. Getting it operationalised, and actually used to do work, is where the return on investment is routinely lost.

Where the role came from

The response, developed in the United States over the past two years, is the forward deployed engineer.

Palantir pioneered the position. It is now heavily recruited across OpenAI, Anthropic, Databricks and the technology teams of large corporates. Rai's argument is that British companies should expect the same shift, since UK technology strategy has consistently followed American enterprise workforce trends.

Why conventional teams fail at this

The diagnosis is about organisational distance rather than skill.

Standard engineering teams tend to work in isolation, building from rigid specification documents drafted by middle managers. By the time a feature or a model reaches the people meant to use it, business priorities have moved, the realities of the workflow were never captured, and adoption stalls.

Nobody in that chain did anything wrong. The specification was accurate when it was written, the engineering matched it, and the result is still unused.

Part software developer, part operational consultant, part frontline investigator

What the engineer actually does

A forward deployed engineer inverts the arrangement by sitting directly inside the client's operational workflow. Rai describes the role as part software developer, part operational consultant and part frontline investigator, working across three areas.

Finding the real problem. Observing how operational teams work in practice, which surfaces the subtle points of friction a static specification will always miss. The friction is rarely where the document says it is.

Prototyping in place. Building, testing and adapting code inside the live environment rather than in a development sandbox, so feedback is immediate and iteration happens against reality.

Driving adoption. Being present while people start using the thing, which is the stage at which most enterprise software quietly dies.

The third of those is the least glamorous and probably the most valuable. Adoption failure rarely looks like rejection. It looks like a team using the new system for the two tasks it makes easier and continuing to run the spreadsheet for everything else, indefinitely, while the dashboard reports a healthy login count. Somebody has to be in the room to notice that, and it is not a thing a quarterly review will surface.

Why it is expensive and worth it

The obvious objection is cost. A senior engineer embedded with one customer is not a scalable use of an engineering budget, and the economics look considerably worse than a central team shipping to everybody.

The comparison only holds if the central team's output gets used. Where adoption stalls, the entire investment produces nothing, and the cheaper model turns out to have been the more expensive one by a wide margin.

It also changes what the engineering organisation learns. A team working from specifications accumulates knowledge about its own product. A team embedded in customer operations accumulates knowledge about the industry it sells into, which is considerably harder for a competitor to replicate and tends to improve the product without anyone filing a request.

There is a second argument that matters more as AI enters enterprise workflows. A model's value depends almost entirely on whether it has been pointed at the right problem, in the right part of a process, with the right data. That is not knowable from a specification. It is knowable by watching people work.

Which is presumably why the companies with the most capable models are recruiting hardest for the people who sit with customers rather than the people who train them. The model is no longer the scarce thing.