Forward Deployed Engineer vs FTE: What Does Your Business Actually Need?

Most engineering hiring plans are written in FTEs. "Three more backend Engineers in Q1." "Two FTEs for the payments rebuild." It's a sensible way to budget, and a poor way to describe what the business actually needs.

Our CEO, Benjamin Kane, put the distinction neatly in a recent LinkedIn post: one term describes capacity, the other describes a role and its responsibilities. This article builds on this idea. We'll look at what a forward-deployed Engineer actually is, why the role has exploded since 2025, and how to tell whether your next hire should be measured in hours or in ownership.

What is a forward-deployed Engineer?

A forward-deployed Engineer is a software Engineer who works directly with the people using the software. Instead of receiving a ticket from a product manager three steps removed from the customer, an FDE sits close to the problem. They talk to stakeholders, challenge assumptions, build the solution and stay involved until it works in practice.

The title comes from Palantir. Palantir started using this idea in the 2010s, placing Engineers inside client organisations. Those clients could not share their problems openly. So Palantir sent Engineers to work with those clients instead.

In practice, an FDE is expected to:

• Spend time with the people who have the problem to understand it before proposing a solution.
• Work directly with interested parties and push back when a request does not match the underlying need
• Align technical decisions with product and business goals
• Take an idea all the way to integration, deployment, and use in the real world, not just “merged”

None of that is exotic. Good senior Engineers have always done some version of the practice. What's new is that companies now hire for it explicitly, and name it.

What does FTE mean in engineering?

FTE stands for Full-Time Equivalent. It's a unit of working capacity: one FTE equals one person working full-time hours, or two people working half-time, and so on. Usually, it is used by the finance teams to budget and by engineering leaders to plan headcount.

The advantage of FTE is that it is measurable. It is also limited for the same reason. An FTE tells you how many hours you are paying. It says nothing about those hours being spent solving the right thing.

That is the gap. Two FTEs with CVs can deliver completely different outcomes depending on how close FTEs are to the problem, how much context FTEs have, and whether FTEs are trusted to make decisions. We've written about this before in our capacity vs capability framework, and the FDE conversation is a sharper version of the same point.

Can a forward-deployed Engineer also be an FTE?

Yes. Most are. An FDE is usually a full-time employee or a full-time embedded team member, so they count as one FTE on a headcount spreadsheet.

The difference is what each term tells you:

So the useful comparison isn't FTE or FDE. It's whether your hiring plan stops at the first column.

Why is everyone hiring forward-deployed Engineers?

Because buying AI turned out to be the easy part.

In June 2025, Andreessen Horowitz partner Joe Schmidt published Trading Margin for Moat, arguing that the forward-deployed Engineer had become "the hottest job in startups". His thinking was pragmatic: enterprise AI products have to be deeply integrated with internal databases, APIs and workflows before they can deliver anything. Someone has to do that work, and it can’t be done remotely. He also pointed out that even model providers such as OpenAI and Anthropic were beginning to hire FDEs and solutions Engineers to win enterprise customers.

The hiring data followed. The Financial Times reported in November 2025, using Indeed data, that FDE job postings rose by more than 800% between January and September 2025. FDE listings on LinkedIn had grown twelvefold in a year, while Indeed listings were up around 730%, reported The New York Times by August 2026. An Indeed Hiring Lab economist told the paper that demand was rising partly because enterprises were buying AI systems without knowing how to set them up well.

The same article adds that more realism would be helpful. Stanford economist Nick Bloom pointed out that part of the title's spread is simply that it "sounds cool", and the raw number of listings is still in the thousands.

Forward deployed Engineer vs software Engineer: what's the difference?

Every FDE is a software Engineer. Not every software Engineer works like an FDE.

A backlog is frequently used by a typical software Engineer. Success is determined by shipping what was requested, and requirements arrive already shaped. That approach is entirely legitimate, particularly when dealing with well-defined issues.

An FDE starts earlier. Finishes later. An FDE helps shape the requirement from the beginning, and an FDE does not consider the work finished until the product is actually used. The technical bar remains unchanged. The scope of responsibility for an FDE is larger. The need for communication, product sense and judgement is also larger. An FDE must also know when an AI‑generated solution is good enough and when it is not. That last point matters more every year, as we explored in why developer judgement still wins.

Forward-deployed Engineer vs consultant: how are they different?

This one comes up a lot, and the distinction is simple. A consultant advises. An FDE builds.

Consultants typically diagnose, recommend and hand over a plan. An FDE writes production code, integrates it with your systems and owns it once it's running. That's also why the FDE model reduces one of the most expensive problems in software delivery: context lost through handovers. There's no gap between the person who understood the problem and the person who built the fix, because they're the same person.

Does embedding an Engineer make them an FDE?

No, and this is where a lot of companies go wrong.

You may have an Engineer participate in your sprint rituals, standups, and Slack meetings while still treating them like a set of hands handling tickets. Ownership is not created by proximity alone. An embedded Engineer can become an FDE by doing the following:

• Context. They understand the product, the users and why the roadmap looks the way it does.
• Access. They can talk directly to stakeholders, not just to the person who writes the tickets.
• Responsibility. They're trusted to challenge assumptions and make decisions, and they're accountable for outcomes, not output.

Take any of those away, and you're back to buying capacity, however closely the Engineer sits to your team.

4 questions to ask before adding engineering capacity

Before your next hiring request turns into "two more FTEs", run it through these questions:

1. Can this person understand the problem before proposing a solution? If the answer depends entirely on how well the ticket is written, you're buying capacity.
2. Will they work directly with stakeholders and be allowed to push back? An Engineer who can't question a requirement can only build what they're told.
3. Can they connect technical decisions to product goals? Trade-offs between speed, cost and quality are business decisions. Someone needs to understand both sides.
4. Can they take an idea through integration, deployment and real-world use? Shipping to staging isn't the finish line. Adoption is.

If you need more help sizing the team itself, our guide on how many developers you actually need covers the headcount side of the decision. And if more people haven't been making things faster, it's worth reading why adding more Engineers doesn't always mean faster delivery.

How we apply FDE principles at TechPods

We didn't set out to build an FDE company. But when we look at what makes our co-sourcing model work, the overlap is hard to miss.

We can either build small pods or a bigger co-sourced team of experienced Engineers who integrate directly into our clients' teams, systems and ways of working. They join the same tools and the same conversations as everyone else on the team. More significantly, we hire Engineers who have solid technical backgrounds, together with product knowledge, effective communication, and flexibility. This includes understanding how to correctly use and assess AI, rather than simply accepting anything it generates.

This works whether a client needs a long-term extension of their team or a focused piece of work through our Mission Pods. In both cases, the client keeps control of the product roadmap and engineering priorities. We add the expertise and the ownership.

For the companies we work with, that typically means:

• Shorter feedback loops between business stakeholders and Engineers
• Less context lost through handovers between teams and vendors
• Better alignment between what gets built and what users need
• Additional expertise without giving up control of the roadmap

It's the same reason we focus on smaller teams of Elite Engineers rather than bigger headcounts. Three Engineers who own the problem will usually move a roadmap further than six who are waiting for clearer tickets.

So, FTE or FDE?

You'll still plan in FTEs. Budgets need numbers, and that's fine. The mistake is letting the number become the whole brief.

When you add engineering capacity, ask whether you're also adding the ability to understand and solve the problem. If you're not sure, that's usually the more important gap to close first.

If you'd like to talk through what that looks like for your team, get in touch.