An industry buzzword recently has been the term “Forward Deployed Engineer” (FDE).

Depending on who you ask, FDEs are either glorified consultants, solutions engineers who write more code, or normal software engineers who happen to spend more time with customers.

At Orca Fraud, we’ve applied this model across several of our customer implementations. Here are a few thoughts on what we see the role as, how we’ve applied it, and what we’re iterating towards.

At its simplest, a forward-deployed engineer is an engineer who works directly with customers to solve problems. The role is representative of where SaaS is going, particularly as software companies take on more responsibility for delivering customer outcomes rather than simply providing the tooling.

Removing the layers between engineers and customers

The traditional flow for building software has generally looked something like this:

Someone close to the customer understands the problem and gathers requirements. Those requirements move through some combination of implementation, product and engineering before eventually reaching the engineer who builds the solution.

There were good reasons for working this way. Software development was expensive and slow, and engineers needed long periods of uninterrupted focus. Putting engineers in customer meetings came with a real opportunity cost.

For well-understood problems, this model still works well.

It starts to break down when the problem itself is difficult to specify.

Requirements are effectively a compressed version of the context that exists inside a business. Every layer between the customer and the engineer has to decide what information is relevant and what can be left out. By the time the problem reaches the person actually building the solution, some context has inevitably been lost.

There is also a second effect which is just as important.

Imagine you’re sitting with an analyst and notice that they spend two hours every week on a manual workflow.

Someone gathering requirements might document the workflow and the pain associated with it. An engineer who understands the customer, their business and the underlying software can go further. They can understand how the workflow fits into the broader system, map it against what is technically possible, and potentially see a relatively simple way of automating it.

The distance between observing the problem and being able to act on it becomes much shorter.

This is one of the main benefits we’ve seen from putting engineers directly in front of customers. They build context around the business at the same time as they build context around the technical problems. That makes it easier to identify opportunities that might otherwise get lost between teams, and much faster to turn those opportunities into working software.

Context changes what you build

Our forward-deployed playbook at Orca generally starts with understanding the business before doing much engineering.

How does the business work? Who are its customers? How do they detect fraud today? What fraud patterns have they seen before, and where are the gaps in their existing monitoring?

That context quite often changes what we end up building.

For one of customers, we started with what was largely a transaction monitoring platform. As we went deeper into how fraud happened within their business, it became clear that transactions were only one part of the information required to detect it. Certain events happening on an account were important inputs into whether a later transaction should be considered suspicious.

That meant modelling those customer-specific events inside Orca and making them available directly within our fraud detection rules. This wasn't something that came from a predefined product requirement. It came from understanding how fraud actually happened at that customer and then working backwards into what the system needed to support.

We see the same thing with fraud patterns more generally. Two customers can both be looking for transaction fraud while having very different products, customers and ways in which they are attacked. During an implementation we'll often build custom conditions into the rule engine, or a specific dashboard that makes a pattern visible to the fraud team, because we've seen something in their data or workflow that matters to them specifically.

Having the engineer involved in those conversations makes that loop much shorter. They understand the customer's problem, know what Orca can already do, and can see where the platform needs to be extended. Some of those changes remain customer-specific; others become capabilities that we can generalise into the product over time.

This is one of the areas where direct customer context has a very tangible effect on the software that gets written.

The customer becomes the feedback loop

Removing the layers between engineering and the customer also changes accountability.

There isn’t a QA or implementation team sitting between the engineer and whether something actually works for the customer.

If you ship something that doesn’t work, you find out directly.

If you build something useful, you see that too. You see how the customer uses it, what it saves them time on, and what they actually value about it.

Over time, an FDE should develop a fairly detailed mental model of what each customer values. That starts influencing how you think about prioritisation and engineering trade-offs. You have a much better intuition for where engineering effort actually creates business value because you’ve seen the outcome yourself.

What this looks like at Orca

A big part of the model for us is being embedded enough with the customer that Orca starts to feel like an extension of their fraud team.

That means taking responsibility beyond getting the software live. We want to understand the fraud problems they are dealing with, help work through them, and ultimately own the fraud outcome alongside the people using the product.

The same approach carries through the implementation.

Sometimes, we have a standard API integration. In other cases, we've built directly against customer data infrastructure, mapped their data into Orca and taken responsibility for getting the integration running.

Once data is flowing, we build and backtest the initial fraud rules with the customer. After go-live, we continue meeting with the people investigating the alerts and look at what was fraud, what generated noise, what we missed, and what new patterns they are starting to see.

That feedback goes directly back into the system. Rules change, thresholds get tuned, new conditions get added and, where necessary, the product itself changes.

Over time, the idea is that the FDE builds a fairly detailed mental model of both the customer's business and what their fraud team actually values. That makes the implementation better, but it also changes how you prioritise engineering work. You have direct context on which problems matter, how painful they are, and whether the thing shipped actually improved the outcome.

The process ends up looking roughly like:

Understand → Build → Backtest → Deploy → Measure → Adjust.

Where we see the role evolving

The FDE role should not only exist during customer onboarding.

Because the role sits somewhere between engineering, product and the customer, there is value in having FDEs involved much earlier in the lifecycle. That can mean helping with RFPs, joining technical discovery during a sales process, working through whether a particular use case is possible, or building something small to prove it out.

The useful part is that the same context can then carry into implementation. The engineer who helped understand the problem before the contract was signed can stay involved while the integration is built, the fraud logic is configured and the customer starts using the product in production.

The same applies after go-live. Staying embedded with the fraud team gives the FDE a good view of where Orca is working well, where there are still gaps and what other problems exist inside the customer. That can lead to product changes, but it can also lead to expanding the problems Orca solves for that customer.

For an early-stage company, that connection to the commercial side of the business is useful. Engineers get a much more direct understanding of how their work affects whether a deal closes, whether an implementation succeeds, whether a customer expands and ultimately how the company generates revenue.

There is obviously a risk in taking this too far.

If every customer problem results in another piece of bespoke software, eventually you end up with a collection of different products that become increasingly difficult to maintain.

A big part of the job is therefore recognising where the abstraction should sit.

A new condition might initially be added to the rule engine for one customer. If we start seeing the same requirement elsewhere, it probably makes sense as a more general product capability. A dashboard built around one fraud workflow might expose a pattern that should be supported natively. Something an FDE repeatedly works through manually with fraud analysts can eventually become an automated workflow or inform what one of our machine learning models should detect.

The customer work gives us examples of the problem in its real environment. Over time, the common patterns across those implementations should make their way back into the platform.

AI makes this model substantially more practical.

Software can now be built and iterated on much faster than it could a few years ago. Historically, putting a strong engineer in front of customers came with a fairly direct cost because those were hours they weren't spending writing software. That trade-off is becoming less severe.

As implementation gets faster, context becomes more important.

There is very little value in being able to build something quickly if you're pointing that engineering capacity at the wrong problem. And a lot of the context required to make that decision is difficult to capture in a specification. It sits across conversations with users, existing workflows, customer data, previous fraud cases and knowledge that may never have been written down.

Being forward deployed gives engineers a much better way of acquiring that context. They can understand the problem directly, combine it with knowledge of what is technically possible, and increasingly use AI to test and implement solutions quickly.

Over time, the role becomes a fairly tight loop across the entire customer lifecycle: understanding problems during pre-sales, carrying that context into implementation, staying close enough to production to see whether the solution worked, and feeding what we learn back into both the product and the next opportunity.

As Orca scales, we think maintaining that level of customer empathy and direct feedback will be crucial to our success. The FDE model gives us a way to preserve that closeness as we grow, and so far it’s proved to be a very effective way of working.

‍