Chapter 11: What is Forward Deployed?
When people hear the term “consultant” many people think of suited up Ivy League graduates that come in, deliver a couple presentations that may or may not be helpful, but read well, and then promptly fly to another tier one city to deliver the exact same recommendation to a competitor. Now, this is completely stereotypical, but all humor is rooted in some level of truth. Regardless, the term “consultant” has become so abstracted and mysterious, there are running jokes that no one even knows what “consultants” do. In fact, many consultants don’t even know what they do. This is not the case with Forward Deployed Developers (FDEs) - a role pioneered by Palantir Technologies, where Forward Deployed Software Engineers embed directly with customers to own both strategy and implementation end-to-end [31]. FDEs assist in strategy, like traditional consultants, and additionally own implementation. I think that the best way to describe this is when you look at traditional consulting hierarchies at other technical services firms. Consultants, designers, developers, project managers, analysts, all flying around the project. I never understood this, I mean it obviously exists for a reason, but why don’t you just take the person who’s building the software and have them talk to the client? Sure it’s a bit of a nuanced role that requires some level of knowledge in all the other roles, but, with AI, that labor structure can be compressed.
FDE vs. Traditional Consulting vs. Staff Augmentation
| Traditional Consulting | Staff Augmentation | Forward Deployed Engineer | |
|---|---|---|---|
| Owns strategy | Yes | No | Yes |
| Owns implementation | No (hands off to devs) | Yes (but directed by client) | Yes |
| Client relationship | Lawyer-client | Employee-employer | Lawyer-client |
| Communication layers | Many (PM, analyst, dev, designer) | Direct but limited | Direct and comprehensive |
| Project context | Second-hand (through docs) | Varies | First-hand (extracted directly) |
| Goal | Deliver recommendations | Execute tasks | Deliver value, transfer, exit |
| Exit strategy | Engagement ends | Placement ends | Gradual handoff to client |
TRADITIONAL CONSULTING FORWARD DEPLOYED ENGINEERING ┌──────────────────┐ ┌──────────────────┐ │ │ │ │ │ Client │ │ Client │ │ │ │ │ └────────┬─────────┘ └────────┬─────────┘ │ │ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ │ Project Mgr │ │ │ └────────┬─────────┘ │ FDE │ │ │ │ ▼ │ Strategy │ ┌──────────┐ ┌──────────┐ │ + Implementation│ │ Analyst │ │ Designer │ │ + Relationship │ └────┬─────┘ └────┬─────┘ │ │ │ │ └────────┬─────────┘ ▼ ▼ │ ┌──────────────────────────┐ ▼ │ │ ┌──────────────────┐ │ Dev Team │ │ │ │ (5-15 engineers) │ │ Support Devs │ │ │ │ │ └──────────────────────────┘ └──────────────────┘ Layers of abstraction Direct line = context loss = full context
In essence this is what an FDE is… someone who is capable of owning the consulting and strategy layer, while also owning the implementation layer. This results in extreme ownership from the FDE over the entire project from start to finish, strong project commitment, reduced communication bottlenecks, and an “owner, operator” like view project success. Another benefit of the FDE role is the proximity to the problem and solution. FDEs, through flattened traditional consulting hierarchies, are able to extract and diagnose the core project problems, goals, etc. rather than hearing it second hand or reading about it in documentation. This is extremely important because many of the nuances of project context are lost through communication abstraction in traditional consulting structures. Again, here we will just take the person who’s building the solution and put them in direct contact with the person who needs something built. In doing so, a comprehensive understanding of the project context can be absorbed and purely translated into a solution. However, it’s important to clear up a distinction between embedding FDEs within a project and staff augmentation.
The clear difference here is that strategy layer. Staffed projects are just essentially employees and purely implementors. As mentioned this is a service that we offer and sometimes works, however this is not the role of FDEs. FDEs are still meant to live at that consulting layer and own the project from end to end. They are to have input on what to build, product strategy, and outcomes. As mentioned, their key value is in that discovery phase and they are weaponized to own that strategy. If clients just need hands, they don’t need an FDE, if they need a solid relationship, strategy, and hands they need an FDE. Let’s dial on that relationship aspect as well.
This is also core to the FDE role, curating a relationship. I’ve mentioned earlier the importance of a relationship, but there is a very explicit social mandate of the FDE as well. As a function of expediting the project lifecycle, FDEs must manage the relationship and all the complexities that come with it. To reiterate, FDEs should formulate a relationship akin to a traditional consultant. Authority, respect, and acceptance of strategy are key. If these are not components of the relationship, then you’re not an FDE, you’re just extra hands in a project.
The FDE Lifecycle: Shock Trooper Model
┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ ┌────────────────┐ │ │ │ │ │ │ │ │ │ │ │ DEPLOY │ │ DISCOVER │ │ BUILD │ │ TRANSFER │ │ EXIT │ │ │────►│ │────►│ │────►│ │────►│ │ │ Embed with │ │ Extract │ │ Implement │ │ Document │ │ Hand off │ │ client │ │ context │ │ solution │ │ Train team │ │ Move to next │ │ │ │ Define what │ │ Prototype │ │ Place support │ │ mission │ │ │ │ │ │ Complete │ │ staff │ │ │ │ │ │ │ │ Deliver │ │ │ │ │ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ └────────────────┘ ◄─────────── HIGH INTENSITY ──────────────────────────────────────── WIND DOWN ───────► "FDEs succeed when they are no longer needed."
Lastly, and this is baked into our process at Benmore, FDEs strive to be removed from the project. FDEs are shock troopers, wholly weaponized for value delivery. Once a project no longer needs strategy, or stakeholders are ready to take over the project, it’s the FDE’s duty to gracefully transfer knowledge to the stakeholders and let them take the reins with their staff or placed staff from Benmore. They’re mission oriented and part of their job is to determine when it’s time to hand the project off. This is counterintuitive when it comes to optimizing long term value from project but it does increase LTV for Benmore in a non-dependence method. By sending in a shock trooper to “right the ship” we can portray a ton of upfront value and develop a value oriented reputation with our clients. Many of our longer and more margin oriented services are better adopted by following this framework. Support contracts are easier facilitated and staff augmentation services are also opted for at a higher rate. Essentially, transparently, I’m saying that we’re not doing all of this from an altruistic position, pounding a ton of value upfront and curating a sound relationship puts both the client and Benmore in a position for long term success and a mutual value creating partnership. FDEs succeed when they are no longer needed. Their job is to bring impact early and often, push the pace, hand off ownership, and leave. A deployed shock trooper.