The Forward Deployed Engineer, Chapter 16: When Not to Build an FDE Function

This is Part 16 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we worked the economics. This one makes the inverse case — the conditions under which the right call is not to build the function at all.

The whole book, up to now, has argued that the FDE function is consequential and sometimes essential. This chapter inverts the argument. Some companies should not build the function at all. Some should not build it yet. Some should build something adjacent that looks like an FDE function from the outside but isn’t. The chapter exists because, in my advisory practice, I have watched founders read the first fifteen chapters of this book and conclude that they need to start hiring FDEs next week, when the right call for their company was something else entirely. The book’s authority does not depend on convincing every reader to build the function; it depends on being honest about who shouldn’t.

The five disqualifying conditions are the ones I’ve seen most consistently produce functions that fail almost regardless of execution. A customer base too small for the leverage to compound — if you have three customers, you do not have an FDE function, you have three engagement managers with engineering chops, which is fine but is not what this book describes. A product still in design-partner phase where the platform isn’t generalizable — you cannot run the outer loop against a platform that doesn’t yet exist. A sales motion that hasn’t found its shape — the FDE function needs a steady inbound to deploy against, and a company still figuring out who its customer is doesn’t have one. A founder unable to spend serious time with customers personally — the function is not a substitute for founder-customer time in the early years, and treating it as one produces a layer of insulation between the founder and the customer that the company will pay for later. And an engineering culture that is allergic to customer-facing work — the FDE function needs to be welcomed into the engineering team’s rituals, and an org that resists this can starve the function even when it’s otherwise well-built.

If the answer is not an FDE function, what is it? The alternatives are not consolation prizes; they are real organizational designs that, for the right company, are better than the FDE function would be. A strong Customer Success function, with a different role and a different rubric than the FDE function, can do most of what the FDE function does for products that are mostly self-serve. A Solutions Engineering team optimized for pre-sale rather than post-sale can carry early-stage GTM until the product matures enough to justify the FDE investment. A Founding Engineer pattern, in which the technical founders themselves do the deployment work for the first dozen customers, is the right answer for almost every company in its first eighteen months. And a Partner-Led Implementation model that delegates the last mile to certified system integrators can work for products whose deployments are systematizable enough to license.

Hybrid Patterns, the Premature-Optimization Trap, and What to Build Instead

Between the full function and the alternatives sit several hybrid patterns worth knowing. The FDE-of-One pattern is a single senior IC doing the role for the first customer cohort, which can produce great results for a year and become unsustainable in the second. The Rotational FDE pattern, where platform engineers rotate into customer-facing tours of duty, builds institutional knowledge in both directions and is a particularly good fit for companies whose engineering culture has the right disposition. And Embedded Partner Engineering, where a system integrator’s engineers are trained, certified, and accountable to your standards, can extend reach into geographies or industries where your own hiring funnel doesn’t yet work. Each hybrid has its own conditions for success and its own pathway to graduating into the full function later, if and when the platform deserves it.

The most common strategic failure I see is what I’ll call the premature-optimization trap: building the function too early, before the platform has the surface area to compound, because the founder has read enough about FDEs to be excited about the role but not enough to recognize that their company isn’t ready for it yet. The trap produces every cost of an FDE function and none of the leverage. The cure is unromantic and consists mostly of patience, plus the operational signals that tell you the function should now be built — second-customer pull on the same pattern, repeated procurement losses on a specific deployment dimension, and platform engineers spontaneously developing customer-facing instincts that they can’t fully act on inside their current role.

The chapter closes by translating the inverse argument into an instruction set. If you’ve concluded the FDE function is not right for your company — not yet, or not ever — here is what to build instead, in operational detail. The small set of capabilities that, in practice, give a company most of the FDE function’s value without most of its weight. Tomorrow: the measurement discipline that the function depends on.