HappyRobot's founding FDE: if your forward deployed engineers aren't improving the product, you're running a services business
Taher Poonawala, HappyRobot's first FDE hire, writes that the company has grown to 60 FDEs and argues they should work as coding product managers whose fixes feed back into the product. He suggests three metrics to check that this is working.
In a HackerNoon essay published October 12, Taher Poonawala, a senior FDE at HappyRobot who joined as its first FDE, says he has watched the company scale to 60 FDEs and a $1.2B valuation. His argument is that agentic startups rushing to build forward-deployed teams often misuse them.
He says AI agents need FDEs because agents don't just organize work, they do it. Every customer's SOPs, edge cases and definition of done are different, and the prompt, tools and actions have to be tuned together inside the customer's real process. The trap is stopping there: build for one customer, expand the contract, repeat. He calls that "a services business wearing a software valuation", squeezed between Palantir on complex work and customers building simple things themselves with AI coding tools.
His fix is to treat FDEs as an extension of product. At HappyRobot, a UAT testing tool built for one customer became the standard for every deployment, and retry and context-persistence logic from one rollout went into the core product. He suggests tracking three things: the share of configuration customers do themselves (should rise), time to deliver similar deployments (should fall), and revenue per FDE (should rise).
Why it matters for FDEs: this is a useful question for candidates to ask in interviews. A team that turns field work into product gives FDEs more leverage and harder problems over time. A team that only does bespoke builds risks becoming a consultancy with a startup's title.
Source: hackernoon.com