Could Forward Deployed Engineers work in legal?

Forward‑deployed engineers are having another moment. Palantir made the idea famous years ago, and AI‑native companies have revived it. The appeal is obvious. Put an engineer inside the customer environment, see real work up close, and turn those insights into product improvements. Law firms (and professional services in general) are no strangers to embedded resources, and on the surface, the model feels like a tight fit.

But proximity alone does not create value. What makes the FDE model powerful is autonomy. An embedded engineer who can observe how work really happens and then change the product in response is doing something different from traditional customer engagement. Proximity gives context, and autonomy turns context into progress.

Proximity + Intent

Two approaches look similar on the surface, but they lead to very different outcomes.

Customisation

You change the product for one customer. You tweak a workflow, add a tiny module, or build a one‑off integration that solves a local problem.

Risks

• expanding scope
• fragmented code
• slower roadmap
• more support work

Value: helpful in the moment, but it rarely benefits anyone else.

FDE model

You embed an engineer inside the customer’s workflow. They see real behaviour, catch issues earlier than any ticket ever would, and ship changes that make the product stronger.

Value: long‑term momentum. You learn faster, align better, and reduce the gap between how people work and what the product supports.

The differences

• Customisation serves a single customer. FDE work serves the product.
• Customisation creates exceptions. FDE work strengthens the core.
• Customisation waits for tickets. FDEs see problems in real time.
• Customisation is transactional. FDEs shape the roadmap.
• Customisation adds complexity. FDE work reduces uncertainty.
• Customisation pushes you toward services. FDEs move you toward stronger product‑market fit.

Many vendors convince themselves they are running an FDE model when, in practice, they are stuck in customisation mode.

Complexity in legal workflows

Most legal workflows are built on exceptions. Every practice group has its own style. Partners want specific workflows. IT wants integrations tuned to their environment. Operations wants to report their way. Each request makes sense on its own, but together they create an ecosystem where tailored work is rewarded and shared patterns struggle to survive.

The result:

• divergence grows faster than reuse
• autonomy turns into a sequence of quick fixes
• engineers are pressured to solve preferences, not problems

Palantir avoided this by forcing a single rule: anything built in the field must serve the platform. Reuse was the default. Exceptions were resisted. Most legal‑tech vendors do not operate with that kind of discipline, not because they lack vision, but because market incentives pull them in the opposite direction.

So could FDE work in legal?

FDEs only work when the organisation is ready for them. You need a clear boundary around what the product is, a habit of turning customer insights into reusable components, clarity about what will never be customized, and leadership willing to say no when it matters. Without these, embedded engineers accelerate divergence instead of progress.

At the same time, an FDE at a product company gains focus and momentum. A services company sinks deeper into bespoke work. The tension becomes obvious very quickly.

So ask yourself a simple question: How much of your recent engineering effort strengthened the shared product, and how much became work only one customer will ever use?

The answer tells you whether the FDE model will make you stronger or pull you off course.

Until next time.