{"id":3734,"date":"2026-07-31T10:35:46","date_gmt":"2026-07-31T08:35:46","guid":{"rendered":"https:\/\/www.pleus.net\/blog\/?p=3734"},"modified":"2026-07-31T21:14:58","modified_gmt":"2026-07-31T19:14:58","slug":"forward-deployed-engineer-das-schweizer-messer-der-softwareentwicklung","status":"publish","type":"post","link":"https:\/\/www.pleus.net\/blog\/?p=3734","title":{"rendered":"Forward Deployed Engineer – Das Schweizer Messer der Softwareentwicklung"},"content":{"rendered":"\n

Der Innovationsgrad der Softwareindustrie ist hoch. Regelm\u00e4\u00dfig entstehen neue Technologien und Methoden, die meist auf bestehendem aufbauen, mit dem Ziel die Herstellung von Software zu erleichtern und zu beschleunigen. Neue Methoden bringen oft neue Rollen hervor, die an die aktuelle Technologie- und Methodenlandschaft angepasst sind. Im Zuge agentischer Softwareentwicklung begegnen wir zunehmend der Rolle des Forward Deployed Engineer.<\/p>\n\n\n\n

Dieser Blogpost betrachtet diese Rolle aus verschiedenen Perspektiven und bettet sie ein in bestehende Strukturen. Dazu m\u00fcssen wir etwas ausholen:<\/p>\n\n\n\n

Rollen und Zusammenarbeit<\/h1>\n\n\n\n

Zu den klassischen Rollen, die wohl jeder kennt, geh\u00f6ren Analyst, Projektleiter, Architekt, Entwickler oder Tester. Diese Rollen sind eher zeitloser Natur und stammen aus einer Zeit in der Softwareentwicklung als prim\u00e4r industrieller Prozess verstanden wurde. Sie sind bis heute gebr\u00e4uchlich.<\/p>\n\n\n\n

Die agile Bewegung hat seit Beginn der 2000er Jahre moderne, angepasste Rollen wie Product Owner, Scrum Master, Release Train Engineer (SAFe), Flow Master (Kanban) oder Full Stack Developer und Data Scientist im Bereich der Technik und des maschinellen Lernens hervorgebracht, um nur einige hervorzuheben. Sie sind abgestimmt auf Arbeiten in komplexen Zusammenh\u00e4ngen, wie wir sie in Softwareentwicklungsprojekten in der Regel vorfinden.<\/p>\n\n\n\n

Im Kontext agentischer Softwareentwicklung erh\u00e4lt die Rolle des Forward Deployed Engineers und zunehmend an Aufmerksamkeit. Aber wozu definieren wir eigentlich Rollen?<\/p>\n\n\n\n

Grunds\u00e4tzlich dienen Rollen dem Zweck Aufgaben und Verantwortlichkeiten zu benennen, damit jeder, zum Beispiel im Rahmen eines Projektes, genau wei\u00df was zu tun ist. Zudem erleichtern diese Schablonen die Beschreibung von Aufgabenfeldern im Rahmen der Personalgewinnung.<\/p>\n\n\n\n

So hilfreich diese Schablonen sein k\u00f6nnen, um Klarheit in die Personalstruktur und Erwartungshaltungen zu bringen, so hinderlich k\u00f6nnen sie sein, wenn es darum geht Projektziele zu erreichen. Wer schon einmal den Satz “Das ist nicht meine Aufgabe” geh\u00f6rt hat, wei\u00df, was damit gemeint ist.<\/p>\n\n\n\n

Im Sinne einer gemeinschaftlichen und kooperativen Zusammenarbeit geht es weniger darum Rollen zu erf\u00fcllen, sondern anstehende Aufgaben mit den vorhandenen F\u00e4higkeiten zu erledigen. Dabei spielt es eine untergeordnete Rolle, ob beispielsweise Softwaretests von Analysten, Architekten oder Entwicklern durchgef\u00fchrt werden oder User Stories vom Product Owner oder Tester geschrieben werden. Es geht um das zu erreichende Ziel, nicht um die Erf\u00fcllung von Rollen. Teams mit hoher Kompetenz\u00fcberlappung sind dadurch flexibler, resilienter und schneller, weil es weniger Wartezust\u00e4nde an den Rollen\u00fcberg\u00e4ngen gibt.<\/p>\n\n\n\n

Die Idee des crossfunktionalen Arbeitens und Anwendern\u00e4he zieht sich wie ein roter Faden durch den Werkzeugkasten moderner Methoden. Wir finden es gleicherma\u00dfen in agilen Frameworks, DevOps oder auch Design Thinking. Konsequent gedacht arbeiten die Personen der Softwareentwicklung direkt mit Anwendern zusammen. Sie sehen und erfahren aus erster Hand, wie die Anwender arbeiten und beziehen sie stark mit ein. Ein Ansatz den wir beispielsweise in den Service Safaris des Design Thinking finden. L\u00f6sungsans\u00e4tze werden direkt mit den Anwendern entwickelt und bewertet. Begriffe daf\u00fcr kennen wir schon. Beispielsweise Embedded-IT, Customer Engineer, On-site-Engineer oder Field Engineer geh\u00f6ren dazu. In der Praxis sehen wir das eher selten. Vermutlich liegt es daran, das sie nicht gut in bestehende Aufbauorganisationen passen. Eine Faktor, der auch bei Forward Deployed Engineers eine Rolle spielt.<\/p>\n\n\n\n

Was ist nun ein Forward Deployed Engineer?<\/h1>\n\n\n\n

Ein Forward Deployed Engineer (FDE) oder auch Forward Deployed Software Engineer ist ein Software Engineer mit maximaler Anwendern\u00e4he. Der Name der Rolle ist entstanden im Umfeld der gro\u00dfen AI Anbieter, die einen Weg suchten Softwarel\u00f6sungen auf schnelle Art mit Hilfe von AI zu entwickeln. Entlehnt dem Milit\u00e4rjagon bedeutet es soviel wie Einsatz an der Front, was mir nicht sehr passend erscheint, da FDEs in Organisationen eher im Freundesland agieren. FDEs entwickeln Software innerhalb einer Organisation mit gro\u00dfer N\u00e4he zu den Fachbereichen und ausgepr\u00e4gter Hands-On Ausrichtung. Die Rolle kombiniert viele F\u00e4higkeiten mit dem Ziel passgenaue Software in k\u00fcrzester Zeit zu erstellen.<\/p>\n\n\n\n

Zu den zentralen F\u00e4higkeiten geh\u00f6ren:<\/p>\n\n\n\n

\ud83d\udd39Anforderungsanalyse
\ud83d\udd39Konzeption und Softwareentwicklung
\ud83d\udd39Software Engineering
\ud83d\udd39AI Harness Engineering
\ud83d\udd39Soziale und kommunikative F\u00e4higkeiten
\ud83d\udd39Empathie, Neugier, Flexibilit\u00e4t, Lernbereitschaft
\ud83d\udd39Pr\u00e4sentation und Moderation<\/p>\n\n\n\n

Wie wir sehen ist die Rolle ist sehr breit angelegt und umfasst viele F\u00e4higkeiten. In der Regel wird sie von Personen ausgef\u00fcllt die \u00fcber ein PI-Profil charakterisiert sind. Also Generalisten mit partiellen Spezialisierungen und der F\u00e4higkeit sich in kurzer Zeit in neue Themen, seien sie fachlich oder technisch, einzuarbeiten. Wie bei einem Schweizer Messer vereinen sich viele Funktionen in einem Werkzeug. Eine Rolle, die nur von sehr erfahrenen Engineers ausgef\u00fcllt werden kann.<\/p>\n\n\n\n

Obwohl die Erfinder dieser Rolle sicher AI als treibende Kraft im Sinn hatten, ist der Einsatz agentischer Techniken eigentlich nicht zwingend. Jedoch beschleunigt der Einsatz von AI in dieser Rolle die Erstellung von Artefakten und hilft dabei schnell zu L\u00f6sungen zu kommen. Insbesondere bei Aufgaben, die nicht unmittelbar final produktionsf\u00e4hige Software betreffen, wie beispielsweise Fachliche- und Codeanalyse, Prototyping, Visualisierung oder Sparring, ist AI ein Werkzeug, um die Entwicklung digitaler Produkte stark zu beschleunigen und die Passung zu erh\u00f6hen.<\/p>\n\n\n\n

Diese Aufgaben charakterisieren die T\u00e4tigkeit eines FDE:<\/p>\n\n\n\n

\ud83d\udd39Analyse und Dokumentation fachlicher Anforderungen
\ud83d\udd39Analyse bestehender Codebasen
\ud83d\udd39Context und Harness Engineering
\ud83d\udd39Erstellung technischer L\u00f6sungskonzeptionen
\ud83d\udd39Erstellung von Prototypen und Machbarkeitsstudien
\ud83d\udd39Entwicklung produktionsreifer L\u00f6sungen
\ud83d\udd39Anwendung agiler und agentischer Entwicklungsmethoden
\ud83d\udd39Beratung zu technischen und methodischen Fragestellungen
\ud83d\udd39Pr\u00e4sentation von Ergebnissen auf allen Ebenen der Organisation<\/p>\n\n\n\n

Der wesentliche Faktor ist dabei die N\u00e4he zu den Anwendern, hohe Transparenz, sowie schnelle R\u00fcckkopplungsschleifen. Prinzipien, die wir aus dem agilen Werkzeugkasten als Inspect & Adapt kennen und die sich vielfach bew\u00e4hrt haben.<\/p>\n\n\n\n

Herausforderungen<\/h1>\n\n\n\n

Forward Deployed Engineers erfordern hohen Gestaltungsspielraum, Experimentierfreude und schnelle Entscheidungen. In Organisationsstruktur und Kulturen, in denen das nicht gegeben ist, k\u00f6nnen FDEs ausgebremst werden und keine starke Wirkung entfalten. Eine Build-To-Learn-Kultur ist f\u00fcr viele noch immer ungewohnt. Es ist zu kl\u00e4ren, wie weit die Bereitschaft dazu reicht.<\/p>\n\n\n\n

Insbesondere bei intensivem Einsatz von AI besteht das Risiko von Wissenserosion und kognitiver Schulden. Es ist darauf zu achten, das insbesondere gesch\u00e4ftskritische Artefakte von den Mitarbeitenden verstanden und ohne den Einsatz von AI gepflegt und weiterentwickelt werden k\u00f6nnen. Dies kann durch Context Engineering erreicht werden, welches das Ziel verfolgt Wissen und Wahrheit f\u00fcr Menschen und Maschinen gleicherma\u00dfen zu strukturieren und zug\u00e4nglich zu machen.<\/p>\n\n\n\n

Die Qualit\u00e4t der entstehenden Software ist von Menschen sicherzustellen, damit sie die M\u00f6glichkeit haben Verantwortung f\u00fcr die Software zu \u00fcbernehmen und in kritischen Situationen zu agieren. Statt m\u00f6glichst schnell m\u00f6glichst viel Code zu erzeugen ist darauf zu achten, das die Menschen des soziotechnischen Systems Verantwortung \u00fcbernehmen k\u00f6nnen. Das Prinzip des Sustainable Pace, also nachhaltiger Liefergeschwindigkeit gilt auch hier.<\/p>\n\n\n\n

Da die Entwicklung zusammen mit den Anwendern der Fachbereiche beziehungsweise Dom\u00e4nen erfolgt, liegt der Fokus zun\u00e4chst auf lokalen L\u00f6sungen. Es ist zu beachten, in wie weit sich diese in die bestende Produkt- und Systemlandschaften einf\u00fcgen und wie sich statt Insell\u00f6sungen integrative Ans\u00e4tze erreichen lassen.<\/p>\n\n\n\n

Einsch\u00e4tzungen<\/h1>\n\n\n\n

Insgesamt erscheint der Forward Deployed Engineer eine sinnvolle Rolle, um dem Ziel guter Software in kurzer Zeit n\u00e4her zu kommen. AI kann bei vielen Aufgaben sinnvoll unterst\u00fctzen. Im Kern steht die enge und vertrauensvolle Zusammenarbeit der Menschen im System der Softwareentwicklung. Dieser wichtige Aspekt ist im agilen Kontext seit langem bekannt und nachgewiesenerma\u00dfen ein entscheidender Erfolgsfaktor. Das passt also. FDEs sind Senior Engineers die eingebettet bei und mit den Kunden arbeiten. Gewisserma\u00dfen sind Forward Deployed Engineers wie ein Schweizer Messer, da sie viele F\u00e4higkeiten in sich vereinen. Diese Rolle ist anspruchsvoll. Sie auszuf\u00fcllen erfordert viel Erfahrung und Seniorit\u00e4t. Ein Faktor, der die Besetzung sicher nicht erleichtert.<\/p>\n\n\n\n

Vielleicht ergeben sich durch Forward Deployed Engineers und dem Schwung des Themas neue M\u00f6glichkeiten die Kultur der Softwareentwicklung weiter zu verbessern und das immerw\u00e4hrende Ziel zu erreichen: Nutzenbringende Software herzustellen. In hoher Qualit\u00e4t und kurzer Zeit.<\/p>\n\n\n\n

Was kann PLEUS Consulting tun?<\/h2>\n\n\n\n

Seit \u00fcber 30 Jahren unterst\u00fctzen wir Unternehmen in allen Phasen des Software Delivery Lifecycles. Wir wissen aus Erfahrung das intensive, vertrauensvolle Zusammenarbeit der Schl\u00fcssel ist. Wir durften es vielfach erleben und gestalten. Oft haben wir direkt mit den Anwendern der Fachbereiche gearbeitet und gemeinsame Erfolgsgeschichten geschrieben. Durch die Unterst\u00fctzung von Startups und DAX-Konzernen in verschiedenen Branchen sind wir mit den kulturellen Unterschieden in den Unternehmen bestens vertraut und stellen uns auf deren Besonderheiten ein.<\/p>\n\n\n\n

Durch unsere langj\u00e4hrige Erfahrung und systemisch-agile Haltung sind wir der ideale Partner wenn es darum geht anspruchsvolle Software im gesch\u00e4ftskritischen Umfeld zu entwickeln.<\/p>\n\n\n\n

\n\n\n\n

Der Autor setzt AI situativ ein wo es Sinn macht. Dieser Text ist vollst\u00e4ndig ohne Einsatz von AI entstanden. Warum? Schreiben ist Denken! Denken macht Spa\u00df! Innovation entsteht nicht durch Replikation! Kreatives und systemisches Denken vergr\u00f6\u00dfert den L\u00f6sungsraum!<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Headerbild von Clker-Free-Vector-Images auf Pixabay<\/p>\n","protected":false},"excerpt":{"rendered":"

Der Innovationsgrad der Softwareindustrie ist hoch. Regelm\u00e4\u00dfig entstehen neue Technologien und Methoden, die meist auf bestehendem aufbauen, mit dem Ziel die Herstellung von Software zu erleichtern und zu beschleunigen. Neue Methoden bringen oft neue Rollen hervor, die an die aktuelle Technologie- und Methodenlandschaft angepasst sind. Im Zuge agentischer Softwareentwicklung begegnen wir zunehmend der Rolle des … Continue reading Forward Deployed Engineer – Das Schweizer Messer der Softwareentwicklung<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":3753,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7,120,6,119],"tags":[125,74,121,124,123],"class_list":["post-3734","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-agile","category-ai","category-scrum","category-system-engineering","tag-agentisch","tag-agile","tag-ai","tag-forward-deployed-engineer","tag-harness-engineering"],"_links":{"self":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3734"}],"version-history":[{"count":52,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3734\/revisions"}],"predecessor-version":[{"id":3794,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/posts\/3734\/revisions\/3794"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=\/wp\/v2\/media\/3753"}],"wp:attachment":[{"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.pleus.net\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}