Originally published on Next Play

The Bottom Line

A Forward Deployed Engineer (FDE) is a software engineer who owns customer outcomes - not just satisfaction scores or relationships, but actual results customers achieve with the software. This distinction fundamentally changes everything about how engineers approach their work.

The critical insight is that you cannot easily hire your way to a true FDE organization. This skill set is too rare and specific, dependent on experiences most engineers never have. Traditional engineering roles insulate engineers from customer reality. The only way to build an FDE organization is to take talented people and put them through experiences that transform how they think about building software.

Why This Matters Now

Three forces are making the FDE model increasingly standard:

First, AI is making deployment harder. AI systems require fine-tuning, prompt engineering, evaluation, and ongoing adjustment. You cannot simply deploy an LLM and expect customers to figure it out. Companies like OpenAI, Anthropic, and xAI are building FDE-style functions, even if they use different terminology.

Second, defense tech is exploding. Companies like Anduril and Palantir build software for military and government customers who cannot tolerate deployment failure. These customers operate in austere environments with unique constraints that require engineers in the field, not helpdesk support.

Third, enterprise buyers are getting smarter. After decades of expensive software sitting unused, enterprises are demanding implementation guarantees and want to see engineers on site who own deployments, not just sales.

The Personal Transformation

While working in product development, I built “Phoenix,” a system with clean architecture and good test coverage. When deployed, it failed catastrophically.

The system relied on a data integration that generated Apache Cassandra keyspaces in 10-minute increments. When bad data arrived with empty date columns, the system interpreted this as the Unix epoch (January 1, 1970) and created keyspaces for every 10-minute interval between 1970 and 2013 - approximately 2.3 million keyspaces. This required roughly 14 terabytes of RAM just to start up. The system crashed immediately.

I realized the fundamental problem: the team had never seen the actual data our system would process. We had never been in the room when garbage data arrived at 2 AM. We had never looked a customer in the eye and explained why a system they depended on was suddenly unresponsive.

After this experience, I alternated between software engineering and field deployments across NYC, Singapore, Afghanistan, Israel, UAE, Toronto, and government locations. Each rotation taught me the distance between building software and deploying it in reality.

Project Frontline: How to Scale FDE Culture

Palantir had a cultural problem: Product Development (PD) and Business Development (BD) were separate organizations that did not understand each other. PD thought BD lacked technical rigor. BD thought PD lacked urgency.

Project Frontline solved this by sending software engineers into the field for rotations before they began formal product development work. Engineers would see how software actually got used, feel the pain of deployment, and understand the gap between what they built and what customers needed. Then they would return and build differently.

The program required structure and support. Every engineer got a mentor who had been through the experience. Leaders checked in frequently. Feedback loops surfaced problems early. The program made mistakes - six-month rotations sometimes stretched to a year, causing frustration. Cultural clashes between existing FDEs and rotators created friction.

A crucial evolution occurred when the company started aligning rotations with future product work. If an engineer would eventually build pipeline monitoring tools, they were sent to deployments where pipeline monitoring was a major pain point. Engineers became users before they became builders. When people experienced the pain of problems they would later fix, something transformed. They built with emotion and passion, with genuine understanding of what users needed.

Over time, more than 250 engineers rotated through Frontline. The program stopped being an experiment and became how the organization worked. Alumni are now at OpenAI, xAI, Helsing, Anduril, Hex, and dozens of other important companies.

What Makes Great FDEs

Relentless curiosity about the customer’s world. Good FDEs solve stated problems. Great FDEs understand the customer’s business deeply enough to surface problems customers had given up on or never articulated. One example: an analyst spent 45 minutes every morning manually downloading data from three systems and combining them in Excel. She had done this for two years without mentioning it. A great FDE noticed, built a pipeline that automated her morning routine, and had the results waiting in her inbox when she arrived.

Calibration of engineering to the situation. Great FDEs know when to build robust systems and when to write a script that just works. Over-engineering wastes time. Under-engineering creates technical debt.

Communication across audiences. FDEs must explain complex systems to executives who do not care about details and dive deep with technical counterparts who need exact specifications. The same problem requires different language for different audiences.

Staying calm when things break. Systems will fail. When the customer’s CEO was demoing the product to their board and it crashed, an engineer diagnosed the issue, talked IT through restarting the service, and had it back up in four minutes. The CEO never knew there was an engineer on the phone.

Owning outcomes without authority. FDEs must often get things done without direct authority. This requires making requests that explain the why, not just the what. Instead of “Can you prioritize this bug?” a better approach is “This customer represents $4M in annual revenue and their renewal is in six weeks. They’ve told their exec sponsor this bug is their top complaint. If we don’t fix it, we risk losing the renewal.”

Pushing back effectively. FDEs do not just do whatever customers ask. Once, a customer demanded a custom feature that would have taken three months. An FDE spent two days understanding the real need and discovered the customer could achieve their goal with an existing product feature plus a configuration change. They got what they needed faster and better.

Why You Might Not Want This

FDE work is interrupt-driven with chaotic calendars and constantly shifting priorities. If you need deep focus time, this is not your path.

If ambiguity paralyzes you, stay away. FDEs operate constantly with incomplete information, unclear requirements, and shifting priorities.

If you want to go deep on a technical specialty and become the world expert in distributed systems or machine learning, pure product engineering is a better path. FDEs are generalists by necessity.

If you take customer frustration personally, you will burn out. Customers get frustrated and blame you for things outside your control.

If you cannot set boundaries, you will work yourself to exhaustion. FDE work expands to fill all available time.

These are not weaknesses - just characteristics that make FDE a bad fit for some people.

The Playbook: How to Become an FDE

Weeks 1-2: Get on customer calls. Email your PM or customer success lead requesting to observe 2-3 customer calls. Take notes not on feature requests, but on the customer’s day, their frustrations, their workarounds.

Weeks 3-4: Shadow support or implementation. Spend three days watching how customer escalations and implementations are handled. Notice the gap between what customers say is wrong and what is actually wrong.

Month 2: Take an escalation. Own a customer issue end-to-end: understand the problem, diagnose the root cause, fix it, deploy it, and confirm resolution. This is the full loop.

Month 3: Visit a customer site. Watch them use your product for their actual work, not a demo or training. Identify one small thing you can fix in under a day. Fix it and ship it before the week ends. Tell them what you did.

Months 4-6: Build your feedback loop. Create a document titled “What I’ve Learned From Customers” and update it weekly. Share it with your product team. Include specific quotes, workflows, and pain points.

Technical Knowledge FDEs Actually Need

FDEs are generalists, but not shallow on everything:

  • SQL: JOINs, GROUP BY with HAVING, window functions, CTEs, subqueries
  • Command line and Linux: File navigation, reading logs (grep, awk, tail -f), understanding processes (ps, top, kill), basic networking (curl, netstat, ping)
  • Containers: What Docker does, container versus VM differences, log locations, Kubernetes basics
  • Networking: DNS, HTTP status codes, TLS/SSL basics, debugging connectivity issues
  • Python scripting: Reading CSVs, transforming data, calling APIs with pagination, database connections
  • Data quality: Timezone mismatches, encoding issues, unexpected nulls, silent data corruption

FDE Interviews: What Interviewers Actually Ask

“Tell me about a time you had a difficult customer.” Good answers acknowledge when the company screwed up, explain exactly what happened, describe what was being done to fix it, and show personal accountability.

“Tell me about a time you disagreed with a customer’s request.” Rather than explaining why customers were wrong, great answers show how you investigated the underlying need and found a better solution.

“Tell me about a time something broke in production.” Excellent answers walk through diagnosis systematically (checking monitoring, reading error logs, profiling, identifying the root cause), show the fix, and explain prevention for the future.

Your First 90 Days

Days 1-30: Learn. Absorb context. Meet everyone. Read documentation. Shadow calls. Build a glossary. Write down three things learned daily. Do not try to add value yet. The most common failure mode is engineers who arrive with opinions before understanding the environment.

Days 31-60: Find your first win. Own something completely. A script that automates manual work, a bug fix that has annoyed customers, a dashboard replacing a spreadsheet. 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 are still a beginner.

Traps to avoid:

  • Overengineering solutions
  • Retreating into code when meetings get tense
  • Overpromising and underdelivering
  • Solving the wrong problem

The Career Path

Year 1: Learning context, building relationships, developing judgment. Handling individual customer problems. Success means customers trust you, the team relies on you for insights, and you have shipped things that made real differences.

Years 2-3: Leading larger customer relationships or small teams. Making prioritization decisions. Mentoring newer FDEs. Success means turning around struggling relationships, shaping product roadmaps, and becoming someone people turn to when they do not know what to do.

Year 4+: 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 deep customer understanding.

Why the Grey Track Jacket Matters

At Palantir, everyone received a black track jacket. But there was another jacket - grey - that you could not buy or request. The mythology was that your black jacket had faded through years of experience, that you had worn it through enough deployments and hard field work that the black had burned away and become grey.

When I received my grey jacket, I did not feel pride or accomplishment. I felt the weight of what it represented: late nights, systems that failed, customers who depended on me when things went wrong. The jacket was not a trophy. It was acknowledgment that you had been through something, and that something had changed you.

The jacket was just a symbol. The transformation is what matters.