Vor etwas mehr als einem Jahr habe ich eine Stunde mit jemandem telefoniert, der seit einem Jahrzehnt Forward Deployment für das Unternehmen betreibt, das den Begriff geprägt hat. In den letzten zwölf Monaten habe ich in verschiedenen Formen mit Menschen zusammengearbeitet, die ihre Forward-Deployment-Engines aufbauen. Ich habe immer noch das Gefühl, dass kein Inhalt dem gerecht wird, was Forward Deployment alles umfasst.
Als ich mit meinem Freund sprach, fragte ich, wie der berühmte Discovery-Prozess tatsächlich funktioniert. Die Antwort war fast peinlich physisch, zumindest anfangs, wenn man die Dinge nur oberflächlich betrachtet. Du fliegst ein. Du verbringst zwei Tage damit, jeden zu treffen, der mit dem Problem zu tun hat. Der ERP-Manager gibt dir eine Theorieschulung über Bestellungen. Dann bringen sie dich in die Fertigungshalle, damit du sehen kannst, was die Theorie auslässt. Dann fragst du sie drei Wochen lang eine Frage pro Tag, während du die Daten verkabelst. Ich fragte, ob es eine Formel gäbe. Er sagte, die Formel sei, so viel Zeit wie möglich mit den Leuten zu verbringen, die es wissen. Zehn Jahre später hat sich dieser Teil nie geändert.
Das kann jedoch irreführend sein, wenn man nicht tiefer gräbt. Ja, sie verbringen viel Zeit mit den Kunden. Gute Forward-Deployed-Engines bauen das Modell jedoch im Voraus. Hervorragende Deployment Engineers und Deployment Strategists erkennen, dass sie nicht alles verstehen werden, aber sie sind sehr schnell darin, Dinge zu bauen und mit den Kunden zu iterieren. Der erste Workflow ist das unmittelbare Ziel. Ontologien werden verwendet, um dieses Tool schrittweise zu einem Betriebssystem zu erweitern. Wo gute Forward-Deployment-Engines glänzen, ist die Tatsache, dass ein Großteil des Kontexts vom Team, von den Fachexperten kommt, und sie setzen alles zu einem großen Teil zusammen, noch bevor sie den Kunden zum ersten Mal treffen. Dieser Teil hat sich im Laufe der Zeit verbessert und ist der wahre Grund, warum manche Engines sich compounding verhalten und andere nicht.
Ich hatte sofort zwei Gedanken. Die hast du wahrscheinlich auch, wenn du nicht darauf geachtet hast, was gutes Forward Deployment ist, also bitte ich dich, weiterzulesen.
Mein erster Gedanke war: Was passiert, wenn du keine Ahnung von den Workflows des Kunden hast? Du würdest mit vielen Interviews beginnen, oder? Mein Freund sagte nein, weil niemand gerne interviewt wird, aber er erzählte eine Geschichte. Sein Team baute einmal eine Routing-Engine für ein Logistikunternehmen, dessen Disponenten tägliche Tickets manuell an Fahrer oder Routen vergaben, basierend auf Bauchgefühl und der Betrachtung von Karten, Entfernungen, Deponiestandorten und anderen operativen Einschränkungen. Mein Freund baute ein Tool, das Disponenten Empfehlungen gab, aber das erste Problem war, dass die Disponenten die Empfehlung oft aus Intuition ablehnten und nicht klar erklären konnten, warum. Um das zu lösen, musste sein Team alle möglichen verschiedenen Zuweisungsmöglichkeiten sichtbar machen, und dann nutzten sie diese Transparenz, um menschliche Entscheidungen mit simulierten Ergebnissen zu vergleichen. Dies war das erste Mal, dass jemand alle Permutationen auf einem Bildschirm abbildete, und somit war es das erste Mal, dass die Leute einen Moment Zeit hatten, um zu reflektieren, ob die Entscheidung, die sie aus dem Bauch heraus trafen, durch Daten in großem Maßstab gestützt wurde. Es ermöglichte dem Team des Logistikunternehmens, den Workflow selbst zu prüfen, zu verstehen, ob die Prozesslogik tatsächlich richtig war, und den digitalen Zwilling zu verfeinern, damit er besser der tatsächlichen Geschäftspraxis entsprach. Sie genossen den Prozess auch, weil er sich nie wie ein Interview anfühlte, sondern ihnen zum ersten Mal erlaubte, alle Puzzleteile auf einem Board zu sehen.
Mein nächster Gedanke war: Wie verändert die Hinzunahme von Agenten den gesamten Prozess heute im Vergleich zu vor ein paar Jahren? Die Antwort meines Freundes war, dass es einfach bedeutet, dass wir mit Agenten viel schneller entwickeln und mehr Kontext auf der Ebene des impliziten Wissens haben können, aber das ist nur ein Teil des Puzzles. Er sagte, die geheime Zutat in ihrem FDE-Modell sei bei diesen Piloten nichts Einstein-würdiges. In einigen Fällen, sogar jetzt noch, während sie Piloten durchführen, hören sie einfach die Schritte und Ergebnisse, machen ein Verb-Mapping und geben dem Kunden ein Team von fünf Leuten, die einfach ihre dedizierten Ingenieure sind. Diese Ingenieure kodifizieren alles, und dann können sie einfach verschwinden und der Kunde kann die Lösung weiterhin nutzen. Die Agenten helfen in dem Sinne, dass sie den Kodifizierungsprozess beschleunigen und vertiefen, indem sie es einfacher machen, mehr Kontext und implizites Wissen aus den Systemen des Kunden einzubeziehen. Agenten sind zu einem Weg geworden, über direktes Benutzerfeedback hinauszugehen und stattdessen historischen und operativen Kontext einzubeziehen, Dinge wie E-Mails, Änderungen im Verkaufsprozess, Statusänderungen in Systemen wie Salesforce und andere Spuren, wie die Organisation im Laufe der Zeit gearbeitet hat. Das macht es einfacher, die Workflows der Kunden umfassender zu modellieren, fragmentierte Wissensquellen miteinander zu verbinden und Systeme zu bauen, die nicht nur das Unternehmen durch einen digitalen Zwilling repräsentieren, sondern auch helfen, die Entscheidungen, die Menschen derzeit manuell treffen, zu automatisieren oder zu unterstützen.
Ich habe ein paar Absätze aus der Transkription meines Gesprächs mit ihm.
Also, die Art und Weise, wie wir beginnen, ist, dass wir uns immer auf die Geschwindigkeit des Werterhalts konzentrieren. Wir folgen nicht immer einem prozeduralen Ansatz wie: Okay, lasst uns die Ontologie erstellen. Dann lasst uns die Anwendung darauf aufbauen. Dann lasst uns zum Benutzer gehen. Nein. In mancher Hinsicht folgen wir ihm, aber in anderen Hinsichten fragen wir den Kunden einfach: Was ist der größte Mehrwert, den wir für dich schaffen können? Oder: Welche größte Auswirkung können wir dir jetzt liefern? Erkläre uns das Problem in deinem Unternehmen und nun das Problem, von dem du denkst, dass wir es lösen können.
Sobald der Kunde es teilt, gehen wir sozusagen ans Reißbrett und sagen: Okay, lass uns einfach eine Version eins der Ontologie hacken, eine Version eins der Anwendung innerhalb von etwa einer Woche bauen und sie testen. Es ist also sehr ähnlich, wie du ein Startup aufbauen würdest. Oft stellen wir fest, dass sie vielleicht auf eine Idee für einen Anwendungsfall kommen, aber während sie sprechen, entdecken wir einen völlig anderen potenziellen Anwendungsfall, den wir einfach lösen können. Und wir werden das einfach bauen, auch wenn sie dachten, sie bräuchten etwas anderes. Am Ende des Tages versuchen wir, uns auf das größte Problem einzustellen, das sie lösen müssen.
Wir werden schnell etwas dafür bauen und fünf Objekte in Bezug auf die Ontologie erstellen. Wenn wir etwas im Zusammenhang mit dem ERP-System tun, das ziemlich komplex sein kann, selbst nachdem wir die Integrationen abgeschlossen haben, suchen wir diesen ERP-Experten ein paar Mal für eine einstündige Jam-Session oder ein halbstündiges Ad-hoc-Treffen während der Woche auf. Und sobald wir uns dort bewährt haben, suchen wir nach dem zweiten, dritten, vierten Anwendungsfall, bis zu dem Punkt, an dem wir ein Enterprise OS für ihr gesamtes Unternehmen aufbauen können.
Normalerweise machen wir das in Form eines Vor-Ort-Termins. Wir fliegen einfach ein, wir sagen: Okay, gib uns zwei Tage. Wir treffen uns mit den Stakeholdern, allen, die zusammen da sein können, oder einzeln. In vielen Fällen, wenn die Leute beschäftigt sind, setzen wir uns einfach neben sie und versuchen, ihren Verkaufsprozess oder ihre Art der Kundeninteraktion zu verstehen. Wir versuchen aus ihrer Perspektive zu verstehen, was passiert, und wir versuchen nicht, die Zeit mit dem Kunden zu verkürzen. Tatsächlich vertiefen wir uns immer mehr darin, und das ist etwas, das sich in 10 Jahren nie geändert hat. Manchmal verbringen wir ganze Wochen mit den Kunden. Wir haben noch nie versucht, uns davon zu lösen und unsere Plattform in irgendeiner Weise vollständig zu automatisieren, wenn es um die Discovery geht.
Ein zentraler Gedanke in der Diskussion war, dass Kodifizierung durch Iteration geschieht, nicht durch umfangreiche Dokumentation. Das Team baut einen "digitalen Zwilling" des Unternehmens direkt im Code, unter Verwendung von Datenintegrationen, operativem Kontext und Input von Fachexperten, um darzustellen, wie die Organisation in der Praxis funktioniert. Aber dieses Datenmodell allein reicht nicht. Die schwierigere und wertvollere Schicht ist die Geschäftslogik – das Verständnis dafür, wo Intervention wichtig ist, welche Maßnahmen empfohlen werden sollten und wie erfahrene Operateure tatsächlich Entscheidungen treffen. All dies geht nicht nur darum, Informationen zu sammeln, sondern den Benutzern zu helfen, Kompromisse abzuwägen, Workflows zu validieren und schließlich die Entscheidungsunterstützung in das Produkt selbst zu kodieren.
Der Rest meines Gesprächs vertiefte sich darin, wie diese Arbeit nicht davon abhängt, von Anfang an tiefe Fachexperten eingebunden zu haben. Die Erwartung ist, dass Forward-Deployed Engineers in unbekannte Umgebungen eintauchen, schnell lernen und Glaubwürdigkeit aufbauen können, indem sie schnell nützliche Systeme produzieren. Frühe Engagements beginnen oft mit einem kurzen Bootcamp, unterstützt durch vorgefertigte Prototypen und Beispieldaten, die darauf ausgelegt sind, schnell Wert zu demonstrieren und sich das Recht für ein tieferes Deployment zu verdienen. Von dort aus kann sich die Beziehung von einem einzelnen Anwendungsfall zu einem breiteren Betriebssystem für den Kunden ausweiten, mit dem langfristigen Ziel, Workflows so effektiv zu kodifizieren, dass das Team schließlich einen Schritt zurücktreten kann, während der Kunde die Lösung weiterhin nutzt.
Dies ist ein hochrelevantes Playbook für ein neues Vorhaben, das jetzt aufgebaut wird. Das ist Forward Deployment. Alles andere ist vielleicht nur Dekoration.
Das Gesetz des compounding
Forward Deployment ist teuer, zeigt sich nur langsam in der Bruttomarge und ist schwer sauber zu planen. Gründer spüren das und fragen sich, ob der Aufwand den Nutzen rechtfertigt. Irgendwann sagt ein leitender Angestellter laut, was alle denken: Wir stecken den doppelten Aufwand rein und bekommen das doppelte Ergebnis.
Dieser Satz ist eine rote Flagge für bestimmte Branchen, wenn er impliziert, dass Forward Deployment nicht das richtige Modell ist. Ich verstehe die Ungeduld eines Gründers, da ich selbst einer war, aber es gibt eine schmale Grenze zwischen Naivität und Ungeduld. Für Unternehmen, die besser mit einem Forward-Deployed-Engine funktionieren, hat jeder, der diese Rechnung mit Multiplikation aufstellt, den Job nicht verstanden. Wenn der doppelte Aufwand das doppelte Ergebnis bringt, hast du Berater eingestellt und sie als Ingenieure verkleidet. Du wirst für immer Personal im Gleichschritt mit dem Umsatz aufbauen, deine Margen werden sich nie verbessern, und der ehrliche Name für das, was du gebaut hast, ist eine Personalvermittlungsagentur, die Code ausliefert oder Support bietet. Leute, die sich nicht klar darüber sind, was sie bauen, landen fast immer bei mittelmäßigen Ergebnissen, und diese besondere Verwirrung wirkt sich gegen dich aus.
Forward Deployment macht nur Sinn, wenn die Mathematik sich biegt. Deployment eins darf hässlich, handgefertigt, wirtschaftlich nicht zu rechtfertigen sein. Sein Job ist es, zu lehren. Deployment zwei muss günstiger sein, weil Deployment eins eine Vorlage, eine Integration, ein dokumentiertes Muster, ein Stück Plattform hinterlassen hat. Bei Deployment zehn sollte das meiste, was das erste Team von Hand gemacht hat, durch Konfiguration geschehen, und die Menschen sollten eine Stufe höher sein und Probleme lösen, die es vor einem Jahr, selbst in den Augen des Kunden, noch nicht gab. Die Distanz zwischen diesen beiden Zahlen in Monat 1 und Monat n ist compounding, und diese Kurve ist das eigentliche Ding, das du kaufst, wenn du ein Forward-Deployed-Team finanzierst. Compounding ist der ganze Punkt. Sich als Forward Deployed zu bezeichnen, ohne einen Engine, der compoundiert, ist einfach dumm.
Ein Softwareentwickler und ein Forward Deployed Engineer unterscheiden sich hauptsächlich dadurch, wie viel Zeit ein SWE damit verbringt, Code zu schreiben, der Dinge wartet, unterstützt oder auf der Roadmap aufbaut, im Vergleich zu dem, was der FDE damit verbringt, Dinge zu entdecken, die oft nicht auf der Roadmap stehen, aber den Kundenwert erschließen, sie einzusetzen und an das Produkt zu übergeben, wenn sich das Muster bei mehreren Kunden wiederholt.
Das Wort, das jeder benutzt und fast niemand meint
Die Idee hat einen spezifischen Ursprung. Vor zwei Jahrzehnten fragte ein Gründer, warum großartige französische Restaurants großartig sind, und landete beim Kellner. In einem großartigen Restaurant ist der Kellner Teil der Küche. Wenn er also etwas empfiehlt, spricht die Küche. Palantir baute die Ingenieursversion davon und gab der Rolle einen militärischen Namen, weil ihre Kunden Militärs waren. Der Name gab der Feldarbeit den verdienten Status, und das zu Recht. Es zahlte sich so gut aus, dass zwanzig Jahre später jeder den Namen will, aber ich bin mir nicht sicher, wie viele die Arbeit verstehen.
In gewisser Weise muss ein Forward-Deployed-Team das tun, was ein Gründer in der 0-1-Phase tun muss. Du entdeckst oft, was du liefern könntest, das nicht nur eine Eitelkeitsmetrik verbessert, sondern deinem Kunden wirklich hilft, sein Geschäft auszubauen. Dies ist ein weiteres reales Beispiel aus dem Gespräch mit meinem Freund. Sein Team wurde von einem Hersteller von EV-Ladegeräten beauftragt, der die Produktion um etwa das Zehnfache steigern wollte. Das war der Auftrag. Kannst du das Ergebnis erraten? Es war definitiv kein Strategiedeck. Das Ziel des Unternehmens war an der Oberfläche einfach: die Produktion von EV-Ladegeräten um das Zehnfache zu steigern. Was das Forward-Deployed-Team tatsächlich tat, war, vor Ort zu gehen und den Betrieb aus mehreren Ebenen des Unternehmens kennenzulernen. Sie verbrachten Zeit mit dem ERP-Verantwortlichen, um das System of Record, Bestellungen, Arbeitsaufträge, Angebot und Nachfrage zu verstehen. Dann gingen sie in die Fertigungshalle, um zu sehen, wie die Produktion in der Praxis tatsächlich ablief. Gleichzeitig sprachen sie mit Führungskräften, um die strategische Version des Problems zu verstehen, denn das, was die Mitarbeiter an der Front als falsch oder dringend bezeichnen, stimmt nicht immer perfekt mit dem überein, was die Führung als die wichtigste Einschränkung ansieht. Die Arbeit bestand also nicht darin, direkt eine neue Produktionslinie zu bauen, zumindest nicht nach dem, was im Meeting gesagt wurde. Es ging darum, einen digitalen Zwilling des Betriebs zu bauen und dann zu identifizieren, wo Software in den Workflow eingreifen könnte, zum Beispiel bei Problemen wie kritischen Teileknappheiten, dem Zeitpunkt von Bestellungen, Sicherheitsbeständen und anderen betrieblichen Entscheidungen. Das beschriebene Ergebnis war ein System, das Risiken früher erkennen und Maßnahmen empfehlen konnte, und keine physische Veränderung der Fertigung selbst. Ich hoffe, das erklärt, was ich meine, wenn ich sage, dass ehemalige Gründer außergewöhnliche Forward-Deployed-Leute sein können.
Schau unter die heutigen Berufserfahrungen (nicht Stellenbeschreibungen) und du findest Ingenieure, die Produktionscode in den Systemen der Kunden schreiben und die Verantwortung für das übernehmen, was nach dem Go-Live passiert, einschließlich Support. Der Rest sind Sales Engineers mit einer besseren Visitenkarte, die anhand der Demo beurteilt werden, plus ein Anhang von internen Automatisierungsrollen, die sich das Wort geliehen haben, weil es modern ist. Die angrenzenden Verwirrungen darüber, was Forward Deployment ist, sind schlimmer. Ein Expertennetzwerk durch hundert Domain-Interviews zu betreiben, ist Forschung, aber das ist kein Forward Deployment. Wenn ein Private-Equity-Unternehmen Unternehmen zusammenfasst und ein Transformationsteam schickt, ist das nützlich, manchmal brillant, aber nicht unbedingt Forward Deployment. Ich sage das, weil niemand in diesen beiden Bewegungen das besitzt, was ich Work-Closure nenne.
Work-Closure ist die Einheit, in der diese gesamte Disziplin bemessen wird. Nicht eine ausgelieferte Funktion, nicht ein gelöstes Ticket. Ein Stück der Arbeit des Kunden, getragen vom stehenden Problem bis zu etwas, an das niemand mehr denkt. Die Vertragsunterschrift ist die Grenze zwischen den Berufen, die hier verwechselt werden. Ein Sales Engineer arbeitet darauf hin. Ein Forward-Deployed-Team beginnt damit, denn zuzustimmen, dass etwas funktionieren sollte, ist nicht dasselbe, wie dass es funktioniert. Wenn die Person eine Verkaufsquote trägt, siehst du Sales. Wenn die Person drei Monate nach dem Start noch in den Logs des Kunden auftaucht, siehst du Forward Deployment. Ein Unternehmen, das ein Marketingprodukt verkauft, wird Sales Engineers schicken, um den Deal abzuschließen und Dinge zu deployen und zu konfigurieren. Ein echter FDE könnte zu dem Schluss kommen, dass keiner der Workflows, die das Produkt unterstützt, dem betreffenden Kunden helfen wird, und etwas völlig Neues wird sich direkt auf das obere oder untere Ende der Gewinn- und Verlustrechnung auswirken, und dann bauen sie diesen Workflow. Das erfordert, ein Experte im Mom's Test zu sein (lies das Buch), zu verstehen, dass Kunden sich nicht für deine Funktion interessieren, sondern dafür, wie sie bessere Geschäfte machen, dein Produkt zu verstehen und schnell auszuliefern, damit du mit dem Kunden am Live-Workflow iterieren kannst.
Hier ist also die Definition, die ich an die Wand hängen würde. Forward Deployment bedeutet, in der Kluft zwischen dem, was du ausgeliefert hast, und dem, was der Kunde brauchte, zu stehen, diese Kluft mit eigenen Händen zu schließen, in ihrer Welt, auf eine Weise, die deinem Produkt beibringt, sie das nächste Mal allein zu schließen.
Der zweite Teil dieses Satzes ist der Punkt, an dem fast alle scheitern.
Warum das plötzlich überall ist
Siebenzig Jahre lang half Software den Menschen, Arbeit zu erledigen. Jetzt beginnt sie, die Arbeit zu erledigen. Das kehrt eine versteckte Annahme um. Ein Werkzeug kann es sich leisten, langsam angenommen zu werden. Ein Arbeiter nicht. In dem Moment, in dem du Ergebnisse statt Plätze verkaufst, muss jemand das Ergebnis in einem Unternehmen wahr werden lassen, das sich ganz anders verhält als deine Demo-Umgebung.
Die Modelle haben irgendwann in den letzten zwei Jahren aufgehört, die Einschränkung zu sein. Das Deployment wurde zur Einschränkung. Die am häufigsten zitierte Studie zu Enterprise-AI-Piloten ergab, dass etwa neunzehn von zwanzig keine messbare Auswirkung auf die Gewinn- und Verlustrechnung haben, und die Autopsie ist fast nie die Modellqualität. Es ist Software, die den Workflow nie gelernt hat. Der dokumentierte Prozess hat vier Schritte. Der echte hat neun, und die fehlenden fünf leben im Gedächtnis einer Frau, in einem persönlichen Tracker, den sie vor Jahren gebaut hat, und in einem Gefallen, den sie mit einer anderen Frau in einem anderen Gebäude austauscht. In älteren Branchen läuft die Arbeit durch Systeme, die installiert wurden, bevor deine Ingenieure geboren wurden, die an den Rändern durch Faxgeräte und Telefonanrufe zusammengehalten werden. Nichts davon hat eine API. Auf den Ölfeldern legt jemand sein Ohr an die Bohranlage, um zu beurteilen, ob das Geräusch auf etwas hinweist, das Sorgen bereiten sollte. Auf dem Schiff, das Tintenfische von Indien in die USA transportiert, mit einem Zwischenstopp in London, werden Tarife und Preise auf der Grundlage von Bauchgefühl, begrenzten Wetterdaten und dem, was visuell als Qualität der Ware erscheint, festgelegt. Implizites Wissen (Tribal Knowledge) ist die tragende Schicht jedes Unternehmens, und niemand hat jemals ein SDK dafür ausgeliefert. Der industrielle Plattformfriedhof des letzten Jahrzehnts hat diese Lektion mit Milliarden von Dollar gelehrt. Transformationen sterben nicht in der Architektur. Sie sterben bei der Adoption.
Das Geld hat es bemerkt. Microsoft hat zweieinhalb Milliarden Dollar und sechstausend Leute eingesetzt, um Experten in die Kunden zu integrieren. AWS hat Wochen zuvor eine Milliarde hinter die gleiche Idee gesteckt. OpenAI und Anthropic haben jeweils eigene dedizierte Deployment-Unternehmen mit einigen der weltweit größten Investoren im Rücken aufgebaut. Du kannst das Mode nennen. Kapital in dieser Größenordnung ist selten ein Kostüm. Die Labs haben ihre eigenen Pipelines bewertet und entdeckt, dass es dem Käufer nie an Intelligenz mangelte. Dem Käufer mangelte es an Händen. Das Scheitern liegt in der letzten Meile, und die letzte Meile ist der Ort, an dem der Burggraben ausgehoben wird. Es hat 10 Jahre harter Arbeit an LLMs gedauert, um dorthin zu gelangen, wo wir jetzt sind. Es könnte viel länger dauern, wenn wir diese Modelle dazu bringen würden, ein Verständnis für Workflow und menschliche Entscheidungsrahmen zu entwickeln.
Warum du eine Geschäftsperson in diesem Team brauchst
Der Ingenieur existiert, weil die Lücke mit Code geschlossen wird, auf der Infrastruktur des Kunden, gegen die Edge Cases des Kunden, normalerweise innerhalb von Tagen. Was die Benutzer am Morgen beschreiben, sollte innerhalb von Tagen vor ihnen laufen, nicht in Quartalen. Diese Geschwindigkeit ist es, wie Vertrauen mit Menschen aufgebaut wird, die dreijährige Transformationsprogramme beobachtet haben, die eine Bibliothek von Folien produziert haben.
Die Geschäftsperson existiert, weil die schwierigsten Probleme beim Deployment nicht technischer Natur sind, und so zu tun, als ob sie es wären, ist der Weg, wie technische Teams scheitern. Jemand muss herausfinden, was die Arbeit tatsächlich ist, bevor jemand sie automatisiert. Jemand muss entscheiden, welche drei der zwanzig Eskalationen wichtig sind, welcher Workflow der eigentliche Engpass ist, welches Schweigen einer Führungskraft die Adoption töten wird und welches Ergebnis das gesamte Engagement rechtfertigen würde. Jemand muss gut darin sein zu lesen, wann ein Kunde zögert und wann er Dinge nur aus Höflichkeit sagt. Jemand muss die heikelste Schnittstelle in Enterprise AI betreiben, die zwischen dem, was dein Produkt heute tut, und dem, was du als unvermeidlich in sechs Monaten verkauft hast. Ich betrachte den Deployment Strategist als das Futures Desk des Unternehmens. Sie verkaufen, was das Produkt werden wird, zu einem Preis, den die Beziehung überleben kann, und sie stellen sicher, dass die Position nie ausfällt. Hochriskante Deals werden an diesem Desk gewonnen und ohne ihn verloren.
Die Fehlermodi sagen dir, welche Rolle dir fehlt. Deals, die ins Stocken geraten, weil das Produkt in der Welt des Kunden nicht läuft, oder Szenarien, in denen das Produkt nur Workflows unterstützt, die innerhalb des Produkts existieren, bedeuten, dass dir der Ingenieur fehlt. Ingenieure, die angeforderte Funktionen liefern und beschäftigt sind, aber der Umsatz steigt nicht so stark, oder Szenarien, in denen der FDE 100+ Anrufe getätigt hat, aber der vertraglich vereinbarte Umsatz immer noch eine Größenordnung höher ist als der realisierte Umsatz, oder Silos von benutzerdefinierten Workflows, die das System nicht verbessern, bedeuten, dass dir der Stratege fehlt.
In den besten Teams verschwimmen die beiden Rollen, und das Verschwimmen ist der Punkt. Der Ingenieur entwickelt Geschäftsinstinkt, der Stratege lernt, ein Schema zu lesen, und was du bekommst, ist das, was einem Gründer, den ein Unternehmen einstellen kann, am nächsten kommt. Forward Deployment ist das, was jeder Gründer jahrelang tut, bevor das Organigramm es verbirgt: im Chaos der Kunden sitzen, Arbeit mit dem schließen, was gerade zur Hand ist, und das, was sie lernen, das Produkt neu zeichnen lassen. Die Rolle ist eine Gründungswoche auf dem Cap Table eines anderen. Es ist auch der Grund, warum diese Teams Gründer in einer Rate hervorbringen, die Big Tech in Verlegenheit bringt. Wenn du einen FDE-Pod leitest, solltest du dich von Tag eins an mit einer Nachfolgeplanung wappnen, denn die Wahrscheinlichkeit ist groß, dass Gründer, die ein Jahrzehnt später aufbauen, alle in ihrem früheren Leben, das sich heute entfaltet, FDEs waren.
Wie du weißt, ob du wirklich einen hast
Du kannst ein Forward-Deployed-Team nicht anhand einer Momentaufnahme beurteilen, denn an jedem beliebigen Tag sehen ein großartiges und ein gefälschtes Team identisch aus: kluge Leute, die zu Kunden fliegen und Heldentaten liefern. Fünf Checks decken es auf.
#1 Aufwand pro Kunde. Ein Team, das letztes Jahr fünf Kunden betreut hat und dieses Jahr fünf betreut, compoundiert nichts. Ein Team, das jetzt fünfzehn betreut, füttert ein Produkt, das aufnimmt, was das Feld lernt. Mit jedem Kunden sollte dein Team intern einen Fachexperten entwickeln.
#2 Die Neuartigkeit der Arbeit. Wenn das vierte Deployment das dritte wiederholt, besitzt niemand die Pipeline vom Feld zur Plattform. Jemand muss dafür bezahlt werden, Wiederholungen über Konten hinweg zu jagen, denn Wiederholungen sind die Roadmap, die sich selbst schreibt.
#3 Die Form des zweiten Deployments in einem Segment. Wenn Kunde zehn dich genauso viel kostet wie Kunde eins, skalierst du kein Produkt. Du franchiseest ein Projekt.
#4 Die Berichtslinie. Innerhalb des Produkts oder der Technik kann sich der Kreislauf schließen. Innerhalb eines Sales- oder Service-Silos verlassen die Erkenntnisse in Reiseberichten, die niemand liest, und das Team wird leise zur Marge.
#5 Die eigene Scorecard des Kunden. Aktivität ist Theater. Nutzungszahlen können spektakulär aussehen, während sich stromabwärts nichts verbessert. Die einzige Messung, die den Kontakt mit einem CFO überlebt, ist eine Bewertung, die der Kunde mitgeschrieben hat, die die Arbeit anhand ihrer Ergebnisse auf ihren Daten bewertet, in Woche eins erstellt und offen verfolgt. Behalte einen menschlichen Test daneben. Wenn in ihrem Geschäft etwas kaputt geht, das nichts mit deinem Produkt zu tun hat, bist du der erste Anruf? Jedes Dashboard, das je gebaut wurde, ist ein Versuch, diesen Anruf zu approximieren.
Und achte auf das dunkle Muster, denn es ist gerade überall. In einigen Unternehmen ist das Forward-Deployed-Team keine lernende Engine, sondern ein Versteck. Das Produkt funktioniert nicht ganz, also wird an jeder Lücke ein Mensch stationiert. Weil die Menschen heldenhaft sind, erreichen die Lücken nie die Roadmap. Weil die Lücken nie die Roadmap erreichen, verbessert sich das Produkt nie, und die Menschen können nie gehen. Das Produkt fühlt keinen Druck, weil das Feld es weiterhin absorbiert. Das Feld schreibt nichts auf, weil es zu beschäftigt damit ist, Konten zu retten. Die Rechnungen kommen weiterhin, weil der Kunde tatsächlich bedient wird. Die Maschine ist im Gleichgewicht, und das Gleichgewicht ist das Problem. Unternehmen leben jahrelang darin, wachsen die Feldbelegschaft genau so schnell wie die Kunden und nennen es Forward Deployment. Das ist es nicht. Es ist das Fehlen eines Produkts, monatlich abgerechnet. Es ist auch der Grund, warum sich so viele talentierte Leute in diesen Positionen fühlen, als würden sie versagen. Sie wurden eingestellt, um zu compoundieren, und besetzt, um zu verstecken.
Wie es in jeder Phase aussieht
Frühe Phase: Stelle niemanden ein. Sei selbst die Person. Die Gründer sind das vor Ort eingesetzte Team, und das Schlimmste, was du mit deinem begrenzten Verständnis tun kannst, ist, dessen Aneignung zu delegieren. Mach die Zwei-Tages-Reisen selbst. Setz dich neben die Disponenten. Wenn du endlich einstellst, stelle Leute ein, die dich schneller machen, die Arbeit abzuschließen, niemals Leute, die sich zwischen dich und den Kunden stellen.
In der Wachstumsphase wird der Vor-Ort-Einsatz leicht missverstanden, denn von außen sieht es nach Verlangsamung aus. Dein Board beobachtet, wie Ingenieure Wochen in einzelnen Konten verbringen, während Wettbewerber wöchentlich neue Funktionen ankündigen. Die Buchhaltung macht es noch schlimmer. Der Einsatz verbucht sich in den Kosten der Umsatzerlöse, obwohl sich die Arbeit wie F&E verhält – je besser du lernst, desto schlechter siehst du aus. Halte beide Wahrheiten, ohne in eine Richtung zu lügen. Im Hauptbuch ist es Kosten. In der Strategie ist es Forschung. Die Auflösung ist keine Geschichte, sondern Leitplanken, die die Forschung zwingen, sich auszuzahlen. Befriste jedes Engagement. Verbinde jedes mit einem einzigen benannten Geschäftsergebnis. Ernte vierteljährlich, das heißt: jedes Quartal wird etwas, das das Feld von Hand gebaut hat, zu etwas, das die Plattform allein tut. Wir werden es später produktisieren ist der Satz, der Unternehmen in dieser Phase tötet, denn später hat keinen Besitzer.
Im Maßstab verändert sich die Frage. Du hast Hunderte von Kunden, die Millionen zahlen, und du beschäftigst bereits Lösungsberater, Implementierungsteams, Managed Services, Account Executives, Customer Success. Führungskräfte in dieser Phase wissen wirklich nicht, wo ein Vor-Ort-Team sitzt, also wird es als vierte Support-Ebene draufgepackt und stirbt am Ticketvolumen. Die Antwort ist, dass jede bestehende Funktion ein Playbook betreibt, und das Vor-Ort-Team existiert nur dort, wo kein Playbook existiert. Die zehn ambitioniertesten Konten. Die neue Vertikale. Der Workflow, von dem die ganze Branche sagt, dass er nicht automatisiert werden kann, den du aber einzigartig automatisieren kannst. Es berichtet an das Produkt, ist damit beauftragt, seine eigene Arbeit überflüssig zu machen, und übergibt jedes gelöste Muster an die Teams, die Playbooks betreiben – so bleiben die Playbooks am Leben. Ubers Version davon ist lehrreich. Sie koppelten ihre KI-gewandtesten Ingenieure mit Domain-Experten aus Finanzen, Recht und Support, gaben jedem Paar zwei Wochen und verlangten, neben der Person zu bauen, die den Workflow besitzt, statt vor ihr zu präsentieren. Zwei Tage Beobachten, ein Tag Zielfindung, bis Tag zehn live. Sechzehn Pods haben in zwei Monaten sechzehn Funktionen umverkabelt, und ein Bericht, der zwei Tage dauerte, dauert jetzt zehn Minuten. Die Einheit der Automatisierung war nie die Aufgabe. Es ist der Workflow, und Workflows zeigen sich nur Menschen, die in ihnen sitzen.
Derselbe Job trägt in jeder Branche andere Kleider
In der Verteidigung und im öffentlichen Sektor ist die Präsenz das Produkt. Sicherheitsfreigaben, abgeschottete Netzwerke, Räume, die dein Laptop nicht verlassen darf. Im Gesundheitswesen ist der Job Workflow-Archäologie. Der eigentliche Prozess läuft über zwanzig Jahre alte Systeme, mit Faxgeräten und Telefonbäumen, die noch die Ausnahmen tragen, jede Einrichtung mit ihrer eigenen ungeschriebenen Variante. Ein Team, das von einem Standard ausgeht, verliert ein Jahr. In der Finanzbranche kauft der Kunde Urteilsvermögen unter Compliance, das Ergebnis ist oft eine Bewertung, die ein Regulierer lesen könnte, und die tiefste Sorge ist nicht Datenabfluss, sondern Urteilsabfluss – die Entscheidungsmuster ihrer besten Leute wandern in ein fremdes Modell. In der Fertigung und Logistik lebt die Wahrheit auf dem Boden, und die Zwänge sind physisch, weshalb Entdeckung nicht per Video stattfinden kann und die Systeme archaisch, sichtbar komplex und oft von der Cloud getrennt sind. In Konsumgüterunternehmen läuft der Kreislauf in Tagen statt Quartalen, und die knappe Fähigkeit ist Geschmack – zu wissen, wie die Marke klingt und wann eine Maschine aufhören sollte zu sprechen. Und das neueste Gebiet ist dein eigenes Unternehmen. Dieselben Pods, eingesetzt in deine eigenen Finanz-, Rechts- und Support-Funktionen, denn die Lücke zwischen dem, was KI kann, und dem, was deine Organisation tatsächlich tut, ist dieselbe Lücke, nur ein Gebäude weiter.
Das Gelände bestimmt die Taktik, und die Taktik ist verhandelbar, aber die Reihenfolge nicht. Setz dich mit der Arbeit auseinander, schließe die Arbeit ab, füttere das Produkt.
Wer das wirklich gut kann
Der Erfinder: Palantir betreibt noch immer die tiefste Version, und das Detail, das alle vergessen, ist, dass das Modell vor dem Produkt geboren wurde. Am Anfang gab es nichts zu konfigurieren, nur eine Wette, dass, wenn man lange genug in kaputten Institutionen sitzt, Produkte sich offenbaren. Das taten sie, und heute führt dasselbe Unternehmen kürzere, stärker schablonisierte Engagements durch, denn sobald das Produkt existiert, ist der Glaube an den Zinseszinseffekt die Religion.
Die neue Generation lässt sich am einfachsten in den Unternehmen für Kundendienstmitarbeiter lesen. Sierra betreibt seine Feldarbeit als Agent Engineers, und der Kreislauf ist bewusst. Löse es für einen Kunden, verbreite, was innerhalb des Unternehmens funktioniert hat, und hebe die Gewinner dann in die Plattform, so dass jeder Kunde sie erbt. Als ihre Ingenieure in Dutzenden von Einsätzen genau lernten, wann ein Agent aufhören sollte, es erneut zu versuchen, und den Kunden an einen Menschen übergeben sollte, wurde dieses Urteil zu einer wiederverwendbaren Komponente. Dann bauten sie Ghostwriter, einen Agenten, der das Bauen übernimmt, gefüttert mit Anrufprotokollen, SOPs und Whiteboard-Fotos, betrieben auf einer Plattform, die sie umarchitekturierten, so dass ein Agent sie direkt bedienen konnte. Eine Wette auf Sierra ist zu einem großen Teil eine Wette darauf, dass seine eingesetzten Teams weiterhin Workflows entdecken, die niemand sonst gesehen hat. Decagon ging den Systemweg, auditierte seine Einsätze auf Arbeit, die keinen Grund hatte, maßgeschneidert zu sein, schnitt die individuelle Entwicklung hinter jedem Agenten um achtzig Prozent und sagte dann das Unausgesprochene laut: dass die Auslieferung, nicht das Produkt, zum Graben wurde. Ramp besetzt sein Feldteam stark mit ehemaligen Gründern, weist sie auf den gesamten Kundenlebenszyklus vom ersten Anruf bis zum langfristigen Support und schärft vor allem eine Gewohnheit ein: Hinterfrage die Anforderung, bevor du sie baust, denn die genannte Bitte ist meist das Symptom, nicht die Krankheit.
Sobald du die Form kennst, siehst du sie in jeder ernsthaften Vertikale. Harvey bettet ehemalige praktizierende Anwälte in Anwaltskanzleien ein – der Beweis, dass die eingesetzte Person gar kein Ingenieur sein muss, sondern nur rechenschaftspflichtig. Im Finanzbereich besetzt Rogo fast die Hälfte des Unternehmens mit ehemaligen Bankern, die in die Institute eingesetzt werden, aus denen sie kamen, während Hebbia Ingenieure schickt, um die letzte Meile in den weltweit größten Vermögensverwaltern zu bauen. Abridge stellt Einsatz-Pods mit Krankenhaussystemen auf, denn einen KI-Schreiber zu zwölftausend Klinikern zu bringen ist keine Installation, sondern eine Kampagne. HappyRobot bettet sich bei Frachtmaklern ein, Gecko Robotics bringt Bauarbeiter auf Marineschiffe, Applied Intuition sitzt in den meisten großen Automobilherstellern der Welt, und Cursor (SpaceX) betreibt ein Vor-Ort-Team, das das Tool, das deine Ingenieure bereits lieben, in Banken und Telekommunikationsunternehmen verdrahtet.
Unterschiedliche Formen, eine Physik. Das Feld füttert die Fabrik, oder es ist kein Vor-Ort-Einsatz.
Das stärkste Gegenargument, denn es verdient eines
Es gibt ein Argument, dass dieser ganze Beruf eine Entschuldigung ist. Dir wurde eine Küche verkauft, die von allein kocht, und sie kam mit einem Koch, der jetzt in deinem Haus lebt, auf deiner Gehaltsliste, zum Aufschlag des Verkäufers, ohne Auszugsdatum. Der Pitch verlangt von dir, zwei Dinge gleichzeitig zu glauben: dass die Maschine brillant genug ist, dein Kochen zu ersetzen, und hilflos genug, um einen ständigen Betreuer zu brauchen. Wenn das Produkt einen ständigen Menschen braucht, ist das Produkt nicht fertig.
Nimm das ernst, denn für viele Verkäufer ist es einfach wahr. Der Test, der die Spezies trennt, ist derselbe, den dieser Artikel ständig wiederholt. Wenn der Mensch an der Lücke dauerhaft ist, gewinnt die Kritik, und du mietest einen Flicken. Wenn der Mensch an der Lücke sich verstärkt, Arbeit so abschließt, dass er sich selbst überflüssig macht, stirbt die Kritik beim zweiten Einsatz. Was sie übersieht, ist, dass der Großteil der Arbeit nie das Fertigstellen des Produkts war. Es ist die Aneignung des Kontextes. Die fünf undokumentierten Schritte, die unausgesprochene Intuition des Disponenten, der Gefallen, der zwischen Gebäuden getauscht wird. Kein fertiges Produkt wird jemals damit ausgeliefert, denn sie sind in jedem Unternehmen anders. Jemand muss sie holen gehen. Die einzige Frage, die zählt, ist, ob das Geholte sich zu einem Vermögenswert verdichtet oder in Rechnungen verdampft.
Wohin das führt
Vier Verschiebungen sind bereits im Gange.
Kontext wird zum Vermögenswert. Was ein eingesetztes Team bei jedem Kunden wirklich aufbaut, ist ein funktionierendes Modell davon, wie dieses Unternehmen läuft. Die Ontologie, der Zwilling, die Karte davon, wer was entscheidet und warum. Investoren haben begonnen, es das Unternehmensgehirn zu nennen, und der Name bleibt hängen, weil jedes Unternehmen eines brauchen wird. Mehr davon, als die Leute denken, kann schon vor dem ersten Flug gebootstrappt werden, denn Kunden geben ihre Wahrheit ständig preis – in Support-Tickets, Anrufprotokollen, E-Mails, Eskalationsfäden. Fang dort an. Aber die tiefste Schicht, das Wissen, das Menschen nicht verbalisieren können, erfordert immer noch Präsenz und Spiegel, Werkzeuge, die es Insidern ermöglichen, ihre eigene Intuition zu prüfen, bis sie zu Logik wird. Wer diese Karte hält, hält das Konto, was die Frage aufwirft, die jeder CEO bald jedem KI-Anbieter stellen wird: Ich miete die Intelligenz, aber wem gehört das Lernen? Wenn ein gemeinsames Modell die Krediturteile jedes Kreditgebers in einem Markt aufnimmt, trainiert der schärfste Underwriter im Pool seine Konkurrenten und bezahlt dafür. Es gibt einen Test, den jeder CFO durchführen kann. Tausche morgen auf dem Papier den Modellanbieter und prüfe, ob alles, was du dem System beigebracht hast, mit ihm zur Tür hinausgeht. Erwarte, dass sich Verträge, Teams und schließlich Unternehmen um eine einzige Zeile neu organisieren. Miete die Intelligenz, besitze das Lernen.
Agenten werden Teil des Teams. Der vor Ort eingesetzte Agent existiert bereits in frühen Formen. Onboarding-Agenten, die einen Nachmittag Integrationsarbeit in Minuten komprimieren. Einsatz-Agenten, die über Nacht ihre eigenen Transkripte lesen und Verbesserungen für ihre eigenen Fähigkeiten vorschlagen. Beobachte, was das mit der menschlichen Rolle macht. Jeder manuelle Eingriff hört auf, die Arbeit zu sein, und wird zu einem Trainingssignal, und die Aufgabe des Teams kehrt sich um: von der Durchführung von Einsätzen zum Betreiben der Fabrik, die Einsätze durchführt. Personalmodelle, wie Manager Leute einteilen. Bewertungen schreiben, wie Manager Beurteilungen schreiben. Die tiefere Umkehrung ist, wer der Benutzer ist. Produkte werden umgebaut, damit Agenten sie direkt bedienen können, und die erste Entdeckungsfrage bei einem Kunden ändert sich leise von Was braucht dein Team? zu Was braucht dein Agent? Derselbe Umschwung trifft die Umsatzseite, wo eine Person mit einer Agentenflotte jetzt die Pipeline betreibt, die früher eine ganze Etage von Leuten hatte, und Post-Sale-Software sich von Werkzeugen zu ergebnisverantwortlichen Dienstleistungen umbenennt – Retention as a Service heute, Expansion as a Service morgen. Und wenn die Agenten deiner Kunden anfangen, mit deinen Agenten zu verhandeln, werden die Menschen, die auf beiden Seiten des Tisches übrig bleiben, die beiden Dinge tun, die Kreisläufe nicht allein schließen können: entscheiden, was wünschenswert ist, und bescheinigen, dass es tatsächlich passiert ist.
Der Boden fällt weg. Einsätze, die vor ein paar Jahren fünf Millionen Dollar an Spitzenentwicklung kosteten, kosten jetzt ein paar hunderttausend und einen scharfen Generalisten mit guten Agenten, und der Preis fällt weiter. Vor-Ort-Einsatz hört auf, ein Fortune-500-Luxus zu sein, und wird zur Art, wie Mid-Market-Software verkauft wird. Die Einschränkung ist nicht mehr das Ingenieursangebot, sondern das Urteilsangebot.
Der Titel löst sich auf. Jeder Ingenieur bei einem ernsthaften Unternehmen wird teilweise zum Vor-Ort-Eingesetzten. Backend-Ingenieure sitzen in Kundenanrufen. Product-Ingenieure liefern gegen Anrufprotokolle aus. Bald ist der Prozentsatz der Zeit, die dem Kunden zugewandt ist, der einzige Unterschied zwischen einem FDE und einem Software-Ingenieur, und Titel werden aufhören, so zu tun, als wäre es anders. Was eine Warnung enthält, die niemand in die Stellenanzeigen schreibt. Diese Arbeit verwandelt Bauarbeiter in Diplomaten, und viele brillante Ingenieure haben sich gerade deshalb für das Bauen entschieden, weil Räume voller Fremder sie auslaugen. Respektiere den Introvertierten, indem du sie nicht einsetzt, und respektiere die Rolle, indem du sie niemals als Abstellgleis für Ingenieure benutzt, die mittelmäßig waren. Es ist das Gegenteil. Es ist der Ort, an den du die Leute schickst, denen du zutrauen würdest, etwas zu gründen.
Der älteste Job im Unternehmen
Streif die Terminologie ab, und der Vor-Ort-Einsatz ist die ursprüngliche Haltung des Gründers, die innerhalb eines Unternehmens am Leben erhalten wird, das groß genug wurde, um sie zu vergessen. Setz dich dorthin, wo die Arbeit ist. Schließe die Arbeit ab. Lass das, was du gelernt hast, verändern, was du baust. Jedes beständige Unternehmen hat das getan, bevor es einen Namen dafür hatte. Die meisten Unternehmen hören damit auf an dem Tag, an dem sie es sich leisten können, es nicht zu tun.
Die eigentliche Frage war also nie, ob man Vor-Ort-Ingenieure einstellen soll. Es ist, ob du bereit bist, ein Unternehmen zu führen, in dem die Menschen, die der Realität am nächsten sind, echte Macht haben, in dem Anstrengung nach ihrer Steigung beurteilt wird, und in dem nichts, was im Feld gelernt wurde, dort sterben darf. Baue das, und der Titel kümmert sich um sich selbst.
Was ist das letzte Stück Arbeit, das dein Team so vollständig abgeschlossen hat, dass der Kunde aufgehört hat, darüber nachzudenken? Wann hat ein Kunde zuletzt verlängert, nicht weil er den Wert aus deiner Produktpalette gezogen hat, sondern weil er weiß, dass du Dinge bauen wirst, von denen er nicht einmal wusste, dass er sie braucht, um sein Geschäft auszubauen? Fang dort an zu zählen.
