Forward Deployed Engineering

A few weeks ago, this chart from the FT made the rounds:

What Forward-Deployed Engineers Do

If you live around Silicon Valley or the software world, you’re starting to hear the term forward-deployed engineer (FDE) more and more. While the term has its roots in the military, it was popularized by Palantir over the last 20 years. To my mind, the primary distinction between a forward-deployed engineer and a more traditional software engineer is their relationship with customers. The latter is much more typically back-office, often purposely hidden away because of worry that they’re too technical or awkward for client interactions. Meanwhile, forward-deployed engineers are meant to sit within organizations, actually putting the software to work.

Nic Prettejohn, head of AI in the UK at Palantir, put it well in that FT piece: “[Forward-deployed engineers] know that the only valuable software is not how exquisite its code is or how beautiful the language . . . It’s only valuable if it means something for the end customer.”

How Alephic Applies the Model

At Alephic, we think about this a lot and have modeled some of our thinking on how Palantir operates. Like them, we have a core software engineering team that works on our platform: a set of tools and services that everyone can use to supercharge their work. This isn't SaaS—it's a set of techniques, components, scripts, and reference architectures we make available to our clients as part of our builds. We also have a team of forward-deployed engineers who work directly with customers to solve their problems.

One of the magical things about AI is that it can help to shrink the distance between these “builders” (our FDEs) and people who need things built. Gone are the days when you have four layers of "suits" sitting between engineers and customers. Those layers were sold as quality control and strategic oversight, but more often, they actually degraded quality while adding cost and delay. Each layer introduced translation errors, approval delays, political friction, context loss, and accountability diffusion. The builder never got to see the actual problem firsthand, and the customer never met the person building the solution. 

By the time requirements traveled through four rounds of telephone, what got built bore little resemblance to what was needed. Nowhere is this better understood than the wasteland of enterprise software aimed at end-user employees but built for the work their managers imagine they do. I’d be lying if I said I never fell into this trap in my time at Percolate, building marketing SaaS for some of the biggest brands in the world. It’s natural to orient functionality towards the people who pay you, at the expense of the people who are expected to use the tool day in and day out.