Anthropic-Ingenieur hält eine Einführung in FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ

Kevin Bai ist heute im Applied-AI-Team von Anthropic tätig. Davor war er Gründungsmitglied des FDE-Teams bei Rippling, und noch davor arbeitete er mehrere Jahre bei Palantir. Kürzlich hat er einen FDE-101-Share gemacht und erklärt sehr klar, wie die Rolle des „Frontline Deployment Engineers“ funktioniert – das lohnt sich, zusammenzufassen.

Zuerst ein Fakt: In börsennotierten SaaS-Unternehmen, geordnet nach durchschnittlichem Vertragswert, liegt Palantir bei 4 Millionen US-Dollar, ServiceNow bei 1,2 Millionen, Workday bei 0,6 Millionen. Bei den übrigen schafft es keine Firma über 0,5 Millionen. Palantir erreicht mit nur ein paar tausend Leuten einen durchschnittlichen Kundenwert, den andere mit mehreren zehntausend nicht hinbekommen. Das liegt an dem FDE-Modell.

Worum genau geht es bei FDE?

Palantirs Produkt Foundry ist eine Plattform zum Erstellen von Anwendungen. Die technischen Einstiegshürden sind hoch, aber die Käufer sind nicht-technische Führungskräfte – zum Beispiel aus Branchen wie Öl und Konsumgütern. Wenn man eine komplexe technische Plattform einem Menschen gibt, der nicht programmieren kann, und erwartet, dass er sich ganz allein erschließt, wie man sie nutzt, ist das unrealistisch.

Daher macht Palantir Folgendes: Der Kunde kauft weder ein Softwareprodukt noch eine Beratungsleistung, sondern „ein Ergebnis“. Du entsendest Ingenieure dorthin, verstehst die konkreten Geschäftsszenarien des Kunden im Detail und baust ihnen auf der Plattform die entsprechenden Dinge. Der Kunde interessiert sich dafür, wie viele zusätzliche Produkte jetzt im Regal stehen oder wie stark sich die Effizienz in der Produktionslinie verbessert hat. Wie die Daten organisiert sind, interessiert ihn nicht – und das muss ihn auch nicht interessieren.

Was unterscheidet FDE von ausgelagerter Entwicklung?

Kevin betont besonders einen Punkt: Wenn deine Ingenieure bei jedem Kundenprojekt jedes Mal von Null an maßgeschneiderte Codes schreiben, dann machst du kein FDE, sondern ausgelagerte Entwicklung. Das FDE-Modell funktioniert nur, wenn du eine wiederverwendbare Plattform hast. Die Ingenieure setzen die Lösung aus bestehenden, bereits vorhandenen Fähigkeiten der Plattform zusammen und passen sie an – sie bauen bei jedem Mal das Rad neu. Ohne Plattform werden die Wartungskosten jeden Profit auffressen, und die Ingenieure werden auch weggehen, weil sie am Ende dutzende völlig unzusammenhängende Codebasen pflegen müssen.

Sollte man FDE machen? Zwei Fragen reichen aus.

Erstens: Muss man ein technisch komplexes Produkt an nicht-technische Käufer verkaufen? Wenn deine Kunden selbst Ingenieure sind – etwa bei GitHub oder Datadog – dann braucht man kein FDE. Wenn dein Produkt ohnehin „out of the box“ nutzbar ist – etwa Slack oder Jira – ebenfalls nicht. Nur wenn dein Produkt sehr komplex ist und der Kunde mit Technik nichts anfangen kann, wird FDE sinnvoll.

Zweitens: Hast du eine wiederverwendbare Plattform – oder bist du bereit, dafür zu investieren? Ohne geteilte Basiskomponenten ist FDE nicht nachhaltig.

Welche neuen Veränderungen gibt es im Jahr 2026?

Kivins Einschätzung ist spannend: Die Art und Weise, wie man im Softwaregeschäft Geld verdient, hat sich selbst verändert. Durch KI wird das Bauen von Software extrem einfach, und fast alle Plattformen gehen in Richtung „Agent“-isierung. Das bedeutet, dass nahezu alle Plattformen hochgradig anpassbar werden. Die Folge ist: Immer mehr Kunden können nicht mehr richtig einschätzen, was dein Produkt tatsächlich leisten kann. Wenn du das Gelingen oder Scheitern deines Produkts dem Kunden überlässt, der es sich in der Agent-Ära erst selbst „zusammenbasteln“ muss, wird es immer schwerer, den Weg dorthin erfolgreich zu gehen.

Damit wird FDE von einer exklusiven, kleinen Spezialität von Palantir zu einer Frage, die sich mehr Softwarefirmen ernsthaft stellen müssen.

Letzte Frage: Welche Art von Menschen eignet sich für FDE?

Kevins Antwort ist sehr knapp: FDE ist ein Software-Engineering-Job, bei dem du der Person so weit vertraust, dass sie direkt mit dem Kunden sprechen und ihn betreuen kann. Technische Fähigkeiten sind die Basis – aber du musst ihm auch zutrauen, das Unternehmen bei der Zusammenarbeit mit dem Kunden zu vertreten.