The first FDE team: when to hire, what to measure and when to add an FDE Lead

A third customer asks for exactly the integration the founder has already built twice. According to a hiring guide from Phosai Labs, a services and consulting firm, that is the right signal to hire a first FDE, and it is far more concrete than “customers need a lot of technical support”.

A signal that clear matters all the more now that many people treat FDEs as a cure-all. James Honsa, who built the legal engineering team at Ironclad, told First Round Review that FDEs are being presented as a universal solution, while the reality is much more complicated.

In the same piece, practitioners stressed that the model suits only certain stages of a company’s growth, and that it takes a great deal of deliberate design to get the benefits.

For a developer looking to move into an FDE role, this bears directly on career choices. How a company decides when to hire, whom to hire, what to measure and when to add a lead tells you whether the job is real engineering or sales support under a new name.

Is a repeated request a hiring signal or a warning sign?

There is an apparent contradiction here. Phosai Labs treats several customers asking for the same integration as a reason to hire an FDE. Rocketlane, writing about the decision to hire FDEs, warns that if many customers ask for the same feature, that work probably belongs in the product.

The two views do not actually conflict. They describe two halves of the same job. The first FDE is hired to take on the work the founder keeps doing over and over. That same person must then recognise which parts have repeated often enough and push them back to the product team, rather than building them by hand a fourth time.

Skip the second half and every new customer becomes a hand-built project, and the company gradually runs more like a consultancy than a product business.

Consider a startup that makes logistics software.

The founder wrote a connector to customer A’s ERP system, then wrote it again for customer B. When customer C asks for the same thing, the first FDE should build C’s connector. In parallel, that person records which parts were the same all three times, so the product team can turn them into a shared module.

The first hire: does everything, but must be strong technically

Recruiting from Scratch, a recruiting firm, describes the first FDE as a generalist: running workshops, writing code, managing customer relationships and carrying feedback back inside the company. At this stage there is nobody to split the work with, so a specialist in a single area gets stuck.

Generalist does not mean weak at everything, though. Phosai Labs writes that communication skills are only table stakes, while technical depth is what sets candidates apart. The reasoning is straightforward: the person who has to spot repetition and move it into the product needs to understand the architecture well enough to know what can be separated out.

The hiring manager also has to decide who this FDE reports to. Phosai Labs advises that at seed and Series A, FDEs should report to Engineering with a dotted line to Product. It also warns against folding FDEs into go-to-market as rebranded solutions engineers.

What to measure when there are no standard KPIs

The easiest number to use is the 20% threshold. According to Phosai Labs, if FDEs spend more than 20% of their time on pre-sales activity, the function has gone off course. In a 40-hour week, that is 8 hours.

If by Wednesday you have already spent 10 hours in demos and answering technical questions for unsigned deals, your team is sliding into sales support.

Rocketlane does not set fixed KPIs. Instead it poses a set of questions about ownership, time and, above all, which customer requests are one-off work and which are repeatable patterns.

That question tests whether FDEs are doing the second half of the job. If after a quarter the list of repeated work keeps growing and nothing has moved into the product, the FDEs are doing the product team’s work for it.

The third metric is workload. Tandem found that FDEs in its research typically handle 3 to 8 accounts at once under normal conditions. That is a common range, not a hard limit, but a first FDE juggling 12 customers will probably have little time left to notice what repeats.

When do you need an FDE Lead?

Recruiting from Scratch puts the mark at roughly 5 to 15 FDEs. From that size, the team needs structure: a career path, clear levels from FDE to Senior FDE to FDE Lead, and a management layer.

As it describes the role, an FDE Lead manages 2 to 4 FDEs on a large or complex customer and sets the deployment methodology.

Take a team of six FDEs. If each handles 3 to 8 accounts, in line with Tandem’s figures, the team is carrying 18 to 48 accounts. At that scale, if everyone works their own way, 48 customers get 48 different deployments. Setting a common method is precisely the lead’s job.

The lead also has to decide how to divide work within the team. Tandem found no standard FDE team structure, but the fastest-scaling teams in its research all separated pioneering work from replication.

For a lead, the question to answer early is who experiments with new customers and who carries a proven approach to the next one.

Where should the lead come from? Recruiting from Scratch argues that an FDE manager should almost always be a former Senior FDE or FDE Lead who wants to develop people, rather than an outside hire.

As teams grow further, Tandem found that leads managing 15 or more people need capacity-planning tools more than management features.

Stage	Who does it	What to measure	Sign of drift
Before FDEs	Founder builds integrations personally	Number of times the same integration is rebuilt	A third customer asks for exactly what was built twice
First FDE	Technically strong generalist reporting to Engineering	Pre-sales share; one-off versus repeatable work	More than 20% of time on pre-sales
5 to 15 FDEs	Add an FDE Lead managing 2 to 4 FDEs	Accounts per person (3 to 8)	Each FDE deploys differently, no common method
Scaling	Separate pioneering and replication teams	Team capacity versus demand	The same person both experiments and replicates

How to read a job description and write your CV

When reading an FDE job description, check three things before looking at the salary. The most visible is the reporting line: Engineering is a good sign, while Sales or Customer Success is worth probing.

Next, see whether the description mentions demos, RFPs or deal support so often that it could exceed 20% of your time. Finally, look for how many customers each person covers.

In the interview, you can ask directly: “When was the last time something an FDE built for a customer went into the product?” If nobody can answer, repeated work is probably not being pushed back to the product, and you will end up building the same thing by hand many times.

On your CV, do not just say you communicate well with customers; that is table stakes. Describe a time you built a feature for one customer, realised a second customer needed it too, and turned it into a shared component.

That experience shows technical depth, and it is exactly what a first FDE team needs most.

What you document about your way of working from your very first project can become the foundation of the deployment methodology you later teach others to follow.