Forward deployed engineers: de populairste baan in AI en het moderniseringswerk dat niet kan worden overgeslagen

Voor iedereen die een moderniseringsprogramma leidt, bevestigt het FDE-verhaal iets wat we al een tijd zeggen. Het model is allang niet meer het moeilijke deel. De staat van de systemen, de data en de processen waarop het model aansluit, is wat projecten nog steeds doet stranden, en geen enkele ingebedde engineer verandert daar iets aan door simpelweg te komen opdagen. Daarom is de vraag die bepaalt of een FDE-traject slaagt niet hoe goed de engineer is. De vraag is of de organisatie het geheel na diens vertrek nog steeds kan draaien.

Bronnen: CIO.com en De nieuwe stack

Samenvatting

Binnen een periode van tien dagen in mei ging de forward deployed engineer van niche naar voorpagina. OpenAI lanceerde een Deployment Company van 4 miljard dollar, Google Cloud stelde tientallen FDE-functies open met salarisschalen tot 265.000 dollar, Anthropic plaatste engineers binnen financiële technologieleverancier Fidelity National Information Services (FIS) om samen een agent tegen witwassen te bouwen, en ServiceNow en Accenture startten een gezamenlijk FDE-programma. Een columnist van The New Stack presenteerde de rol als de meest duurzame nieuwe carrière binnen AI en schetste er een opleidingstraject voor. Een auteur bij CIO.com las dezelfde gebeurtenissen en zag een afhankelijkheid ontstaan, met een citaat van een Gartner-analist die voorspelt dat zeventig procent van de ondernemingen in 2028 agentic AI-projecten die op deze manier zijn opgeleverd, zal stopzetten, omdat de leverancierskosten hoog blijven en interne teams nooit leren om te beheren wat er is gebouwd. We bespraken beide stukken met Kishan Chamman, onze CTO.

Beoordeling en inzichten

Een functietitel voor iets dat al bestond. Ondanks alle ophef eromheen is de FDE geen nieuw soort mens. Kishans beschrijving voor de camera was onomwonden. Een FDE zit dicht tegen een fullstack-engineer aan die daarnaast kennis van business en processen meebrengt en een idee binnen een bedrijf kan verkopen. De markt nam de multidisciplinaire engineer, degene die tegelijk een framework en de business begrijpt, gaf die combinatie een naam en hing er een seniorsalaris aan. Goed om te weten, want het betekent dat het aanbod dun is en de rol lastig te veinzen valt.

De 20 procent die het in een demo goed doet en de 80 procent die dat niet doet. Eén zin uit de berichtgeving is ons allebei bijgebleven: een demo draaiend krijgen in een sandbox is ruwweg een vijfde van het werk. De rest bestaat uit enterprise single sign-on, verouderde extract-transform-load-pijplijnen, beperkingen vanuit regelgeving en het lospeuteren van productiecredentials bij een securityteam. Kishans versie, opgebouwd uit jaren van implementaties bij enterprises en overheden, luidt dat het bouwen van het systeem nooit de plek was waar projecten sneuvelen. Ze sneuvelen in het ecosysteem eromheen, in de maanden die het kost om stakeholders het eens te laten worden over wat er gebouwd wordt en waarom.

Dienstverlening, geen software. Het CIO-artikel bevat de helderste herkadering van het moment. CIO's denken dat ze software kopen. Wat er landt, is een professional services-opdracht, met een ander kostenmodel, een ander afhankelijkheidsmodel en een ander governancemodel. Wanneer een leverancier zegt dat elke beslissing van een agent auditeerbaar en traceerbaar is, klopt dat en is het tegelijk niet ter zake. De moeilijkere vraag is welke beslissingen überhaupt bij de agent thuishoren, en banken hebben decennia besteed aan het opbouwen van kaders voor beslissingsbevoegdheid die niet aansluiten op een agent harness die door de engineers van iemand anders is geschreven.

De toets die er werkelijk toe doet. Een lid van de Coalition for Secure AI leverde het beste idee uit het CIO-artikel, en wij hebben het meteen overgenomen. Kan de organisatie, nadat het forward deployed team is vertrokken, de workflow bedienen, monitoren, ter discussie stellen en veilig aanpassen? Als het antwoord nee is, dan is er een geslaagd implementatieproject en nog geen capaciteit. Een Gartner-analist plakt een getal op hoe vaak het antwoord nee is: zeventig procent van dit soort opdrachten wordt vóór 2028 gestaakt. Kishans beeld uit de praktijk komt in dezelfde orde uit of slechter. Hij schat dat zeventig tot tachtig procent van de bedrijven op die toets zal falen, achterblijvend met een agent die ze niet kunnen onderhouden en betalend aan de leverancier om die in leven te houden.

De factuur, en wie hem heeft opgesteld. Dit is het deel waar een CTO van rechtop moet gaan zitten. Een onafhankelijke analist die in het CIO-artikel wordt geciteerd, benoemt een belangenconflict dat midden in het hele model zit. De leverancier die betaald wordt om de complexiteit te temmen, is vaak dezelfde leverancier wiens model die complexiteit heeft veroorzaakt. Als het verdienmodel draait op ingebedde engineers die uren schrijven om agents in leven te houden, waar zit dan de prikkel om agents te leveren die capabel genoeg zijn om hen niet nodig te hebben? Het is redelijk om aan te nemen dat sommige van deze aanbiedingen bewust zo zijn vormgegeven dat de engineer binnenboord blijft. De hoofdanalist van Greyhound Research verwoordde het scherper en omschreef het resultaat als "afhankelijkheid met mooier briefpapier".

Versie één en versie twee. Hoe neemt een organisatie de hulp dan aan zonder de afhankelijkheid mee te kopen? Kishan liep door hoe we dit bij Eli5 afbakenen, en dat is het duidelijkste antwoord dat we hebben op de CIO-toets. Begin met het vinden van de waarde in plaats van de techniek. Schets goedkope prototypes voor een handvol use cases, scoor ze op inspanning tegenover waarde, en pak de combinaties van lage inspanning en hoge waarde als eerste op. Lever vervolgens bewust in twee versies. Versie één is de snelle winst die aantoont wat de tooling kan ontsluiten, snel uitgerold en nog niet verweven met het bedrijf. Versie twee is de ingebedde versie die er daarachter aan wordt gewerkt, de versie die komt met de procesveranderingen, de interne ondersteuningsstructuur en de opleiding waarmee de eigen mensen van de klant ermee kunnen werken. De regel waar we ons aan houden, is dat we versie één nooit afbakenen zonder versie twee. Iets bouwen dat de klant niet kan bedienen, is precies hoe een project in die zeventig procent belandt.

De link met modernisering

Dit sluit direct aan op het werk waar we onze dagen aan besteden. De reden dat zoveel van deze opdrachten instorten zodra de engineers vertrekken, is niet de agent. Het is alles onder die agent waar niemand aan heeft gezeten. Ongedocumenteerde bedrijfslogica, versnipperde data, brosse integraties en processen die nooit zijn ontworpen voor software die zelfstandig handelt. AI-tooling leunt op accurate data en een accuraat beeld van het landschap, en de meeste organisaties hebben geen van beide vastgelegd. Zet tien briljante engineers in die situatie en ze bouwen iets dat prachtig aansluit op wat er al staat. Laat het een maand draaien zonder het onderliggende proces te veranderen en het breekt. De FDE neemt het moderniseringswerk eronder niet weg, het maakt het overslaan van dat werk alleen duurder.

Hetzelfde verhaal speelde zich af bij digitale transformatie. Het aanschaffen van de tool zou het bedrijf repareren. Dat gebeurde niet, omdat niemand de processen veranderde of de mensen meenam. Vervang het woord transformatie door AI en de faalmodus is identiek.

Afsluitende opmerkingen

De forward deployed engineer is een echte rol met echt werk, en de salarissen zijn geen zeepbel zoals prompt engineer dat in 2023 was. De vraag is oprecht, want een agent uitrollen binnen een draaiende onderneming is lastiger dan de meeste mensen verwachten. Wat niet is veranderd, is wat eronder ligt. Voordat welk model dan ook zijn geld waard is binnen een organisatie, moet iemand nog altijd de legacysystemen, de rommelige data en de workflows aanpakken die nooit gebouwd zijn voor intelligente software. Dat werk gaat niet sneller doordat een leverancier een engineer stuurt met een beroemd logo achter zich.

Voor een CTO of PO die hiernaar kijkt, zijn er twee stappen die beter vermeden kunnen worden. Niets doen is de ergste. Daar vlak achteraan komt het tekenen van een opdracht bij één enkele leverancier voordat de organisatie haar eigen stack begrijpt, want de eerste engineer die aanschuift bepaalt meteen de standaardkeuzes voor welk model, welke tools en welke integraties de organisatie uiteindelijk aan zich bindt. Zorg eerst voor een onafhankelijke blik op de systemen. Breng in kaart welke workflows klaar zijn om rond AI te worden herbouwd en welke eerst modernisering nodig hebben voordat iemand eraan begint. Bepaal daarna wie de pen vasthoudt, en zorg ervoor dat de getekende overeenkomst iets oplevert dat het team zelfstandig kan draaien.

Volledige video-aflevering: Forward deployed engineers: de populairste baan in AI en het moderniseringswerk dat daarbij niet kan worden overgeslagen

De eerste stap om de moderniseringsreis te starten

Softwaremodernisering en architectuurherbouw vormen de kern van Eli5. Wij lossen complexiteit op en leveren directe zakelijke waarde door te focussen op pragmatische, cloud-native transities.

Voordat wordt besloten om een legacysysteem in te kapselen, een nieuw SaaS-product aan te schaffen of AI in te zetten om maatwerktools te bouwen, is volledig zicht op het huidige technologielandschap essentieel.

Interesse in het inplannen van een gratis brainstorm over de legacy stack? Dat is de essentiële eerste stap om technische schuld om te zetten in een schaalbare, modulaire toekomst.