Der perfekte Leitfaden für die Einstellung von Forward Deployed Engineers (FDEs)

• Forward Deployed Engineers (FDEs) werden direkt beim Kunden vor Ort eingesetzt und setzen die „letzte Meile“ technisch komplexer Produkte um
• Sie sind nicht bloß Consultants, sondern Entwickler, die echten Production-Code schreiben, debuggen und neue Produktchancen identifizieren
• Dieses Modell eignet sich nicht für jedes Unternehmen und ist nur dann wirksam, wenn drei Bedingungen erfüllt sind: große Vertragskunden, ein nicht standardisiertes ICP und eine offene Haltung zur Produktausrichtung
• Die besten FDEs sind meist Talente in einer frühen Karrierephase mit unabhängigem Denkvermögen, Ausdauer, hoher technischer Stärke und geschäftlicher Neugier – Menschen, die sich nicht auf bestehende Playbooks verlassen
• Beim Betrieb eines FDE-Teams ist entscheidend, sich auf die schwierigsten Probleme der größten Kunden zu konzentrieren und Vor-Ort-Einsatz mit gutem Scope-Management zu verbinden

---

Ursprung und Gegenwart des FDE

• Palantir-Mitgründer Alex Karp entwickelte die Rolle des Forward Deployed Engineer (FDE) vor rund 20 Jahren erstmals, inspiriert von der Beobachtung in einem französischen Restaurant, dass Kellner eine Verlängerung des Küchenteams sind
• FDEs werden direkt beim Kunden eingesetzt und bauen die „letzte Meile“ des Produkts in der Production-Umgebung; anders als klassische Solution Consultants oder Sales Engineers schreiben und debuggen sie echten Production-Code
• Lange gab es Skepsis, ob das nicht „nur High-End-Consulting“ sei, doch nach dem Überschreiten einer Marktkapitalisierung von 300 Milliarden US-Dollar bei Palantir wurde das Interesse an dieser Rolle neu entfacht
• Zwischen Januar und September 2025 stiegen Stellenausschreibungen für FDEs um 800 %, und AI-Startups einschließlich OpenAI bauen FDE-Teams auf, um Enterprise Sales zu stärken

Wo FDEs Wert schaffen

• FDEs sind nicht bloß für die Implementierung da, sondern vollwertige Mitglieder des Software-Engineering-Teams; sie sprechen täglich mit Kunden und müssen selbst Software bauen
  • Die FDEs von Serval haben tatsächlich mehr als 60 Drittanbieter-App-Integrationen, ein Feedback-System für Agent-Performance, ein SLA-System und mehr als Produkt umgesetzt
• Das Aufgabenspektrum von Palantir-FDEs reicht von der Senkung von Ausschussquoten in der Fertigung bis zur Auslieferung von Software für die Verwaltung von Hilfsgütern bei Naturkatastrophen

• Unterstützung beim Abschluss großer Verträge

  • Looker nutzte FDEs im Vertrieb, indem potenziellen Kunden kostenlose Trials mit echten Daten und starke Pre-Implementation-Unterstützung angeboten wurden
    • Mitgründer Lloyd Tabb: „Dass wir uns nicht zwischen Produkt und Service entschieden haben, eröffnete einen dritten Weg. Wir verkauften es als Produkt, deployten aber während der kostenlosen Testphase forward, sodass es sich wie ein maßgeschneiderter Service anfühlte.“
    • Statt Demo-Dummys wurden PoCs immer mit den echten Datensätzen potenzieller Kunden gebaut
  • Auch bei Palantir gab es Fälle, in denen drei bis vier FDEs für Kunden aus dem Energiesektor ohne Roadmap oder Freigabe aus dem Headquarter direkt lösungsspezifische Software bauten und damit den Vertragsabschluss ermöglichten

• Produktchancen durch Einbettung beim Kunden identifizieren

  • Tiefe Insights, die in einem 30-minütigen Zoom-Call kaum zu gewinnen sind, lassen sich durch Vor-Ort-Einbettung entdecken
    • „Im Feld mit dem Kunden zu leben, ist der Kern des FDE. Es geht nicht darum, User-Interviews aufzusetzen, sondern darum, das am Tag Gehörte zu prototypen und es am nächsten Tag zu zeigen.“
  • Einige der erfolgreichsten FDE-Fälle entstanden bei Palantir in Bereichen, die nichts mit dem Kernprodukt zu tun hatten
  • Gleichzeitig besteht das Risiko, dass FDEs beliebig Features bauen, die nichts zur Verbesserung des Kernprodukts beitragen; daher braucht es Produktgespür, um Probleme zu identifizieren, die auch für andere Kunden relevant sind

• Die Energie früher Gründer skalieren

  • Das FDE-Modell ist ein Weg, die frühe Gründerenergie zu reproduzieren und zu skalieren, bei der ein CTO direkt Kundenfeedback hört und es sofort in Code umsetzt
    • Bei Serval ist der Unterschied zwischen FDEs und normalen Engineers gering; FDEs verbringen etwa 20 % ihrer Zeit mit Kunden und konzentrieren sich auf den Aufbau von Produktfähigkeiten statt Infrastruktur
  • In traditionellen Feedback-Produkt-Zyklen vergehen von Solution Engineer über PM bis hin zum Engineering Manager und Sprint-Planung oft mehrere Monate; das FDE-Modell entfernt diese Zwischenstufen

• Funktionen mit niedriger Priorität abarbeiten

  • FDEs können Feature-Requests auf P2-Niveau, die in der Roadmap ständig nach hinten geschoben werden, tatsächlich umsetzen
    • Bei Verkada sammelte das Sales-Team Kundenanfragen in einem Slack-Channel namens „Feature Garage“, doch die meisten blieben liegen
  • „Wenn sich P2s immer weiter stapeln, erhält man am Ende ein unterlegenes Produkt, selbst wenn man sich technisch nur auf das Richtige konzentriert. Im FDE-Modell werden auch P2s tatsächlich geprüft.“

Selbstcheck vor der Einführung von FDEs

• Die Investition in ein FDE-Team ist vor allem für frühe Startups teuer; wenn die Mathematik des Geschäftsmodells nicht aufgeht, kann sehr schnell Kapital verbrannt werden
• Looker-CEO Frank Bien entschied sich erst dann für Investitionen in FDEs, nachdem das Modell bestätigt war, mit 2.000 Kunden 100 Millionen US-Dollar ARR erreichen zu können
  • „Wenn man das Modell vollständig versteht, kann man rechnerisch prüfen, ob man jede eingesetzte Ressource tragen kann. Aber wenn unklar gewesen wäre, ob man für 100 Millionen US-Dollar 2.000 oder 100.000 Kunden braucht, dann hätten wir nur VC-Geld verbrannt.“

• Bedingung 1: Große Kunden gewonnen haben oder gezielt ansprechen

  • FDE ist im Kern eine Upmarket-Strategie; wenn das Endmodell ein PLG-Premium-Modell ist, passt FDE nicht
  • Ironclad verstand früh, dass Rechtsabteilungen großer globaler Unternehmen die idealen Kunden sind, und führte FDEs ein, weil für hohe Enterprise-ACVs maßgeschneiderte Implementierungen nötig waren

• Bedingung 2: Keine starke Meinung dazu haben, wie das Produkt genutzt werden soll

  • Wenn ein Unternehmen eine starke Vorstellung davon hat, wie sein Produkt künftig aussehen soll, sind eher PMs oder kundennahe Engineers geeignet als FDEs
  • Am einen Ende des Spektrums steht Apple (für alle Nutzer dieselbe Experience), am anderen Palantir (eine verformbare Plattform für viele unterschiedliche Probleme und Organisationen)
    • In Palantirs Anfangszeit wurde kaum gesagt: „So muss das Produkt aussehen“; stattdessen lernten FDEs aus konkreten Use Cases und Kunden und bauten schrittweise ein wertvolles Produkt auf

• Bedingung 3: Das ICP ist nicht homogen

  • Wenn die Kundendefinition sehr detailliert und einheitlich ist, sinkt der Bedarf an einem FDE-Team
  • Die ersten 50 Kunden von Ironclad hatten kaum Gemeinsamkeiten: börsennotierte Tech-Unternehmen, YC-Startups, globale Beauty-Marken, Profi-Sportteams usw.
    • Die Anforderungen an einen japanischsprachigen Workflow für Influencer-Verträge und an Verträge für den Verkauf von MLB-Saisontickets waren völlig unterschiedlich
  • Promise hat US-Behörden als Kunden und baut wegen der heterogenen Kundenlandschaft ein FDE-Team auf, da jeder Bundesstaat Programme anders betreibt

• FDEs nicht gewaltsam in Engineering- oder Post-Sales-Rollen pressen

  • Viele Gründer sagen, sie wollten FDEs, brauchen in Wirklichkeit aber eher reguläre Software Engineers oder Implementierungs-Consultants bzw. CSMs
  • Verifizierungsfragen, die Tiffany Siu von First Round empfiehlt:
    • „Was war der Auslöser dafür, diese Position zu öffnen? Wer macht diese Arbeit aktuell? Was passiert, wenn wir diese Person nicht einstellen?“
    • „Wie sieht der Arbeitsalltag dieser Person konkret aus?“
    • „Was sind die Erfolgsmetriken dieser Person?“
  • „Wenn man möchte, dass FDEs X Deals closen oder X Demos durchführen, dann braucht man keinen FDE, sondern eine vertriebsnahe Rolle.“

Wie man passende FDEs einstellt

• Es ist nicht nötig, sich darauf zu versteifen, jemanden mit bereits bestehendem FDE-Titel zu finden. Da die Rolle je nach Unternehmen unterschiedlich strukturiert ist, sollte man mehr auf die tatsächliche Arbeit als auf den Titel achten

• Fünf Eigenschaften, die die besten FDEs gemeinsam haben

  • Menschen, die sich nicht auf Playbooks verlassen (frühe Karrierestufe ist von Vorteil): Bei Palantir machten Berufseinsteiger einen großen Teil der FDEs aus. Geeignet sind unabhängige Denker, die nicht in Mustern abgleichen, sondern überzeugt sind, jedes Problem lösen zu können
    • Kandidaten mit übermäßig festgefahrenen Arbeitsweisen, etwa nach mehr als 10 Jahren bei FAANG, sind eher ein Warnsignal
  • Grit: FDE-Arbeit bewegt sich in extrem schwierigen Problemräumen, daher ist die „Bereitschaft, Schmerz auszuhalten“ essenziell. Die besten FDEs von Ironclad wurden ebenfalls als „Grinder“ beschrieben
    • FDEs übernehmen intern die Rolle von Mini-Gründern und brauchen starkes Produktgespür sowie echtes Interesse am Vertrieb
  • Hohe technische Standards: Die besten FDEs bei Ironclad hätten auch Staff Engineers bei Top-Tech-Unternehmen sein können. Bei Palantir mussten FDEs denselben Interviewprozess wie Software Engineers bestehen
  • Ständiger Drang zu bauen: Die besten FDEs sind „zwanghafte Builder“, die ständig etwas erschaffen müssen – Tools bauen, Apps launchen, zu Open Source beitragen
  • Tiefe Neugier auf das Geschäft: Menschen, die sich etwa tief in rechtliche Risiken des Influencer-Marketings hineinarbeiten und Energie daraus ziehen, zu verstehen, wie das Business selbst funktioniert

• Interview-Design

  • Palantir setzte statt klassischer Coding-Interviews großer Tech-Unternehmen auf Interviews mit Fokus auf hochrangige Problemlösung anhand realer Kundenprobleme
    • Beispiel: Nach einer Erklärung zu Insiderhandel Fragen wie „Welche Daten wären nötig, welche Fragen würden Sie dem Kunden stellen und wonach würden Sie suchen?“ – es werden sowohl geschäftliche als auch technische Schlussfolgerungen bewertet
  • Ironclad nutzt offene Präsentationsinterviews, in denen Kandidaten ein Problem aus ihrer bisherigen Laufbahn vorstellen und erklären sollen, wie sie es technisch gelöst haben
    • Ein typisches Beispiel war das Zeigen von Fotos eines physischen „Deal Room“ für Flugzeugfinanzierungstransaktionen mit Tausenden Seiten und Klebezetteln sowie eines späteren Excel-Makros, das dies automatisierte

Scope der FDE-Rolle: Drei Taktiken, um das erste FDE-Team wirkungsvoll einzusetzen

• FDEs auf die schwierigsten Probleme der größten Kunden ansetzen

  • Ironclad schickte anfangs zu jedem Kunden FDEs, wechselte mit dem Wachstum aber zu einem Modell, bei dem nur Kunden mit hohem ACV FDEs zugewiesen bekommen
    • Es geht nicht um „entweder vollständiges FDE-Unternehmen oder gar nicht“, sondern darum, verschiedene Menüoptionen je nach Kundenbedarf zu systematisieren und Implementierungen im unteren Marktsegment zu standardisieren
  • Auch Serval deployte anfangs bei allen Kunden, setzt FDEs heute aber vorrangig bei großen Kunden ein, etwa Unternehmen mit mehr als 1.000 Mitarbeitenden

• Die Bedeutung des Vor-Ort-Einsatzes

  • FDEs erzielen vor Ort ihre besten Ergebnisse. So können sie über die im Vertrag festgehaltene Anforderungsliste hinausgehen und durch gemeinsame Alltagserfahrung Dinge entdecken, die nie im Vertrag standen
    • Die Kultur der Vor-Ort-Besuche von Ironclad-FDEs ist so bekannt, dass Fortune-100-Chefsyndizi sie „The Backpacks“ nennen

• Ein ausgewogener Umgang mit Scope Creep: akzeptieren, aber nicht „Produktprobleme mit menschlicher Arbeit überdecken“

  • Man sollte den serviceartigen Charakter der FDE-Rolle akzeptieren, aber vermeiden, endlos Zeit in Lösungen zu investieren, die künftigen Kunden keinen Nutzen bringen
  • In der Frühphase von Ironclad wurde Scope Creep als Signal verstanden, dass Kunden noch mehr lösbare Probleme haben; dank workflowbasierter Preisgestaltung profitierte die Software-Ökonomie dort sogar von wachsendem Scope
  • Schlechter Scope Creep liegt vor, wenn in Workflows mit begrenzter Nutzerzahl endlos wiederkehrende Arbeit anfällt; wenn kein Software-Upside erkennbar ist, sollte die Arbeit gestoppt werden
  • Echte FDEs sind so stark auf Problemlösung fokussiert, dass sie oft nicht einmal merken, wenn sie über den Vertragsumfang hinausgehen – Scope-Management ist deshalb Aufgabe der Manager