Forward deployed engineering team: scaling the FDE motion

FDE is the hottest title in software right now. Every company wants a team, and as Isy Lynch (Product & FDE at SolveAI) put it at PropelX, "FDE is really sexy at the moment and everyone's scrambling to try and build an FDE org." That's exactly why she asked the room to slow down and check whether it's actually the right move for them.

Because the biggest mindset shift an FDE team needs isn't technical. It's recognising that an FDE is a genuinely different role from an implementation consultant or a project manager. Treat it as a rebrand of the same job, with a shinier title and the same old playbook, and it won't work. 

That's also why people with no prior experience and no preconceived notions of how delivery "should" work often end up being better FDEs than people who've been in the seat for years. Isy saw it again and again while hiring at Palantir: the fresh grads kept beating the veterans, because they brought more curiosity. Great news for new grads. Slightly awkward news for the rest of us.

That tension ran through the "Scaling the FDE motion: scope, commercials and execution" panel at PropelX 2026 in London. Milos Mandic (Founder of FDE Hub) moderated the conversation with Isy and Boaz Francis (Head of Forward Deployed Engineering at Wonderful). Both panelists are ex-Palantir, and they're at very different stages: Isy is hiring her first FDEs, while Boaz runs a team of more than 400.

Why do companies need a forward deployed engineering team?

Milos opened with the shift that made FDEs necessary in the first place. Building has become cheap: a demo that used to take weeks or months can now be stood up in about a day. But knowing what to build hasn't got any easier, and that's still the hard part.

Customers have raised the bar too. Two years ago, a good demo was enough to earn a pilot. Now many customers want to see an end-to-end solution working on a narrow part of their business, on their own data and infrastructure, before they commit. The FDE motion exists to close the gap between a working build and something a business will actually use, which is why it has become a core part of modern implementation.

What does "FDE" actually mean?

The term has become an umbrella. Some FDEs spend weeks or months embedded with a single customer. Some work in pods of one to three people, with one person leaning more towards engineering, another towards product and another towards strategy. And some FDEs handle 10 customers in parallel. What they all have in common, Milos said, is that the right people are hard to find, the team is hard to scale, and it's hard to balance commercials with delivery.

Isy's view is that the FDE motion is really about learning from customer engagements to build a better product you can keep selling. If that isn't what you're after, you might not need an FDE org at all. As Milos summed up at the end of the panel, start by asking yourself why you want one, because every other decision about hiring, scaling and commercials follows from that answer.

Who should you hire for a forward deployed engineering team?

According to Isy, the best FDE candidates can come from a broad range of backgrounds, but they usually share one thing: they're "a little bit unhappy with whatever they're doing right now and they're not sure why." That might be a consultant who misses delivering something end to end, or a developer at a software company who feels too far from the outcome. What they want is the whole problem, not just their slice of it.

Boaz added that the best engineer isn't always the best FDE. The talent matters, but attitude is what makes or breaks the team. He'd much rather hire someone hungry and gritty with less experience than someone with all the knowledge in the world who brings morale down. FDEs spend a lot of time in difficult situations where they simply have to figure things out, and one negative person in that environment is "so detrimental and so costly for the business." It's the kind of team culture that decides how well a project gets executed.

How do you scale an FDE team to hundreds of engineers?

Wonderful, which describes itself as an AI operating system for enterprises, works across 35 different markets. Each market starts its own forward deployed engineering team and operates independently, a bit like its own startup, and the whole FDE organisation recently crossed 400 people. Boaz said the structure stays flat, with everyone officially just an FDE.

But as the team grew, a pattern appeared. The people who naturally end up leading are the ones who span a bit of the customer side, a bit of project management and a bit of the technical side. Where Wonderful had hired too narrowly for specialists, it missed that "glue" that brings the whole team together. When you're scaling professional services, hire for the people who connect the pieces, not just the people who are best at one piece.

How do you balance speed for customers with improving the product?

As the team and customer base grow, Isy said, a "really healthy tension" shows up between delivering at speed and caring about how each engagement can improve the product. Solve every customer's problem fast without feeding anything back, and your FDEs are really just consultants. Spend all their time on the product, and customers wait.

Her fix is cultural and structural. SolveAI integrates FDE teams into product teams and makes sure FDEs get real time to spend on product work. But it really comes down to incentives: "If you're incentivizing people and measuring the metric of success as how quickly you deliver for a customer, you're not ever going to get people wanting to spend time improving a product." Measure what each pilot or engagement taught you, and how it improved the product, and the behaviour follows.

Where should FDEs sit in the organisation?

Milos asked whether positioning the FDE org in a particular part of the company shapes the kind of motion it develops. Boaz said it all depends on what FDEs are incentivised on. If the incentive is commercial, the team will go one way. If the incentive is customer outcomes, it creates a completely different set of priorities.

In a small company, it might not make much difference, because everyone is working closely together anyway. But as the organisation scales, where the team sits and what it's measured on start to matter a lot more. It's worth deciding deliberately, before the org structure decides for you.

How do you make the product your leverage?

Isy is actively avoiding one trap: FDEs building up a collection of external scripts and know-how that lives outside the product. If her team learns something from working with a customer, the rule is to build it as a prototype inside the product and feed it back to the product team. That way the product gets better with every engagement, and customers can eventually do more themselves without an FDE in the room. It's product thinking applied to services.

If your FDE knowledge lives in a shared folder of scripts, you haven't built a product. You've built a very expensive consultancy.

Allow some healthy inefficiency

It's tempting to push every solution straight into the product after the first time you solve it. Isy argued against that. Solve a problem once and whatever you build will carry the bias of that one customer, but solve it 10 times and you can see what the real problem actually is. She calls it "a healthy inefficiency," and it's what gives FDEs the breadth to contribute useful features back to the product instead of one-off customisations.

How do FDE teams charge customers?

Neither company bills by the hour. Boaz explained that the power of an FDE organisation, compared to traditional services or consultancy, is its focus on outcomes and value. FDEs often spend a lot of time with a customer early on, so billable hours "would go through the roof very quickly," and the real value comes from customers adopting and building on the platform over time. SolveAI, meanwhile, leans towards outcome and licence-style fees rather than a standard SaaS subscription.

Boaz also had the line of the panel: "If we came in with one particular use case and we just delivered that use case perfectly, then I would say we probably just failed." The goal isn't to sell one point solution for one problem. It's to sell a partnership that carries the customer through the AI era, which is a very different kind of professional services engagement.

Will FDE-built software replace SaaS tools?

An audience member asked whether software built by FDEs on these platforms will end up replacing common SaaS tools like CRMs and ERPs. Boaz's answer was that most enterprises are already frustrated with their SaaS stack. He has walked into companies with 16,000 subscriptions they weren't sure about, which is exactly why Wonderful positions itself as a single AI operating system that connects to existing systems.

In some cases, replacing software outright makes sense. Wonderful replaced its own CRM in just under four weeks, building only what it needed to run the business its way, without thousands of unused features. In others, the better move is to enable the existing tools with AI and build on top, depending on what the enterprise wants. Either way, it's a reminder that what customers buy is shifting from features to outcomes.

5 key takeaways on scaling a forward deployed engineering team

1. Start with why. Decide what you want an FDE team to achieve before deciding who to hire.
2. Hire for curiosity and attitude. Grit and curiosity often beat years of experience, and one negative hire hurts the whole team.
3. Hire the glue. As you scale, the people who span customer, project and tech end up leading.
4. Reward learning, not just speed. Measure what each engagement taught the product, or FDEs become consultants.
5. Sell partnerships. One perfectly delivered use case is a failure if it doesn't lead to the next one.

Best practices for building a forward deployed engineering team

• Write down your why. Before opening a req, note what the team should feed back into the product, and whether better implementation would solve the problem instead.
• Test for curiosity. Look for candidates who want the whole problem, including new grads and restless consultants, and assess them on real customer scenarios.
• Integrate FDEs with product. Give them protected time for product work and a direct path to ship improvements.
• Ban the script bank. Build learnings as prototypes inside the product so the platform, not a shared folder, gets smarter.
• Price for outcomes. Use pilots, design partnerships and licence or outcome fees instead of billable hours.

About Rocketlane

Rocketlane is an agentic AI-powered professional services automation (PSA) platform built for services teams running complex implementations.

Its AI layer, Nitro, deploys named agents that do the work, not just flag it:

• Migration Agent — data preparation and transformation
• Workforce Agent — repeatable configuration at scale
• Documentation Agent — project context current across calls and emails
• Project Governance — delivery standards enforced proactively
• Nitro Signals — account risk surfaced before it escalates

The core distinction: Nitro agents produce the deliverable or enforce the gate. Most platforms advise. Rocketlane acts.

Teams using Rocketlane ship faster, recover margin through tighter governance, and scale delivery without proportional headcount growth.

Related sessions from PropelX

• Professional services trends for 2026: why delivery is the new moat: Sri Ganesan on why the FDE is the first job created for the outcome era.
• Building AI customer onboarding: redesigning PS teams for the outcome era: how Chargebee forward deploys through agents, engineers and experts.
• Implementation partner management: how a $1M guarantee rewired our deployment services: how Fin built FDEs into its deployment model.

The best FDE teams learn faster than they bill. See how Rocketlane helps delivery teams track what every engagement teaches the product.