It starts with listening
The first job of an FDE is to listen.
Before anyone writes a line of code, you sit with the people who live the work, from ICs to VPs, and figure out how the business actually runs: what’s working, what’s breaking, what “great” looks like. You earn trust through clarity, not jargon. And you find the root problem hiding under the symptoms, which is almost never the one people walk in describing.
That’s one hat. An FDE wears three.
A consultant who builds trust and finds the real problem. A product manager who picks the highest-leverage one to solve. An engineer who ships working software, not slide decks or demos. One person carrying a problem from discovery to delivery, with no handoffs in between.
And what we ship is built natively on the platform itself. No bolted-on code, no fragile middleware. Every solution is secure, scalable, and integrated from day one, and it keeps evolving as the business grows instead of cracking the first time something changes.
The cost-center trap
There’s a version of this role that sounds like a cost center: expensive engineers, embedded for weeks, easy to mistake for premium support with a bigger salary.
That framing is wrong, and treating FDE as support is one of the most expensive mistakes I see companies make.
An FDE is a growth function. Not adjacent to growth. Not growth-supporting. A growth engine in its own right.
I’ve said “growth, not support” before. This time I want to show why.
Why FDE actually drives revenue
1. It collapses time to value. When the same person who hears the problem ships the fix, you skip every handoff between sales, services, and engineering. A Custom App, a Workflow, an integration that finally syncs two systems that never talked, goes live in weeks, not quarters. Value shows up while the customer still remembers asking for it.
2. It turns delivery into expansion. Once you’re embedded in the work, you can see the next ten problems worth solving. You’re in the data model. You see the workflows from the inside. Land-and-expand stops being a sales play and becomes a byproduct of being in the room. The next build finds you.
3. It compounds into trust. Realized value is the only thing that actually renews a contract. The customer who watched you build the exact app they’d been dreaming about, not a template they had to bend their business around, doesn’t go shopping at renewal. That switching cost never shows up in a contract.
The whole game is picking the right problem
We talk about finding the Goldilocks zone: the problem that’s most valuable to solve and most achievable on the platform. That sounds like a scoping nicety. It isn’t. It’s the ROI dial for the whole function.
Aim an FDE at a low-value build and you’ve burned a scarce resource. Aim them at the right one and a single deployment pays for the motion and pulls three more behind it.
Which is why knowing when not to send an FDE matters just as much. Point them at the messy, ambiguous, high-value problems where the answer is a build, not a config. Use them as a fancy support queue and you’ve spent your highest-leverage asset on commodity work.
The part nobody says out loud
Want proof FDE is a growth function? At our last customer conference, three customers got up and talked about the apps we’d built together. The automation didn’t eliminate a single role.
Not one.
It freed their teams to put their best people on harder problems instead. Everyone hears that as a feel-good story. Here’s the part nobody says out loud:
Those harder problems are the next builds. Free a team up and they immediately find the next thing worth automating, and they want you to build it. The expansion isn’t extracted from the customer. It’s created with them.
And the platform gets better too
FDEs don’t just win the deal and make the customer happy. They make the product itself better.
We live at the frontier of the platform and hit the real edges first: the missing API, the workflow that needs one more capability, the integration a dozen customers will eventually ask for. Every gap is signal, and we carry it straight back to the core product team. The field is the best product research there is, real problems with real money on the line, and that feedback loop quietly makes the whole company smarter.
So what does it mean to be an FDE?
It means you’re not a deliverable factory, and you’re not a safety net. You’re the bridge between what the platform could do and what the business actually needs. And when you build that bridge right, it carries the most valuable traffic in the company.
I was the first FDE at Rippling. We’re past twenty now, and the mission hasn’t moved: free smart people to work on hard problems. The longer I do this, the more I think the mission and the business case are the same sentence.