The Definitive Guide to Forward Deployed Engineering

And why it's becoming one of the most popular roles at AI companies

✨ Hey there this is a free edition of next play’s newsletter, where we share under-the-radar opportunities to help you figure out what’s next in your journey. Join our private Slack community here and access $1000s of dollars of product discounts here.

Recent top posts: Startup skills for non-technical people, 61 people open to meeting a cofounder, and more.

---

If you work in tech, you should learn about Forward Deployed Engineering (FDE). It’s quickly become one of the most popular roles that nearly all fast-growing AI companies are looking for…at the same time, it’s the type of role very few people and companies seem to actually understand.

FDE was originally popularized by Palantir (now a $275 billion public company). So I thought it’d be a good idea to speak with Vinoo Ganesh, the person who designed and built the program that turned software engineers into FDEs at Palantir (back in 2015).

The program was called Project Frontline, and it worked by sending engineers into live customer deployments across defense, intelligence, and enterprise. Over 250 engineers went through it. They’re now at OpenAI, xAI, Anduril, and dozens of leading companies.

I asked him to put together his best advice for people looking to become (or hire) FDE, which includes:

• Why FDE is (increasingly) important to startups

• The history of the FDE role

• His personal experience becoming an FDE

• Why you should consider becoming an FDE

• Why you should not become an FDE

• A playbook for becoming an FDE

Even if you are not looking to immediately become (or hire) an FDE, I think you’ll find the article insightful. It contains lots of stories and ideas that apply to people horizontally across a startup, who wish to understand their customers and be in the weeds. Also just think you’ll find his story interesting. Hope it’s helpful!

(By the way You can follow Vinoo on LinkedIn, or the kepler.ai blog for more of his thoughts)

---

The Definitive Guide to Forward Deployed Engineering

The Bottom Line

The Forward Deployed Engineer (FDE) has become the most valuable credential in tech, and most people don’t understand why.

If you look at job postings at OpenAI, xAI, Anthropic, Helsing, Anduril, Scale, or Palantir, you’ll notice they’re not just looking for software engineers. They’re looking for engineers who can deploy, who can sit with customers, who can make software work in the real world.

Here’s what you need to know:

An FDE is a software engineer who owns customer outcomes. Not customer relationships, not customer satisfaction scores, but outcomes: the actual results the customer is trying to achieve with the software. This distinction sounds subtle, but it changes everything. A sales engineer’s job is to help close the deal. A solutions architect designs how the product fits the customer’s environment. An FDE’s job is to make sure the customer actually wins.

The critical insight is that you can’t easily hire your way to a true FDE organization. The skill set is too rare, too specific, too dependent on experiences most engineers never have. Traditional engineering jobs don’t build this skill set because they’re structured to insulate engineers from customer reality. You write code, you ship it, you move to the next ticket. You never feel the weight of a customer depending on your work, never see what happens when your elegant system meets messy real-world data, never have to look someone in the eye and explain why the thing they needed isn’t working.

So how do you hire forward deployed engineers? You don’t. You grow them.

This was Palantir’s critical insight, and it took us years to fully understand it. The only way to build an FDE organization is to take talented people and put them through a crucible that transforms how they think about building software.

Why this matters now: Three forces are making the FDE model the default rather than the exception.

First, AI is making deployment harder, not easier. AI systems require fine-tuning, prompt engineering, evaluation, and ongoing adjustment. You can’t throw an LLM over the wall and expect customers to figure it out. OpenAI, Anthropic, xAI, and every serious AI company is building FDE-style functions, even if they don’t call them that. There’s a related point here about what it means to be an engineer at all: if AI can do much of what junior engineers used to do, the engineers who remain valuable are the ones who can do what AI can’t, which is sit with a customer, understand their real problem, and own the outcome.

Second, defense tech is exploding. Anduril, Palantir, Shield AI, and dozens of startups are building software for military and government customers who can’t tolerate deployment failure. These customers operate in austere environments with unique constraints, and you can’t support them with a helpdesk. You need engineers in the field.

Third, enterprise buyers are getting smarter. After decades of shelfware, enterprises are starting to demand implementation guarantees. They want to see engineers on site and know that someone will own the deployment, not just the sale. The vendors who can deliver this will win.

Five years from now, I expect every serious enterprise software company to have an FDE function. If you’re thinking about where to invest your career, this is the trend to bet on.

The Grey Track Jacket

[1] My Grey Track Jacket

At Palantir, everyone got a black track jacket. Standard issue. But there was another jacket, a grey one, that you couldn’t buy or request.

The mythology was that your black jacket had faded through years of experience, that you’d worn it through enough deployments and enough hard field work that the black had burned away and become grey. Leadership awarded them when you had proven yourself in the field.

Brian Schimpf, now CEO of Anduril, awarded these jackets when he was one of Palantir’s senior engineering leaders. When I got mine, I didn’t feel pride or accomplishment. I felt the weight of what it represented: the late nights, the systems that failed, the customers who’d depended on me when things went wrong. The jacket wasn’t a trophy. It was an acknowledgment that you’d been through something, and that something had changed you.

When engineers ask me how to become an FDE, they want skills to develop, certifications to get, keywords for their resume. But that’s not what this is about. The jacket was just the symbol. The transformation is what matters.

---

Looking to meet like-minded people? Join the Friends of Next Play Slack Group.

---

My Transformation

If you want concrete recommendations on how to become an FDE, skip to “The Playbook” at the end. But if you want to understand why this transformation matters and what it actually feels like, read on.

I joined Palantir on the product development side in Palo Alto. I fixed Jira tickets, wrote code, built tests, did code reviews, architected systems. I attended sprint planning and hit my deadlines. By every internal metric, I was doing good work.

But once I rotated into the field, what I saw broke how I understood my own job.

We had a product called Phoenix. It worked beautifully for the use case it was designed for. Clean architecture, solid code, good test coverage. We were proud of it.

Then I watched it fail.

The system relied on a data integration that seemed straightforward: when new data comes in, we generate a keyspace in Apache Cassandra. We’d designed it to create keyspaces in 10-minute increments for easy automated deletion. We thought it felt like a clever trick.

Then bad data came in. Well, specifically, no data came in. The date column was empty. Our system interpreted this as the epoch: January 1, 1970. So it did exactly what it was designed to do, and generated every keyspace between January 1, 1970 and October 7, 2013.

That’s 2.3 million keyspaces. Cassandra requires roughly 5MB per column family. You’d need 14 terabytes of RAM just to start up.

The system OOMed on startup. As was commonly said at Palantir back then, “bad times on boats.”

I sat there watching this happen, and I realized something that should have been obvious: we had never seen the data this system would actually process. We had never been in the room when garbage data showed up at 2am. We had never had to look a customer in the eye and explain why the system they depended on was suddenly unresponsive.

This wasn’t a one-time thing. I saw it again on other projects. We would build something elegant and technically sophisticated, ship it to the field, and watch it collide with reality in ways we never anticipated. The pattern was always the same: we built without understanding, optimized for the wrong things, and solved problems that didn’t exist while ignoring problems that did. The gap between what we were building and what users actually needed wasn’t a small gap. It was a chasm.

After that first experience, I kept going back to the field: NYC, Singapore, Afghanistan, Israel, UAE, Toronto, SF, Mumbai, and government deployments I can’t name. I spent hours in SCIFs working through data integrations across multiple networks. My laptop once overheated and nearly melted sitting in a car in the Middle East.

Each field experience taught me something new about the distance between building software and deploying it, about what happens when your code meets reality, about the difference between solving a problem in theory and solving it for a real human being who needs it to work right now.

I alternated between software engineering and forward deployed work for years, going back and forth between building and deploying. Each time I returned to product development, I built differently. I asked different questions and anticipated different failures. I understood, in a way I couldn’t have before, what the software was actually for.

That oscillation changed me. And I became convinced it could change others.

Why This Model Works

The Business Case

The business case is simple: software that actually gets adopted is worth infinitely more than software that sits on a shelf.

Most enterprise software fails to deliver value not because it doesn’t work technically, but because it never gets properly deployed, configured, adopted, and integrated into customer workflows. The industry’s dirty secret is that a huge percentage of enterprise software purchases end up as shelfware. Customers buy it, try to implement it, hit friction, and give up.

Companies with an FDE model don’t have this problem. Their software gets used because there’s an engineer on site making sure it gets used. Problems get solved in real time, configurations get tuned to actual workflows, and edge cases get handled before they become blockers.

This creates a flywheel: deployed software generates feedback, feedback improves the product, better products deploy more easily, easier deployment means more customers, and more customers means more feedback.

Palantir generates over $1.1 billion in annual revenue from just their top 20 customers. That’s not because the software is marginally better than competitors. It’s because Palantir engineers own customer outcomes in a way that traditional enterprise software vendors simply don’t.

The other reason companies want FDEs is that they’re the best source of product insight. Engineers who work directly with customers see things that product managers reading survey data never see. They understand the actual workflows, the real constraints, the true pain points. The best product ideas at Palantir came from FDEs who’d spent enough time in the field to understand what needed to be built.

One deployment I worked on had over fifty data pipelines running daily, and monitoring them was a nightmare. A few engineers who’d experienced this pain firsthand built a pipeline monitoring tool that got deployed across multiple sites. They didn’t build it because a PM told them to. They built it because they’d felt the problem themselves.

That’s the FDE advantage: engineers who build from experience, not from specs.

A Correction, Not a Trend

For a long time, the software industry optimized for building at scale while pushing deployment complexity onto customers and divorcing engineering from the business problems it was supposed to solve. The prevailing model was simple: throw it over the wall, let the customer figure it out, and hire systems integrators to clean up the mess.

This worked when software was simple and customers were patient, but neither of those things is true anymore.

The companies winning right now are the ones who own the full loop of building and deploying. They don’t hand off to SI firms or blame customers for implementation failures. They send engineers into the field who own outcomes, not just outputs.

Palantir figured this out twenty years ago and got criticized for it. The criticism was relentless: “It’s not scalable.” “It’s just consultants.” “It’s not a real software company.” Now everyone is trying to copy the model.

The problem is, you can’t hire your way to an FDE organization.

Building Frontline: The Program That Scaled It

To really understand FDE, you need to understand Frontline.

At the time, Palantir had two organizations that didn’t understand each other. Product Development (PD) built the software while Business Development (BD), which included the forward deployed engineers) put it in front of customers. The two groups were culturally and operationally separate, and that separation was causing real damage.

PD thought BD lacked technical rigor. BD thought PD lacked urgency. Deploying the product was painful, sometimes taking days or weeks. Engineers in the field drowned in problems that engineers in headquarters had never seen, while engineers in headquarters built features that solved the wrong problems because they’d never felt the pain of the people using their software.

The best way to understand someone is to walk a mile in their shoes. We decided to make that literal.

Project Frontline was born from this insight. Software engineers would spend time in the field doing a forward deployed rotation before formally beginning their product development work. They would see how the software actually got used, feel the pain of deployment, and understand viscerally the gap between what we built and what customers needed. Then they would come back and build differently.

I had the opportunity to lead Frontline alongside Palantir’s senior leadership: Matt Steckman, John Garrod, Bill Ward, Lynne Lu, and Randy Shultz. Shyam Sankar, Palantir’s now CTO, was directly involved, sitting in on our update meetings as we figured out what was working and what wasn’t. This wasn’t a side project. It was a strategic priority.

We learned quickly that throwing engineers into the field wasn’t enough. They needed support and structure. Every Frontliner got a mentor who had been through the experience, who could guide them through the disorientation of going from building software to deploying it. They got leads who checked in frequently, not just to track progress but to surface problems early. We created feedback loops throughout the rotation so that when someone was struggling, we caught it early, and when something wasn’t working, we heard about it fast.

We made mistakes along the way. The six month rotation timeline was supposed to be a guideline, but resourcing pressures sometimes stretched rotations to a year, and engineers felt stuck. There was friction between existing FDEs and the rotators, along with cultural clashes and different working styles.

We also discovered something crucial: often, the rotations weren’t connected to the products engineers would eventually build. Someone would spend six months deploying software they would never touch again. They learned valuable things, but the connection was abstract. So we started aligning rotations with future product work. If someone was going to build pipeline monitoring tools, we sent them to deployments where pipeline monitoring was a problem.

They became users before they became builders.

This was transformative. When engineers experienced the pain of problems they would later fix, something clicked. They built with emotion and passion, with a deep understanding of what users actually needed. You could feel it in the products. The software wasn’t just technically good; it was designed by people who cared, who had been there, who understood.

Over time, the program scaled. Over 250 engineers rotated through Frontline, and it stopped being an experiment and became the way things worked.

The proof is in what happened to the people who went through it. Frontline alumni are now at OpenAI, xAI, Helsing, Anduril, Hex, and dozens of other companies building important things. Bill Ward, who co-led Frontline, started Northslope Technologies, which offers FDE as a service. Jesse Rickard started Fourth Age, which does something similar. The model we built is now being replicated across the industry.

What Makes Someone Great at This

I’ve watched hundreds of engineers go through the FDE crucible. Some became exceptional while others washed out. Here’s what separates the great ones.

Great FDEs are relentlessly curious about the customer’s world. Good FDEs solve the problems they’re given, but great FDEs understand the customer’s business well enough to surface problems the customer had given up on or hadn’t yet articulated. In other words, as I said above, they become users before they become builders. I once spent a week at a customer site and noticed that every morning, an analyst spent 45 minutes manually downloading data from three different systems and combining them in Excel before she could start her actual work. She’d been doing this for two years and had never thought to ask if it could be automated. She’d just accepted it as part of her job. A good FDE would have built what she asked for. I built a pipeline that did her morning routine automatically and had it waiting in her inbox when she arrived. That’s the difference.

Great FDEs calibrate their engineering to the situation. They know when to build a robust system and when to write a script that just works. Here’s a failure story: early in my FDE career, a customer asked for a way to deduplicate records. I spent two weeks building an elegant, configurable deduplication engine with fuzzy matching, confidence scores, and a review interface. What they actually needed was a SQL query that ran once to clean up a specific data import. They never used the engine again. I’d overengineered by 10x. The opposite failure is equally painful: I once hacked together a “temporary” data deletion script that ended up running in production for eighteen months (vinoo.groovy, a name many of my old Palantir teammates still call me).

Great FDEs communicate across audiences. They can explain complex systems to executives who don’t care about the details and dive deep with technical counterparts who need to understand exactly how something works. In one meeting, I had to explain why a migration would take three months instead of three weeks. To the CTO, I said: “The data has 15 years of accumulated edge cases that will break downstream reports if we don’t handle them carefully. Rushing it risks the quarterly board reporting.” To the engineering lead, I said: “There are 847 columns across 12 tables with undocumented interdependencies, and the existing ETL has implicit type coercions that we need to preserve or we’ll get silent data corruption.” Same problem, different language.

Great FDEs stay calm when things break. And things will break. I remember a deployment where the customer’s CEO was demoing our product to their board when it crashed. My phone rang. Instead of panicking, I talked the customer’s IT person through restarting the service (which I knew would work because I’d diagnosed the root cause earlier that week), and the demo was back up in four minutes. The CEO never knew there was an engineer on the phone. How you handle a crisis matters as much as whether you fix it.

Great FDEs own outcomes without having authority. This is the hardest skill. Once, I needed a product team to prioritize a bug fix that was blocking a major customer. I had no authority over that team. What didn’t work: “Can you please prioritize this bug?” What did work: “This customer represents $4M in annual revenue and their renewal is in six weeks. They’ve told their exec sponsor that this bug is their top complaint. If we don’t fix it, we risk losing the renewal, and I can get you a call with the customer to hear it directly if that would help.” I got the fix in two days.

Great FDEs know when to push back. They don’t just do whatever customers ask. Once, a customer demanded we build a custom feature that would have taken three months of engineering time. Instead of saying yes or no, I spent two days understanding why they wanted it. It turned out they were trying to solve a problem that our existing product could handle with a configuration change. I showed them how to do it, and they were happier with that solution than they would have been with the custom feature. Pushing back isn’t about saying no. It’s about understanding the real need and finding the right solution.

The Palantir Singapore FDE team debugging an outage (h/t Satej Soman for the photo)

Why You Might Not Want This

I’ve spent this essay explaining why FDE is valuable. Now let me tell you why it might not be right for you.

If you need deep focus time, this isn’t your path. FDE work is interrupt-driven, with customers having emergencies and deployments hitting unexpected problems. Your calendar will look like that week I described above: chaotic, fragmented, constantly shifting.

If ambiguity paralyzes you, stay away. FDEs operate with incomplete information constantly. Requirements are unclear, priorities shift, and you have to make decisions without knowing if they’re right.

If you want to go deep on a technical specialty, look elsewhere. FDEs are generalists by necessity. You’ll learn a lot about a lot of things, but you won’t become a world expert in any of them. If your goal is to be the best in the world at distributed systems or machine learning, pure product engineering is a better path.

If you take customer frustration personally, you’ll burn out. Customers get frustrated and blame you for things that aren’t your fault.

If you can’t set boundaries, you’ll work yourself to death. FDE work expands to fill all available time. I’ve seen talented people burn out because they couldn’t say no.

These aren’t weaknesses; they’re just characteristics that make FDE a bad fit. There are plenty of great engineering roles for people who have them.

---

Hiring? We’d love to introduce you to great candidates. Email: hi@nextplay.so.

---

The Playbook

Manufacturing Your Own Field Exposure

Most of you reading this don’t work at a company with a Frontline program. Nobody is going to hand you this experience, so you have to create it yourself. Here’s exactly how to do it.

Week 1-2: Get on customer calls. Email your PM or customer success lead today with this exact message: “I want to understand our customers better so I can build more robust features. Can I sit in on 2-3 customer calls over the next few weeks? I’ll be on mute, just observing.” Almost no one will say no to this. On the calls, don’t take notes on feature requests. Take notes on these things: What does this person’s day look like? What did they do before this call? What will they do after? What do they seem frustrated by that they’re not explicitly complaining about? What workarounds are they using?

Week 3-4: Shadow support or implementation. Find whoever handles customer escalations or implementations at your company. Ask to shadow them for three days. If you work remotely, ask to be added to their Slack channels and get on video calls with them when issues come in. Watch how problems get diagnosed. Notice the gap between what customers say is wrong and what’s actually wrong. Pay attention to which parts of your product cause the most confusion.

Month 2: Take an escalation. When a customer issue comes in, volunteer to own it end-to-end. Not just fix the bug, but talk to the customer, understand the impact, communicate the timeline, deploy the fix, and confirm it’s resolved. This is the full loop. It will be uncomfortable. You will learn more from this one experience than from months of normal development work.

Month 3: Visit a customer site (or do a deep-dive remote session). If your company has customers you can visit, ask to join a site visit. If not, ask if you can do a 2-hour screen-share session with a customer where you watch them use the product for their actual work, not a demo, not a training session, their actual job. While you’re watching, identify one papercut you can fix in under a day. Then fix it and ship it before the week is over. Tell them you did it. This builds trust and goodwill like nothing else.

Month 4-6: Build your feedback loop. By now you should have enough context to start seeing patterns. Create a simple document titled “What I’ve Learned From Customers” and update it weekly. Share it with your product team. Include specific quotes, specific workflows, specific pain points. This document will make you invaluable. It will also prepare you for FDE interviews, where you’ll need to demonstrate customer empathy.

Developing the Six Traits

Curiosity is really about empathy. It develops when you force yourself out of the codebase and into the customer’s environment. The next time you’re on a customer call or a site visit, don’t just listen for feature requests. Try to understand the customer’s day: what are they doing before they open your software, what are they doing after, and what are the three things keeping them up at night that have nothing to do with your product?

Calibration comes from getting it wrong in both directions. You need both scars. Deliberately vary your approach: on your next project, try solving it with the simplest possible thing, and on the one after, try building it properly. Pay attention to which approach the situation actually called for.

Communication is a muscle you have to exercise. Think of it like the game of telephone: every time a message passes through another person, it degrades. FDEs short-circuit that chain. Practice writing one-page summaries of technical projects for non-technical stakeholders. If you can’t explain what you built and why it matters in one page without jargon, you don’t understand it well enough.

Staying calm is about preparation and repetition, not personality. Put yourself in high-pressure situations voluntarily: volunteer for the on-call rotation, take the escalation, join the war room when production is down. By the tenth time, you’ll have a playbook in your head.

Owning outcomes without authority develops when you put yourself in situations where you need something from someone who doesn’t report to you. Learn to make requests that explain the why, not just the what.

Pushing back effectively runs on credibility. Think of credibility as points you can spend or lose. Early on, pick your battles carefully. The key is to always push back with an alternative, not just a no.

What You Should Actually Know Technically

FDEs are generalists, but that doesn’t mean you can be shallow on everything. Here’s the specific technical knowledge you need.

The XY Problem. Customers will ask you for Y when what they actually need is a solution to X. Practice by asking “what are you trying to accomplish?” before jumping to solutions.

SQL. JOINs, GROUP BY with HAVING, window functions, CTEs, subqueries. Target: write a query that finds “the second-highest value per category” without Googling. Data is objective and data analysis is your lifeblood.

Command line and Linux. Navigating the filesystem, reading logs (grep, awk, tail -f), understanding processes (ps, top, kill), basic networking (curl, netstat, ping, traceroute). Know what “out of inodes” means. Resource: OverTheWire Bandit.

Containers. What Docker does, difference between container and VM, where logs go. What Kubernetes does at a high level. Resource: Docker’s getting started guide.

Networking. DNS, HTTP status codes, TLS/SSL basics, debugging when you can ping but can’t connect. Resource: Julia Evans’ zines.

Python scripting. Read a CSV, transform data, write it somewhere. Call an API, handle pagination. Connect to a database. Be fast. Resource: Automate the Boring Stuff with Python.

Data quality. What happens with timezone mismatches, encoding issues, unexpected nulls. The Cassandra story I told? That’s a data quality issue.

Getting Hired: What Interviewers Actually Ask

FDE interviews are heavy on behavioral questions because the job is about judgment, not just technical skill.

“Tell me about a time you had to work with a difficult customer.” Bad: “The customer was being unreasonable, but I stayed calm and eventually they came around.” Good: “The customer was frustrated because our product had lost their data. They were angry, and honestly, they had a right to be. I started by acknowledging that we’d screwed up, not making excuses. Then I explained exactly what had happened, what we were doing to recover the data, and what we were doing to make sure it never happened again. I also gave them my cell phone number and told them to call me directly if anything else went wrong. It took two weeks, but by the end they renewed their contract.”

“Tell me about a time you disagreed with a customer’s request.” Bad: “The customer wanted something that didn’t make sense, so I explained why they were wrong.” Good: “The customer wanted us to build a custom dashboard that would have taken a month of engineering time. Instead of saying no, I asked them to walk me through exactly how they’d use it. It turned out they needed to answer a specific question for a weekly meeting. I showed them how to get that answer with our existing product plus a 10-minute SQL query. They were actually happier with that solution because they got it that day instead of waiting a month.”

“Tell me about a time something broke in production.” Bad: “Our service went down, and I fixed it.” Good: “I was on-call when our main API started returning 500 errors. First, I checked monitoring to understand scope: 30% of requests, not all. That told me it probably wasn’t new code. Error logs showed database connection timeouts. Database was at 100% CPU. Slow query log showed a full table scan on 50 million rows from a feature that launched that morning. I disabled the feature, fixed the API, then worked with the team to add an index. Whole thing took 45 minutes. Next day we implemented query review for large tables.”

Technical questions focus on debugging and practical coding:

• “How would you debug a slow API endpoint?” (Walk through: monitoring, logs, profiling, database queries, external dependencies)

• “Write a script that processes this data.” (Messy data problem. Handle edge cases. Python.)

• “Explain X to me like I’m not technical.” (DNS, database indexing, rate limiting. No jargon.)

Your First 90 Days

Days 1-30: Learn. Absorb context. Meet everyone. Read all documentation. Shadow every call. Build a glossary. Write down three things you learned each day. Don’t try to add value yet. The most common failure mode is engineers who come in hot with opinions before they understand the environment.

Days 31-60: Find your first win. One small thing you can own completely. A script that automates manual work. A bug fix that’s been annoying customers. A dashboard replacing a spreadsheet. Something with a clear before and after. Ship it. Tell people.

Days 61-90: Start forming opinions. Now you have context and credibility. Engage harder problems. Propose solutions. Be humble—three months in, you’re still a beginner. But you’re a beginner with context.

Traps to avoid:

• Overengineering. I once saw a new FDE spend three weeks building a “robust, scalable” solution for a problem that needed a bash script. The customer cared about getting the answer by Friday.

• Retreating into code. When a meeting gets tense, your instinct is to hide behind your laptop. Don’t. Stay present.

• Overpromising. Underpromise and overdeliver. “Done by Wednesday” when you finish Tuesday beats “Done by Monday” when you finish Wednesday.

• Solving the wrong problem. “What are you trying to accomplish?” is the most important question in an FDE’s toolkit.

The Career Path

Year 1: Learn. Absorbing context, building relationships, developing judgment. Handling individual customer problems. Success: customers trust you, team relies on you for insights, you’ve shipped things that made a real difference.

Year 2-3: Lead. Owning larger customer relationships or leading small teams. Making prioritization decisions. Mentoring newer FDEs. Success: turned around a struggling customer relationship, shaped the product roadmap, people come to you when they don’t know what to do.

Year 4+: Multiply. Going deep (domain expert) or going broad (leading an FDE org, product leadership, starting a company). Many FDEs become founders because they have both technical skills and customer understanding. Others become product leaders. Some stay as senior FDEs handling the most complex deployments.

Frontline alumni have become founders of AI companies, heads of product at public companies, and engineering leaders at defense contractors. The FDE skill set is rare and valuable in almost any technical leadership role.

Resources

Companies hiring FDEs: Palantir, Anduril, OpenAI, Anthropic, Scale AI, Helsing, Hex, Databricks, Weights & Biases

FDE-adjacent: FDE as a service companies, defense tech startups, vertical SaaS with complex deployments, AI companies with enterprise customers

What to read:

• Palantir’s S-1 filing (deployment methodology section)

• Shyam Sankar’s blog - https://www.shyamsankar.com/

• “The Mom Test” by Rob Fitzpatrick - https://www.momtestbook.com/

• Julia Evans’ blog and zines - https://jvns.ca/

The Path Forward

The grey track jacket was just a symbol. What it represented was something deeper: the transformation that happens when you stop building software in a vacuum and start building it for real people, with real problems, in the real world.

That transformation is available to you whether or not you work at Palantir. It requires putting yourself in the field, feeling the pain of deployment, and understanding what customers actually need. It requires going through something that changes you.

The field is where the real education happens. Everything else is just preparation.