The Two Questions

FDE is in vogue, and it's easy to want things that are in vogue — the same way it's easy to want "AI" because everyone else is doing it. But the function is expensive, structurally demanding, and wrong for most companies. Whether it's right for yours comes down to two questions, answered honestly.

Question one: do you need it?

Not want — need. Is there some corner of your business where you must take a technically complicated thing to market with a non-technical buyer? That's the only situation that calls for FDE.

If your motion is technical-to-technical, there are great things you can do with DevRel and developer engagement. If you're selling more traditional SaaS, a sales-led motion works. Both are cheaper, both are better understood, and neither requires you to staff engineers you'd trust alone in a boardroom.

Question two: do you have a platform?

Or phrased honestly: are you willing to invest in building one? However tempting it is to hire engineers who can go make you money, if they aren't building on top of shared primitives, you are in for a very bad time. The maintenance burden on the team will be enormous even with a robust platform — never mind without one.

The profile

Both answers yes? Then the hiring bar, in one line: an FDE is nothing more than a customer-facing software engineer. Someone you would hire as a software engineer on your team — and, at the same time, someone you'd trust in front of a customer in some shape or capacity. It's an intersection, not a compromise: a salesperson who can't build, and a builder who can't sit with a buyer, are each only half the role.

In the wild

Rippling's FDE function went from its first hire to roughly 25 people in a year — the demand side of the two questions was never in doubt. The discipline is on the second question: the teams that scale keep score of what fraction of each new deployment came from existing primitives, because that number is the difference between an FDE program and 25 independent contractors.

The intersection, priced

"Customer-facing software engineer" is a clean definition and an expensive one. Pauline Brunet describes the same intersection from the hiring side, and it is longer because the job is: leading discovery with a CIO, a CTO, a COO, an engineering manager and a developer in the same week; finding the real use case; understanding the customer's culture well enough to change it; and "at the cutting edge of the technological advancements" — "because your customers are expecting you to be the expert."

Her bar at Cursor is five-plus years of software engineering, and explicitly no new graduates "at this moment". Which is where the definition acquires a clause Bai's does not have.

Two further structural notes from the same team, both of which read as answers to "what does this org look like in a year":

• Geography first, industry later. Cursor's team is organised by region for now and expects to move to industries, for a reason that is about credibility rather than efficiency: "when you talk to an industry and you don't use their lingo, you immediately lose credibility. If you talk to a bank and you're not talking about payment systems, if you're not talking about asset management, risk, you kind of lost them."
• Product SMEs inside the team. One person owns long-running cloud agents, another owns the SDK, and engagements pull them in. The platform from the previous sheet needs specialists, or every FDE is re-learning every primitive.

The answer neither question anticipates

There is a third response to "the profile is too rare to hire", and it is the one a harness site should have seen coming: point a harness at the job.

Vasuman Moza's firm runs department-wide agent deployments, which is FDE work at maximum depth, and he states the constraint plainly — the people who are both "the technical like top 1%" and able to extract requirements from a non-technical operator in real time barely exist. "Typically, you'll have consultants that you then train on the technical side, or engineers that you then kind of train on the soft skill side, but it's very hard to find people who are the best of both."

So Varick built what they call an FDE agent, and the framing is not automation of the role — it is "our effort to bolster the existing forward deployed engineers that we do have," so that one person can hold several client relationships without the firm hiring fifty people to do it.

What it absorbs is the part of the job nobody writes a job description for. Moza is blunt that technical readers underestimate it: "it's very easy to misunderstand how deeply involved you have to be with the client. They're emailing you 24/7. They're sending you hundreds of pages of documentation. And every single process they will pull you in a different direction."

The mechanism is on the last sheet of this pillar, because it is the clearest example available of what happens when the two questions get answered a third way.