The Forward Deployed Engineer, Chapter 3: Where the FDE Sits in the Org
This is Part 3 of a series walking through my book The Forward Deployed Engineer. In the previous chapter, we mapped the last-mile problem. This one is about the first organizational decision a company makes about the FDE function, and the most common mistake inside it.
The first decision a company makes about an FDE function is almost always wrong, because it’s made by analogy. Someone in the leadership team asks, “is this a sales role, an engineering role, or a customer-success role?” and the conversation that follows decides where the function reports, how it’s compensated, what its success metrics are, and which kind of candidate it attracts. The question feels reasonable. It is the trap. The FDE doesn’t fit cleanly anywhere on the standard org chart, and forcing it to fit somewhere is what produces nearly every downstream failure I cover in later chapters.
There are three placements that organizations actually consider, and I’ll defer the full discussion of which to pick to Chapter 14. The function can sit under Engineering, reporting through the CTO. It can sit under GTM, reporting through the Chief Revenue Officer. Or it can sit standalone, reporting to the CEO or COO as its own deployment function. Each has visible trade-offs and at least one hidden one. The shape of the decision matters less, at this stage, than recognizing that the decision is real and consequential, and that doing it well requires understanding what the role actually does — which is most of the rest of this book.
Pods, Seniority, and Compensation
What I want to spend more time on here is the internal structure of the function itself, regardless of where it reports. An effective FDE function is not a flat organization of individual engineers assigned to accounts. It is a collection of small pods, usually three to five people, each combining the technical and operator strengths in different proportions, and each owning a defined customer surface end-to-end. Pods outperform staffed projects because they hold context across a relationship, share on-call burden meaningfully, and produce platform learnings that an individually-staffed model never quite manages to capture.
The composition of the pod matters, and so does the seniority distribution across the whole function. Most FDE functions are staffed too junior, and this is one of the few generalizations I’ll make in the entire book. The role looks like a senior IC role on the job description, but most organizations hire it like a mid-level customer-engineering role, and the wrong seniority is the most expensive recoverable mistake the function can make. A junior FDE in a customer-facing seat will burn trust at a rate that no platform improvement can compensate for. A senior FDE will produce leverage the platform team didn’t know it was going to get.
If the function is staffed with senior engineers, it has to compensate like one. The deep compensation discussion is in Chapter 18, but the headline matters now: the FDE is one of the few roles where comp parity with the platform engineering team is load-bearing, not negotiable. The moment a senior FDE concludes they’re being paid less than the platform engineers whose work they make valuable, the function’s retention math collapses. There’s no graceful recovery from that, only a slow attrition that takes the function’s best institutional knowledge out the door one quarter at a time.
The Career-Path Problem
The last structural issue is the one most likely to silt up an FDE function within its first two years, and the easiest one to overlook. An FDE function without a clear career path attracts the wrong people for the wrong reasons. Engineers who join expecting it to be a stepping stone to a platform role leave when they realize it isn’t, and engineers who could have made a long career inside the function never join in the first place because the ladder isn’t visible. The two ladders that work are deep technical and customer-strategy, and both have to be built explicitly — with titles, with comp bands, with promotion criteria — rather than left implicit and hopeful. Tomorrow: the technical bar that the whole function rests on.
📖 Get the book
The full org-design treatment — the five real placements, pod composition, the seniority distribution, the compensation benchmarks, and the career ladder — in one place.
Sho Shimoda
I share and organize what I’ve learned and experienced.Categories
Tags
Search Logs
Development & Technical Consulting
Working on a new product or exploring a technical idea? We help teams with system design, architecture reviews, requirements definition, proof-of-concept development, and full implementation. Whether you need a quick technical assessment or end-to-end support, feel free to reach out.
Contact Us