Skip to content
ISSUE / 18 6 MIN READ · PRACTICE

Forward deployed engineering, and the distance nobody owns

The position came from the inbound, not from a strategy session. What the calls had in common, and what we’ve named it.


Pilot to fleet.

FORWARD DEPLOYED ENGINEERING · MARITIME & TRADE · EST. 2026 — LONDON

We've named the work. Lucid is forward deployed engineering for maritime and B2B software — an operator in the room deciding what gets built, engineers who build it, and something running in production when we leave.

The name is new. The work behind it has been running since the firm started, and none of it is being withdrawn.

This is the piece that says where the name came from, why it points at shipping, and what we bring to it that a consultancy and a vendor’s implementation team do not. It is also, unavoidably, a piece about pedigree. In this industry that is what gets you into the room.


The calls came from one industry

We put the site live in July expecting the inbound to look like the page: founders scaling past their first operating model, portfolio operators, enterprise divisions. Some of it did.

Most of it was shipping.

One conversation led to another, and each one surfaced something the last had not. What looked like a set of unrelated introductions turned out to be one problem with several names on it. That is usually the signal that a market is describing something it has no term for.

We came back to shipping. Twenty years in software, and a set of relationships built inside the industry rather than sold into it. We spent the firm’s first months treating all of that as history. The inbound corrected us.


What the calls had in common

A pilot that worked, and a rollout that didn’t happen. A position that didn’t stand out. A go-to-market that couldn’t cut through the noise.

Three complaints, and most of the calls carried more than one. They are also the same failure at three points on one line: the product is good, and something between the product and the customer isn’t turning that into growth.

ONE FAILURE, THREE POINTS
POSITIONGO-TO-MARKETDEPLOYMENT
The market can't tell you apart
The message doesn't cut through
The customer can't get live, or can't grow

THE PRODUCT IS GOOD AT EVERY POINT ON THIS LINE
FIG / 01THREE COMPLAINTS, ONE LINE

The deployment end of that line is the one nobody owns, so it is where we start.

Maritime software is typically sold on named-user licences rather than by vessel. A pilot proves the product on one desk, with the people who wanted it, in the workflow they already control. A rollout is a different job: it needs workflow change across teams who didn’t buy the thing and don’t yet believe it. Implementation ends at go-live. The superuser left holding the expansion has a day job, no engineering authority, and no mandate to change how the work is done.

So deals start small and stop. The product is fine. The distance has no owner.

Maritime doesn’t have an AI problem. It has a deployment problem wearing an AI budget.

The spend is real and it is climbing. Thetius research commissioned by Lloyd’s Register counted 420 organisations active in maritime AI developments in the last year alone, up from 276 a year earlier.

1

The budget is committed.

What it has not bought is confidence at the point of decision. Thetius again, on the same problem: decision-makers “often must use multiple tools to answer a single commercial question, which might erode confidence in digital tools due to inefficiency.”

2

The distance between buying it and trusting it is the work.

An outside voice puts it better than we do:

“There is a noteworthy difference between simply connecting systems and confirming they actually support decision-making.”

THETIUS · THE GREAT INTEGRATION · 2026

Confirming it is the job we take.


We don’t own the category. We own the maritime version of it.

Forward deployed engineering is not our term and we are not going to pretend otherwise. Palantir’s own job posting claims it: the role “isn’t just a job title: it’s the blueprint. We pioneered this unique position.” EY UK & Ireland launched forward deployed engineering roles on 28 April 2026. Kinaxis made Forward Deployed Engineering a named commercial offering on 3 June 2026.

WHO IS TEACHING THE TERM
PALANTIR — PIONEERED THE ROLE, BY ITS OWN ACCOUNT
28 APR 2026EY UK & IRELAND — FORWARD DEPLOYED ENGINEERING ROLES
03 JUN 2026KINAXIS — A NAMED COMMERCIAL OFFERING
MARITIME — PILOT TO FLEET, UNCLAIMED
FIG / 02THREE FIRMS TEACHING THE TERM AT THEIR OWN EXPENSE

Palantir, EY and Kinaxis are teaching the market what the phrase means at their own expense. A firm our size rides that rather than routing around it. The alternative — inventing a category and spending the next two years explaining it — is a tax you pay in every first meeting.

That distinction is not pedantry. It decides whether a buyer can pay for this. A vendor books forward deployed engineering against implementation and professional services, or against expansion — a pilot-to-fleet stall is an NRR problem, and NRR is a number they already report to a board. An owner or operator books it against the digital or transformation programme, which in this sector is funded and being spent badly. A fund books it three ways: company-paid, split, or fund-backed where the gap is critical and the company won’t move on its own.

A category invented last quarter has no line item waiting for it.


What we own is the distance from pilot to fleet

That is the maritime-specific part, and it is the one term in this vocabulary our research found genuinely unclaimed.

PILOT TO FLEET
PILOTONE DESKNAMED-USER LICENCETHE PEOPLE WHO WANTED IT
OWNED BY NOBODY
ROLLOUTTEAMS THAT DIDN'T BUY ITWORKFLOW CHANGENO ENGINEERING AUTHORITYA SUPERUSER WITH A DAY JOB

IMPLEMENTATION ENDS AT GO-LIVE
FIG / 03IMPLEMENTATION ENDS AT GO-LIVE. THE ROLLOUT DOESN’T START.

It passes the only three tests we care about. A shipping buyer needs no explanation of it. It names a gap rather than a capability, so it implies the work instead of advertising it. And it points directly at a budget — expansion revenue for a vendor, rollout for an owner.


Five years on the other side of this problem

There is a fair question underneath all of this, and it deserves a plain answer. Why us.

Five of those twenty years were Sedna — the Operating System for Global Trade — as CPTO and COO. That is the vendor’s side of the table in exactly the problem described above: implementation, adoption, expansion, and the revenue attached to all three. The diagnosis in this piece is not research we have read. It is work we have owned.

Two things come with that, and both are hard to hire. The relationships are real, and they were built inside the industry rather than sold into it, which is why the inbound arrived at all. And when we say a workflow is wrong it carries, because we have shipped into these workflows and lived with the result.

That is the claim. We have been the company at the other end of this problem, and we would rather not watch it happen again from the outside.


What we can do now that we couldn’t in July

Lucid was founded this year, so there is not much history to revise. There is one change in it worth reporting, and it is the reason this reframe is honest rather than cosmetic.

For most of the firm’s short life the build capacity was one operator, AI-assisted. That is enough to prototype, and enough to prove a point. Handing a customer something running in their estate takes more. Since September there is a small engineering team behind the seat.

What we decide, our engineers build. The same people who run the model, holding the keyboard.

That closes the gap every operating-model engagement eventually hits — the point where the right decision has been made and the company still has to go and find somebody to resource it. A recommendation that arrives with no means of execution is a bill for a quarter of somebody else’s roadmap.


What has not changed

Nothing we do has been withdrawn.

Fractional CPTO and fractional COO are still the seats. Engagement and Venture are still the two modes. The argument in issue 16 stands unchanged: the operating model is the product decision nobody writes down, and writing it down is the work. Forward deployed engineering is the name for what the seat and the engineers add up to, and for where that combination is pointed.

The difference between our version and the standard one is a single sentence, and it is worth being plain about it. In the standard version the customer decides what to build and the engineers deploy it into their environment. In ours, what gets built is decided by somebody who has run a software business in this industry and can say, out loud and in the room, that the workflow is wrong.


The test we would like to be held to

The engagement has to be able to end. That is what makes it worth starting.

We would rather be the vanguard than the garrison — first into the new problem, prove it, build the reusable part, hand it over, leave. The measure is not what is true in month three. It is what is still true ninety days after the last invoice: software running, an owner named, a model somebody else can hold.

We publish work at the point it’s real, not at the point it’s announced. This is the point at which the name became real.

If you have product-market fit and your customers are struggling to get live, or to grow past the desk that bought you, that is the conversation to start.

FOOTNOTES

1.Eleanna Apostolidi, Global Head of Client Enablement, Lloyd’s Register, Understanding the potential for marine AI transformation, LR Horizons, April 2026. The figure is from Thetius research commissioned by Lloyd’s Register.↩

2.Thetius, The Great Integration, 2026.↩

START

Forty-five minutes. Bring the constraint.

Tell us where the model is bending. We'll say what we'd do, and whether we're the right people to do it.

WHAT DO YOU NEED?
LONDON — GMT TAKING ENGAGEMENTS