The Forward Deployed Engineer — Paden Gayle (#Books)
Paden Gayle has started writing “The Forward Deployed Engineer,” and two chapters are currently available on O’Reilly: it is still being written and published as an Early Release. Those chapters already give me the impression that this will be a good book. I particularly enjoyed the sections on responsibility and aligning different stakeholders’ positions.
An FDE (Forward Deployed Engineer) is an engineer whom a technology supplier embeds in a customer’s organization. They identify the problem to solve, agree on scope, build the system, and bring it into production. The author compares the role to being a founder inside someone else’s company. The scale of responsibility is similar, but the data, infrastructure, security rules, and people belong to the customer.
I like how precisely this captures the contradiction: taking responsibility for a result in an environment you do not control. If launch requires access, approval, or another person’s decision, your job is to find that person and get the matter resolved. You do not need to do everything personally.
Then it gets interesting: “the customer” has several incompatible ideas of success.
- The person who allocated the budget wants an economic return.
- The process owner wants understandable changes and a functioning team.
- IT and security want controlled access, data, and consequences of errors.
- Users want a particular piece of manual drudgery to disappear.
- The internal sponsor wants the result they have already promised their colleagues.
The book offers a useful technique: describe the same solution in each stakeholder’s language, with every description remaining true. If you promise one person a process without human involvement and another mandatory confirmation of every step, the problem is already in the design. Averaging their wishes or satisfying the loudest person is not enough.
Responsibility is compatible with boundaries. The author explores documenting scope, exclusions, customer obligations, and verifiable acceptance criteria. One example: a Friday export that took four hours of manual work appears automatically in a shared folder by nine. It is immediately clear what to accept and who can verify it.
The economics of the role are interesting too.
Why is there demand? The customer needs a working process in their systems, with their data and constraints. In the author’s view, AI makes code cheaper to write, while choosing the right problem, securing agreement, and taking responsibility remain difficult. When implementation accelerates, these questions become more visible. It is now cheaper to quickly build something completely unnecessary too :)
Where does the supply come from? For an AI supplier, such an engineer helps turn product capabilities into results for which the customer will keep paying. The book argues that coding agents allow one engineer to take on work that previously needed a small team: customized implementation becomes more affordable. This is already becoming a separate business activity: AWS announced a $1 billion investment in FDE.
From the engineer’s perspective, I see the appeal in autonomy, direct feedback from users, and influence over the whole journey from task to result. The price of that autonomy is negotiation, uncertainty, and someone else’s constraints. Combining strong engineering with the ability to hold this context is difficult.
For now, this is a recommendation of the first two chapters. Even so, the book already looks useful for tech leads and engineers who have to agree on what is worth building at all. I want to follow its progress.
#Books #AI #Engineering #Management #Product