Building a defense startup is hard. In this post, we’ll share some of the lessons we’ve learned about setting up the engineering team to cover multiple products and customer groups. In particular, we’ll focus on Forward Deployed Engineers (FDEs) — engineers that embed with users, deeply understand their missions, and fuel that understanding into inventing new products and capturing programs. We’ll walk through the problems we encountered that led us to building this function and how it fits into the journey of building a defense company.
Scaling to multiple missions is hard
Fifteen months ago, we had a single product — Decrypt. We were starting to scale across the DoD — expanding from a couple of core user groups to other service branches. We began encountering scaling friction — turns out we were running up against some fundamental laws of building in defense.
I. Cookie-cutter solutions don’t work for the DoD.
DoD components are responsible for multifaceted, complicated, specialized mission sets. These unique mission sets require unique software solutions. Trying to build a one-size-fits-all solution results in software that never sees the light of day. If you want to solve user needs — and by extension, win category-defining programs — you have got to build to the specific mission.
We learned this the hard way. Decrypt was the tool we knew, and so we ended up trying to fit every mission problem into that construct. We bolted features onto Decrypt however we could, even when they didn’t really make sense in the context of the product. As you would suspect, this didn’t scale, and the complexity of shipping the product grew over time, slowing our iteration speed and momentum.
This also limited our growth across mission sets. We didn’t have a good forum to try out wildly new ideas, to experiment with different ways we could help the customer. We didn’t have a good way to grant ourselves the freedom to learn about fundamentally new problems.
Being a trusted partner for the DoD requires constantly ensuring that you’re addressing core mission needs. We had to shift from thinking about ‘Decrypt-in-isolation’ to creating an ecosystem of capabilities that can be integrated into large-scale operational missions (e.g., a deterrence operation in the South China Sea). Simply put, one product to rule them all doesn’t work in the DoD.
II. You have to embed with the user to understand what to build.
The world of the warfighter is dramatically different from that of the traditional SaaS customer. You have to operate in austere compute environments, integrate with numerous DoD legacy systems, and contend with highly motivated state-sponsored adversaries attempting to disable or disrupt your capability.
Building successfully for this world requires developing empathy for it, and the only way to do that is to spend time with end users. You need to understand their missions deeply and use that understanding to drive what you build.
When Vannevar was small, this was straightforward. The Mission team — primarily former military officers — were the subject matter experts and embedded with the customers. Engineers were the technical experts who built the product based on guidance from Mission. There was shared state across the company, and Product Managers could hash out competing priorities.
The game of telephone between Mission, Product, and Engineering got exponentially more difficult as we grew. Without intuition around the mission, it became harder for engineers to make tradeoffs and have good taste around new capabilities. We needed to figure out a way for engineers to get ground truth — to build user and mission empathy directly.
Enter: The Forward Deployed Engineer
FDEs are a unique breed of engineers, possessing strong technical chops, good product intuition, high user empathy, and excellent communication skills. FDEs do all that other software engineers do, and more. It’s a software engineering role that also has elements of product management, product design, customer interaction, and vision scoping. FDEs get to live the entire cycle of software development: requirements shaping, product ideation, writing the code, prioritizing what to build next, deploying to the user, and iterating quickly in the trenches. The role is all about innovation speed in the context of a specific customer.
The FDE/user collaboration shortens feedback loops, making the path to product quicker — and this speed is a core value for Vannevar. Once we think we know the right thing to do, we do it as fast as possible. Our advantage is iteration speed: we can do 20 reps before others even step up to the mat. We show up onsite regularly to get feedback from the source and iterate directly with warfighters.
Our CTO, Scott Philips, put it best:
It’s not just about iterating on the technology; it’s about iterating with the warfighter. It’s about how AI integrates into complex warfighting scenarios. We get these tools into the hands of the warfighter so they can experiment with novel concepts of employment, identify technology gaps, and surface risks from real world use. When engineers partner with DoD users to solve hard problems, the lessons learned get incorporated into new techniques, tactics, and procedures that eventually change warfighting doctrine — and that’s a good thing.
Especially when it comes to emerging technologies, customers don’t necessarily know what solutions they need. Embedding FDEs with customers reduces this ambiguity, because by working directly with customers, FDEs can understand the nuances of each mission firsthand. This eliminates a lot of the guesswork usually involved when relying on secondhand insights.
We believe that FDEs are almost a requirement if you aspire to have a large defense business.
What does the evolution of FDEs look like?
The evolution of FDEs is closely tied to the arc of building a defense company. I tend to think of that arc in 3 phases.
Phase 1 is all about building a single product. It’s a roller coaster to get to product mission fit for your first offering. You have no FDEs, because all your engineers are effectively forward deployed. You add features to that product as new requests came in, and eventually hit a ceiling.
This is where we were in early 2023. Decrypt was consistently generating mission value for a specific set of intelligence problems.
Phase 2 is about expanding to different domains. To do this well, you allow yourself the freedom to operate on blank canvases for new problems. You introduce FDEs, who iterate on new ideas without constraints, and maintain a ruthless focus on outcomes. You support iterative development, with a deployment process that allows getting new ideas in front of the warfighter within hours. You eventually end up building multiple products.
We’ve been focused on getting Phase 2 right over the last year. FDEs have bolstered our trajectory by expanding the product portfolio and supporting our expansion across all service branches.
The problem with Phase 2 is that every new product is starting from scratch and reinventing (parts of) the wheel.
Phase 3 is about platforming your products. You extract shared components and services from your products and build them out into a foundational layer. You support composability and allow your FDEs to put together robust ML services from your toolkit with a new bespoke data asset they’re experimenting on. The next custom development phase you run is much shorter, because it stands on top of these building blocks. You’re still crafting custom software for custom mission sets, but it’s much simpler to build, deploy, and maintain.
We’ve started to spend points on Phase 3 in 2024 and expect it to be our main focus for 2025.
Balancing long-term product development with short-term services
Winning big programs and solving top 3 mission problems requires solving mission workflows end-to-end. We’ve found that doing this effectively requires custom development, and FDEs iterating directly with customers on mission workflows and programs has led to the most success for us.
However, as an FDE, you want the derivative of your work to trend towards product. That is — over time, you want your embedded custom development to evolve into product features. This way, each subsequent project can leverage these building blocks, leading to faster development. The key is not to get stuck doing services work as an end in itself, but to use it as a means to build and innovate toward your future products.
We think of this as extreme outcome orientation — when you do whatever it takes to solve the mission, it may feel like services up front, but it leads to product at the tail end.
It’s also worth noting that not every discovery or mission win will translate to being part of a larger capability. Being a great FDE means being able to discern the signal from the noise and knowing when to cut losses or nuke what’s not working. We think about this on roughly a 6-month horizon: what we build must either convert to program, convert to product, or be sunset. In the last year, we’ve built 14 prototypes, sunset 2 of them, and migrated 3 to longer-lived product teams.
What does this look like in practice?
One of my favorite Vannevar stories captures the ethos of FDE perfectly:
It’s early 2023. Jamie Kuppel—our first-ever FDE—is onsite with a customer in Europe. The customer happens to mention that they have some geospatial data that they haven’t been able to exploit lying around in an S3 bucket. Jamie asks if they’re willing to give him access to that bucket—they send him the credentials.
Jamie comes back 48 hours later with the first prototype of Serra: a geospatial app that allows the customer to exploit their data on a map over time. The customer is thrilled: Jamie has built to their exact needs, for an urgent mission requirement, and it’s real within 2 days! They’re so excited that they find funding for continued development on Serra.
Fast-forward to today: Serra is a core product offering for Vannevar and has expanded into several different types of geospatial data. Other FDEs have done similar quick-turn geospatial feature work by building on top of Serra—so their solutions are still customized to the mission set but powered by shared infrastructure underneath.
Serra is entering Phase 3: each custom iteration results in a more robust underlying product, which makes the next iteration faster and easier.
We started the FDE program at Vannevar in April 2023. In the past 15 months, we’ve grown from 3 to 15 FDEs, and the team has:
- Developed 14 new workflow prototypes. 9 of these have generated operational outcomes and are used by mission users on a daily basis. In addition, 3 of these have converted to being supported by full-fledged product teams
- Built a mobile application that is used by forward deployed operators during their missions.
- Built a large-scale RAG platform that has become a core ML offering for the company.
- Deployed to 20+ military bases in support of missions around the world.
- Briefed numerous senior DoD flag and general officers and USG policy makers.
FDEs have been an accelerant to our business. And we’re just getting started.
Miguel Opeña, FDE at Vannevar, testing our systems in theater
p.s., if you’re looking to get into the defense tech space and would like to chat, feel free to hit me up at tn@vannevarlabs.com.
