The Forward Deployed Engineer, Chapter 14: Where Does the FDE Function Belong?

This is Part 14 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we walked the failure-mode catalog. This one opens Part V — organizational design and economics — by returning to the placement question Chapter 3 introduced, now with full operational detail.

Chapter 3 introduced the placement question and named three reasonable answers. The real picture is more complicated. In my advisory practice I’ve seen five distinct placements that companies actually use, plus a sixth model — the federated one — that is, in my experience, where the most mature FDE functions eventually settle. The placement decision is the single most consequential organizational design choice a founder makes about the function, and it is the one most often made by analogy rather than by analysis. Worth slowing down for.

The five placements look like this. The function can sit under Engineering, reporting through the CTO or VP of Engineering, which preserves the technical bar but tends to under-invest in the customer-facing soft stack. It can sit under GTM, reporting through the CRO or CCO, which keeps the function close to the customer but produces a chronic tension with the platform engineering team it’s supposed to feed. It can be standalone, reporting to the CEO or COO as its own deployment function, which gives the function clean lines of accountability and creates a permanent question about whether it’s really a department or just a sponsor-of-convenience. It can sit under Product, which is the rarest placement but increasingly viable for agentic products where the deployment work and the product work are genuinely inseparable. And it can be federated, with no single home and instead a network of embedded pods inside each line of business.

The federated model deserves its own paragraph because it is the model most likely to survive scale, in my experience, and it is also the model most likely to fracture quietly when its operational discipline lapses. What holds a federated function together is shared standards across pods (the same DARE rhythm, the same OLA structure, the same eval discipline), shared career ladder so engineers can move between pods without losing momentum, and regular rotation of senior FDEs across pods to keep institutional knowledge from siloing. Without those three, the federated function silently becomes a confederation of independent customer teams whose work doesn’t generalize, which is functionally the snowflake-per-customer trap with extra steps.

What Drives the Choice, and How to Move

The right choice among the five depends on five factors that the chapter walks in turn: company stage (early-stage companies almost always start the function standalone or under engineering, even if they’ll move it later); customer concentration (a function that serves three customers has different needs than one that serves three hundred); the technical risk of the platform itself (high-technical-risk platforms benefit from FDE-engineering proximity); regulatory exposure (regulated industries push the function toward standalone, where the governance discipline is most legible); and the founder’s personal time-on-customer (founders who spend a third of their week with customers have different organizational needs than founders who don’t). The factors often pull in different directions, and the chapter is precise about how to make the call when they conflict.

Whatever placement is chosen, the decision has to be communicated clearly — to the company, to the customers, and to the function itself. Internal ambiguity about where the function sits produces external ambiguity about who can speak for it, which is one of the more common ways customer relationships go sideways in year two. And because most placement decisions are wrong on the first attempt, the chapter also walks the operational discipline of moving the function. Move it before the placement becomes load-bearing; move it cleanly, with explicit re-onboarding of the senior FDEs into the new reporting structure; and don’t pretend the move is a routine reorganization, because it isn’t.

The chapter closes on a small but consequential point that catches founders off guard: the name of the function shapes how it is perceived, recruited for, and compensated. “Solutions Engineering” pulls a different candidate pool than “Forward Deployed Engineering,” which pulls a different pool than “Deployment Strategy” or “Field Engineering.” The names are not interchangeable. The wrong one will cost real headcount years later, and the cost is hard to see while it’s happening because each missed candidate is invisible. Tomorrow: the economics that the placement decision interacts with.