Welke vaardigheden heeft een Forward Deployed Engineer echt nodig?

Het rijtje uit de vacatures ken je waarschijnlijk al: full-stack bouwen, Python of TypeScript, SQL en databases, koppelingen, cloud, taalmodellen, en dan onderaan iets over communicatie. Hieronder leg ik dat rijtje langs de praktijk. Sommige punten kloppen precies, een paar staan er verkeerd om, en het belangrijkste ontbreekt.

Welke vaardigheden heeft een Forward Deployed Engineer nodig?

In vacatures staat een technisch rijtje: full-stack, Python of TypeScript, SQL, koppelingen, cloud en taalmodellen. Dat is de toegangseis, niet het vak. Wat het verschil maakt is dat je een vage vraag durft af te kappen, in gewone taal kunt uitleggen wat je bouwt, en nee zegt als iets niet nodig is.

Die technische eisen zijn dus geen onzin. Ze zijn de bodem waar je op staat. Alleen: iedereen die op zo’n vacature reageert heeft ze, en daarom beslissen ze niets. Het onderscheid ontstaat op het moment dat je bij een klant zit met een half probleem en een halve beschrijving.

Welke technische basis heb je echt nodig?

Genoeg om er in je eentje doorheen te komen. Je moet een database kunnen bevragen, een koppeling kunnen bouwen én kunnen repareren, iets kunnen neerzetten waar een mens op kan klikken, en het draaiend kunnen krijgen op een server. Kun je één van die vier niet, dan zit je te wachten op iemand anders.

Dat wachten is de kern van het probleem. Zit je bij een klant en moet je voor elke stap een collega bellen, dan valt het tempo weg dat dit werk juist zijn waarde geeft. De klant heeft niet gevraagd om een team; hij heeft gevraagd om iemand die het regelt.

SQL wordt hierin het meest onderschat. Bijna elk knelpunt dat ik tegenkom, is uiteindelijk een vraag over gegevens: waar staan ze, hoe vaak staan ze dubbel, en welke van de drie plekken heeft gelijk. Wie een database niet zelf kan doorzoeken, is afhankelijk van wat mensen zeggen dat erin staat. Dat klopt zelden helemaal.

Hoeveel AI-kennis is genoeg?

Minder dan de vacatures suggereren, en op een ander punt. Je moet weten wanneer een model geschikt is en wanneer je een formule wilt, hoe je zorgt dat het antwoord controleerbaar blijft, en waar het fout gaat. De diepe modelkennis heb je zelden nodig; de grens kennen wel.

Waar het bij mij in de praktijk om draait: mag dit onderdeel weleens fout zijn? Bij een bedrag is het antwoord nee, dus daar rekent een formule en geen model. Bij het lezen van een binnengekomen mail mag het weleens misgaan, want er kijkt nog iemand naar. Die scheiding aanbrengen is de vaardigheid, niet het opsommen van technieken.

Het tweede stuk is weten wanneer je een taak aan een agent geeft en wanneer niet, en hoe je een mens verantwoordelijk houdt voor wat er uitkomt. Daarover schreef ik apart wat een agent is en wanneer hij werkt. En dat je uit een model vooral het gemiddelde antwoord krijgt zolang je niet doorvraagt, staat bij waarom een model je het gemiddelde antwoord geeft.

Waarom is uitleggen zwaarder dan het lijkt?

Omdat je opdracht van mensen komt die je vakgebied niet spreken, en je uitkomst gebruikt wordt door mensen die er niet om vroegen. Kun je niet in gewone taal vertellen wat je bouwt en waarom, dan krijg je de verkeerde opdracht en daarna een systeem dat niemand gebruikt. Twee keer mis.

Mijn eigen lat: als iemand na een uur met mij niet kan navertellen wat we gaan doen, heb ik het slecht uitgelegd. Dat ligt dan aan mij. Vaktaal is daarbij het snelste middel om een gesprek te laten mislukken zonder dat iemand het merkt, want mensen knikken en vragen niet door.

Er hoort een tweede kant bij die minder vaak genoemd wordt: horen wat er níét gezegd wordt. Als iemand drie keer terloops dezelfde uitzondering noemt, is dat geen uitzondering maar de kern. Wie alleen luistert naar de vraag die gesteld wordt, bouwt netjes het verkeerde.

Welke vaardigheid staat in geen enkele vacature?

Stoppen. Kunnen zeggen dat iets niet gebouwd moet worden, dat het proces eerst opgeruimd moet, of dat het bestaande pakket prima voldoet. Dat kost je op dat moment omzet en het is precies waarom mensen je een tweede keer bellen. Er staat nergens een vinkje voor.

Het klinkt makkelijker dan het is. Op het moment dat iemand enthousiast is en jij het leuk vindt om te bouwen, moet je zeggen dat het niet loont. Ik moet daar zelf ook toe gedwongen worden, want een mooi technisch probleem trekt harder dan een verstandige rekensom.

Een tweede die nergens staat: doorzetten in de saaie fase. Het bouwen is het leuke deel. Erbij blijven terwijl mensen wennen, uitzonderingen opduiken en de eerste enthousiasteling met vakantie is — daar sneuvelen de meeste projecten. Dat hoort bij de vier taken die ik apart beschreef als de vier taken op een dag.

Welke vaardigheden worden overschat?

Kennis van specifieke gereedschappen. Vacatures noemen graag exacte technieken, en die zijn over twee jaar anders. Wie het onderliggende principe snapt, leert een nieuw gereedschap in een week. Wie alleen het gereedschap kent, staat stil zodra de klant iets anders gebruikt dan waar hij op geoefend heeft.

Ook overschat: architectuur voor de lange termijn. In productwerk is dat terecht belangrijk. Werk je voor één bedrijf aan iets dat over drie maanden moet draaien, dan is een net ontwerp dat te laat komt slechter dan een simpel ding dat werkt. Dat gaat tegen elke opleiding in en het is hier meestal waar.

Onderschat, en daarom noem ik hem hier: begrijpen hoe een bedrijf geld verdient. Weet je waar de marge zit en welke stap in het proces de omzet bepaalt, dan kies je bijna vanzelf het goede knelpunt. Weet je dat niet, dan bouw je wat het hardst geroepen wordt. Dat is zelden hetzelfde.

Wie doen dit werk opvallend vaak goed?

Mensen die gewend zijn een omweg te zoeken. Wat doe je als je bepaalde kleuren niet uit elkaar kunt houden? Je onthoudt de volgorde, je telt de plek, je bedenkt iets waardoor het tóch klopt. Wie dat jarenlang doet, raakt geoefend in het vinden van een deur die wél opengaat.

Dat is een waarneming en geen verklaring. Waaróm dat zo vaak samenvalt weet ik niet, en ik ga er geen onderzoek bij verzinnen. Wat ik wel zie is dat de gewoonte overblijft, en dat die gewoonte precies is wat dit vak vraagt — want je krijgt zelden een probleem waar de standaardroute op past.

Twee dingen horen daar expliciet bij. Je hebt zoiets niet nodig om goed te worden in dit werk: de meeste mensen die het goed doen hebben niets bijzonders. En andersom is het geen garantie. Het maakt je niet vanzelf iemand die verbanden ziet.

Wat een opdrachtgever koopt is dus geen kenmerk maar een gewoonte. Iemand die nooit de makkelijkste weg heeft kunnen nemen, is geoefend in het zoeken van de tweede. Als het makkelijk kon, kon iedereen het.

Hoe toets je dit bij iemand die je inhuurt?

Vraag naar het laatste project en blijf doorvragen. Wat stond er toen je binnenkwam, wat heb je gebouwd, wie gebruikt het nu, en wat is er misgegaan? Die laatste vraag is de beste. Wie niets kan noemen dat misging, heeft het niet zelf gedaan of vertelt het niet.

Een tweede vraag die veel losmaakt: waar heb je een keer nee gezegd tegen een klant, en hoe liep dat af? Daar hoor je meteen of iemand zijn eigen oordeel durft te gebruiken of vooral opdrachten uitvoert.

En laat je niet leiden door het aantal genoemde technieken. Een lijst met vijftien afkortingen zegt minder dan één verhaal over een koppeling die maandenlang stilletjes kapot was en hoe dat is opgelost. Wat koppelen in de praktijk inhoudt, staat bij wat koppelen echt inhoudt, en welke achtergronden mensen meenemen bij welke achtergrond mensen meebrengen.