On Some Thoroughly Unfancy FDEs
Forward Deployed Engineer — strip away the glamour of the acronym and what remains is a narrative variant of the oldest role every consulting firm knows: technical labor dispatched to the client’s site. Consulting firms call it “delivery,” software companies call it “deployment,” and underneath it is the same thing: carry the technology, go onto someone else’s territory, and rebuild someone else’s system to someone else’s requirements. The position occupied is the tool of a tool.
Judging by how AI has developed so far, its path of application and commercialization does not differ much from that of any other technology; by the same token, the position an FDE occupies inside a company is strikingly similar to the position of an IBM engineer in the 1970s. IBM sold hardware plus custom consulting, and its engineers were dispatched to chemical plants, pharmaceutical factories and banks, writing bespoke programs for each client, touching the most concrete business reality there is — how every order moves, how every entry gets booked. Constrained by that hardware-plus-consulting business model (structurally so, I think), IBM never saw the profit in pure software. Yet SAP, which went on to do enterprise SaaS extraordinarily well, was founded entirely by people out of IBM — while building an order-processing system for a chemical plant they noticed that the finance workflows of every company are broadly alike and could be packaged as standardized software. IBM turned the proposal down; its reasons I will not speculate about. A similar thing had happened once before: the IBM researcher Edgar Codd published “A Relational Model of Data for Large Shared Data Banks,” proposing the relational database; IBM built it internally and concluded it had no commercial value. Larry Ellison read the same paper and founded Software Development Laboratories, later Oracle — the first commercial relational database to use SQL.
SAP and Oracle are essentially the same story: an engineer finds a general structure inside service work, abstracts it into a product, and leaves. Looking at outcomes, the positions engineers occupy when a new technology arrives come in three kinds: first, parasitic but independent — see a general need, abstract it into a product, go out and build it yourself, which is the road both SAP and Oracle took; second, create a new category — Google, PayPal and the like, which cannot be planned for; third, purely parasitic — service, customization for hire, selling person-days, high-grade outsourcing underneath.
The common understanding is that the vast majority of FDEs will stay in the third position, trading time for money. The pivot is whether, in the course of doing service work, you can find a “general structure” — a shared need that holds across clients and across scenarios — and abstract it into a product. But there is a deeper problem here. Because scenario complexity has climbed so steeply, current AI enters through verticals; suppose you successfully build a law firm an Agent product that lifts efficiency fivefold — does real profit double? Obviously not. Supply and demand constrain it: the same team can now process five times the caseload, but total demand for legal services in a city is relatively fixed in the short run — the arrival of AI does not suddenly produce five times as many people with lawsuits to file. So that firm’s growth can only come from taking clients away from other firms.
For the relatively successful among these FDEs, another fork follows: arbitrage the high PE multiples of the capital markets, earn the industry’s money honestly, or keep chasing a “new category”?
End of rambling. Talk is cheap; what creates real value at any stage is doing one concrete thing.