Een Forward Deployed Engineer inhuren of aannemen?

Dit is een vraag die grote bedrijven anders beantwoorden dan mkb-bedrijven, en het antwoord hangt minder van je omvang af dan van één ding: is er over een jaar nog werk voor deze persoon, en werk waar hij zin in heeft?

Kun je een Forward Deployed Engineer beter inhuren of in dienst nemen?

Inhuren past als er een periode is waarin iets moet gaan draaien en daarna niet meer. Aannemen past als er blijvend werk ligt voor iemand die bouwt én met je mensen praat. In het mkb is dat tweede zelden het geval, want zo iemand verveelt zich zodra het draait.

Die laatste zin is geen grap. Het is de belangrijkste reden waarom vaste dienstverbanden hier misgaan, en hij wordt bijna nooit meegenomen in de afweging. Ik ken het van mezelf: zodra iets af is, wordt het saai en ga ik het verbeteren terwijl niemand daarom vroeg. Dat is prettig in de opbouwfase en waardeloos in de beheerfase.

Waarom lukt het mkb het zelden om er iemand voor aan te nemen?

Omdat de functie in een bedrijf van twintig man na een half jaar leegloopt. De eerste maanden zijn er drie processen die pijn doen; die worden opgelost. Daarna resteert beheer, en beheer is ander werk voor een ander type mens. Je houdt een dure kracht over die zich verveelt.

Er is nog een praktisch punt. Iemand die dit kan, kiest zijn opdrachten. Hij wil afwisseling, hij wil zelf beslissen wat er gebouwd wordt, en hij wil niet de enige technische persoon in een bedrijf zijn waar hij niemand heeft om iets tegenaan te gooien. Dat maakt werven lastig, ook als je bereid bent goed te betalen.

Grote bedrijven hebben dat probleem minder, want daar staan altijd drie nieuwe afdelingen in de rij. Zit je daar tussenin, dan is een deeltijdconstructie soms het antwoord: iemand die een vaste dag per week komt en de rest van de week elders werkt.

Wat gebeurt er als je iemand aanneemt en het werk opdroogt?

Dan verlies je hem, of erger: hij blijft en gaat systemen bouwen die niemand nodig heeft. Dat tweede is het duurdere scenario, want je merkt het pas als er drie eigen systemen draaien waar alleen hij mee overweg kan. Vanaf dat moment ben je afhankelijk van één persoon.

Ik zie dat regelmatig bij bedrijven die ooit “hun eigen IT’er” aannamen. De man of vrouw in kwestie doet niets verkeerd; er is gewoon niemand die stuurt op wat er wél en niet gebouwd wordt. Na een paar jaar staat er een eigen wereldje waar niemand anders in thuis is, en is vertrek van die persoon een bedrijfsrisico geworden.

Wie toch aanneemt, doet er goed aan om vanaf dag één te eisen dat alles wat gebouwd wordt door een tweede persoon te begrijpen is. Niet als documentatieproject, wel als gewoonte: iemand anders moet het een keer hebben aangeraakt.

Waarom noem ik hier geen tarief?

Omdat ik geen Nederlands cijfer heb dat ik kan onderbouwen. De functietitel is hier zo jong dat er te weinig vacatures zijn om een betrouwbaar beeld uit te halen, en de bedragen die uit Amerika overwaaien komen uit een andere markt met andere lonen. Een getal noemen zou hier gokken zijn.

Wat ik wel kan zeggen over de kostenkant: de bouwuren zijn zelden de grootste post. Dat is jouw eigen tijd. Iemand in je bedrijf moet uitleggen hoe het werk nu loopt en de eerste weken meekijken of de uitkomst klopt. Reken daar mee, want het is het deel dat mensen structureel vergeten.

En reken op onderhoud. Elk systeem vraagt erom: pakketten veranderen, wachtwoorden verlopen, een leverancier past zijn koppeling aan. Wie dat niet meeneemt in de som, vergelijkt de bouwprijs met de verkeerde uitkomst.

Hoe lang heb je zo iemand nodig?

Korter dan een jaar, in de meeste mkb-gevallen. Het patroon is telkens hetzelfde: een intensieve periode waarin er iets ontstaat en gebruikt gaat worden, daarna een rustiger staart waarin er alleen nog bijgestuurd wordt. Die staart mag dun zijn, maar hij mag niet nul zijn.

Die staart overslaan is de klassieke fout. Een systeem is niet af op de dag van oplevering; het is af als het drie maanden heeft meegedraaid met echte drukte, echte uitzonderingen en de collega die met vakantie was toen het werd uitgelegd. Wie op de opleverdag de deur dichtdoet, betaalt het verschil later terug in gedoe.

Wat moet je zelf op orde hebben voordat inhuren zin heeft?

Drie dingen, en ze zijn alle drie van jou. Iemand in het bedrijf die vragen mag beantwoorden zonder eerst drie weken agenda-overleg. Toegang tot je systemen, geregeld en niet beloofd. En een besluit dat je wilt nemen, zodat er iets te bouwen valt in plaats van te onderzoeken.

Ontbreekt de eerste, dan kost alles vier keer zo lang. Ontbreekt de tweede, dan sta je te wachten op een leverancier die pas over zes weken tijd heeft. En ontbreekt de derde, dan krijg je precies het traject dat je niet wilde: een onderzoek dat uitmondt in een advies.

Er is een vierde die minder hard is maar wel telt: de bereidheid om te horen dat het antwoord nee is. Bij lage aantallen, rommelige gegevens of een proces dat eerst opgeruimd moet worden, is bouwen de dure route. Wanneer dat zo is, staat bij wanneer je er niet aan moet beginnen.

Hoe voorkom je dat je afhankelijk wordt van één persoon?

Door dat aan het begin af te spreken in plaats van aan het eind. Leg vast waar de code staat, wie er nog meer bij kan, en welke wachtwoorden op naam van het bedrijf staan. Vraag ook wat er gebeurt als je morgen met iemand anders verder wilt. Een eerlijk antwoord daarop zegt genoeg.

Wat ik zelf als maatstaf aanhoud: iemand die na twee jaar nog steeds onmisbaar is, heeft slecht opgeleverd. Het doel is een bedrijf dat verder kan, niet een klant die moet blijven bellen. Dat klinkt tegen het eigenbelang in en op de korte termijn is dat ook zo.

Zorg daarnaast dat je zelf begrijpt wat er draait. Niet technisch, wel functioneel. Kun je in drie zinnen navertellen wat het systeem doet en waarom, dan ben je bestand tegen het vertrek van wie dan ook.

Wanneer moet je dit juist niet inhuren?

Als je eigenlijk iemand anders zoekt. Ligt de opdracht al vast tot in de details, dan wil je een ontwikkelaar. Is de vraag groter dan techniek, dan wil je een adviseur. En past een standaardpakket goed op je proces, hou dat dan en koppel het hooguit aan de rest.

Ook niet doen als er nog geen enkel proces is aangewezen. “Iets met AI” of “wij moeten digitaliseren” is geen opdracht; daar begint elk mislukt project mee. Kies eerst één proces dat elke week terugkomt en dat irriteert. Hoe je dat aanpakt, staat bij AI werkend krijgen in een mkb-bedrijf.

Twijfel je nog welke van de drie soorten mensen je zoekt, dan helpt of je eigenlijk iemand anders zoekt. Wil je eerst zien wat het werk inhoudt of nalezen wat zo iemand doet, dan kan dat daar.