Was ist ein Forward Deployed Engineer?

„Forward Deployed Engineer“ ist eine Berufsbezeichnung, die überall dort auftaucht, wo Unternehmen Software einkaufen. Sie klingt nach Jargon, und zur Hälfte ist sie das auch: „forward deployed“ stammt aus dem Militär und bedeutet dort, nah am Geschehen stationiert zu sein statt im Hauptquartier. Lässt man die geliehene Hälfte weg, bleibt etwas Einfaches übrig. Ein Forward Deployed Engineer ist ein erfahrener Engineer, der in Ihrem Unternehmen und an Ihrem Problem arbeitet, statt es aus der Distanz zu betrachten.

Der Unterschied wiegt schwerer, als er klingt. Technische Arbeit, die Sie einkaufen, kommt meist in einer von zwei Formen. Entweder Sie kaufen ein Dokument, in dem jemand Ihr Unternehmen untersucht und eine Empfehlung zurückgibt, oder Sie kaufen ein Projekt, bei dem jemand eine geschriebene Spezifikation mitnimmt und fertige Software zurückbringt. Beide Formen setzen voraus, dass die Ausführung das Schwierige ist und die Frage schon geklärt war, bevor jemand angefangen hat. Bei vieler KI-Arbeit stimmt diese Annahme schlicht nicht. Das Schwierige ist herauszufinden, was das System tatsächlich abdecken muss, und das erfährt man, indem man etwas gegen die echten Fälle des letzten Monats laufen lässt, nicht indem man eine längere Spezifikation schreibt.

Das Forward-Deployed-Modell ist die Antwort darauf. Statt eine Spezifikation zu bekommen, setzt sich der Engineer dorthin, wo die Arbeit passiert, sieht einen vollständigen Durchlauf, vereinbart mit jemandem, der Ja sagen kann, ein einziges Ergebnis, und baut darauf zu, während die echten Fälle zeigen, was übersehen wurde. Verantwortlich ist er für das Ergebnis, nicht für eine Ticketliste. Wenn es funktioniert, merkt der Kunde den Unterschied nicht an der Technik. Er merkt ihn daran, dass niemand darauf wartet, dass jemand anderes etwas aufschreibt.

Woher der Titel kommt

Bekannt gemacht hat den Titel Palantir, ein amerikanisches Softwareunternehmen, das ihn seit Jahren öffentlich auf den eigenen Karriereseiten verwendet: für Engineers, die vor Ort beim Kunden arbeiten, statt aus der Ferne ein Produkt zu bauen. Das Muster hat sich verbreitet. KI-Labore und Anbieter von Unternehmenssoftware schreiben heute öffentlich Stellen unter diesem oder einem sehr ähnlichen Titel aus, weil das, was sie verkaufen, erst auf die Daten und Abläufe jedes Kunden zugeschnitten werden muss, bevor es etwas taugt.

Es gibt einen ehrlichen Grund für dieses Modell. Allzwecksysteme lösen den allgemeinen Teil eines Problems und bleiben dann stehen. Der Wert, der übrig bleibt, steckt im Durcheinander des einzelnen Unternehmens: in den Ausnahmen, den hausgemachten Regeln, der Tabelle, die jemand von Hand pflegt, den drei Systemen, die denselben Kunden unterschiedlich führen. Kein Maß an Produktarbeit aus der Distanz holt das heraus. Der einzige Weg hinein führt darüber, jemanden in dieses Durcheinander zu schicken.

Was die Person tatsächlich tut

Die ersten zwei Monate sehen überall ähnlich aus, wo das Modell funktioniert. Die erste Woche vergeht damit, der Arbeit zuzusehen und Zugang zu den Systemen zu bekommen, die sie berührt, und sie endet mit einer Seite, auf der steht, was das Ergebnis ist und wie es gemessen wird. Ein guter Forward Deployed Engineer verbringt diese Woche mehr mit Fragen als mit Code, und das ist keine Verzögerung: Davon hängt ab, ob die restliche Arbeit überhaupt auf etwas zielt.

• Woche eins: einen vollständigen Durchlauf der Arbeit ansehen, Zugänge bekommen, eine Seite zu Ergebnis und Messung vereinbaren.
• Woche zwei: etwas Schmales läuft auf den echten Daten, vor den Leuten, deren Arbeit es verändert.
• Danach: die Fehler, die es macht, sind die Spezifikation für den Rest der Arbeit.
• Um Monat zwei: im Betrieb, mit menschlicher Übersteuerung und dokumentiert, damit das Team allein weitermacht.

Wie es sich von dem unterscheidet, was Sie schon einkaufen

Eine Beratung hinterlässt ein Dokument. Das ist der richtige Einkauf, wenn die Entscheidung der Engpass ist. Es ist der falsche Einkauf, wenn sich alle längst einig sind, was passieren soll, und trotzdem nichts passiert. Ein Forward Deployed Engineer hinterlässt stattdessen ein laufendes System, was weniger wert ist als ein Dokument, falls die Entscheidung das Schwierige war, und deutlich mehr wert, falls nicht.

Dienstleister und Personalaufstockung verkaufen Kapazität. Jemand auf Ihrer Seite schreibt die Tickets und trägt das Risiko, das Falsche zu bestellen, und der Anbieter wird daran gemessen, ob die Tickets geschlossen wurden. Ein Forward Deployed Engineer wird daran gemessen, ob der Prozess schneller oder günstiger geworden ist, und entscheidet mit, was gebaut wird.

Ein Projekt mit festem Umfang setzt voraus, dass die Antwort vor dem Start bekannt ist. Wenn sie es ist, nehmen Sie den festen Umfang: Er ist günstiger, und das Risiko einer falschen Schätzung liegt beim Anbieter. Wenn sie es nicht ist, wird ein Festpreis entweder mit Puffer aufgeblasen, was ihn teuer macht, oder buchstabengetreu durchgezogen, was genau das liefert, was aufgeschrieben wurde, und nichts, was jemand gebraucht hätte.

Wann es die richtige Wahl ist

• Sie können den Prozess benennen, der die meisten Stunden kostet, aber nicht die Lösung, und im Haus kann sie niemand bauen.
• Jemand hat ein Strategiepapier zu Ihren KI-Chancen geliefert, und seither läuft nichts.
• Eine Einstellung würde Monate dauern, und es ist noch offen, ob die Arbeit eine feste Stelle rechtfertigt.
• Die Ausnahmen in Ihrem Prozess sind das Schwierige, also wäre jeder heute geschriebene Umfang geraten.

Diese vier Fälle haben eines gemeinsam: Die Frage ist noch offen. Wo die Frage offen ist, schlägt der Einkauf eines Ergebnisses den Einkauf eines Plans oder zusätzlicher Hände.

Wann es die falsche Wahl ist

• Sie wissen bereits genau, was gebaut werden soll. Kaufen Sie den Bau: Das ist günstiger, und das Risiko liegt beim Anbieter.
• Niemand auf Ihrer Seite kann innerhalb einer Woche entscheiden. Das Modell lebt von einem schnellen Ja oder Nein, sonst steht der Engineer still und Sie zahlen für den Stillstand.
• Der Zugang zu Daten und Systemen dauert drei Monate Freigaben. Die Uhr läuft trotzdem.
• Was Sie wirklich brauchen, sind mehr Hände für ein bestehendes Backlog. Das ist Personalaufstockung, ein anderes und günstigeres Produkt.

Ein Anbieter, der Ihnen nie sagt, dass einer dieser Punkte auf Sie zutrifft, verkauft Ihnen etwas. Die Frage ist nicht, ob er Forward Deployed Engineering macht. Die Frage ist, wovon er Ihnen abraten würde.

Was Sie fragen sollten, bevor Sie zusagen

• Wer genau kommt ins Team, und kann ich mit dieser Person sprechen, bevor ich etwas unterschreibe?
• Was steht am Ende der ersten Woche auf dem Papier, und wie wird das Ergebnis gemessen?
• Was läuft am Ende der zweiten Woche auf echten Produktivdaten?
• Wo liegt der Code, und wem gehört er, wenn die Zusammenarbeit früher endet?
• Wie lang ist die Kündigungsfrist, und gibt es eine Ausstiegsgebühr?

Bei Pluscode arbeiten wir so, weil wir keinen anderen Weg gefunden haben, aus den unordentlichen, sehr spezifischen und halb dokumentierten Abläufen, auf denen echte Unternehmen laufen, ein Ergebnis zu holen. Wenn Sie die Aufgabe benennen können, die Ihr Team die meisten Stunden kostet, nehmen wir uns dreißig Minuten dafür, gemeinsam mit dem Engineer, der die Arbeit machen würde, und sagen Ihnen ehrlich, ob das der richtige Weg ist oder ob etwas Kleineres und Günstigeres reicht. Dieses Gespräch kostet nichts und verpflichtet zu nichts.