Forward Deployed Engineer, consultant of ontwikkelaar?

Deze pagina is voor wie moet kiezen wie hij belt. Niet voor wie een functietitel zoekt. Er is iets in je bedrijf dat beter kan, je weet niet precies wat je nodig hebt, en de drie soorten mensen die zich melden klinken verdacht hetzelfde aan de telefoon.

Wat is het verschil tussen een Forward Deployed Engineer, een consultant en een softwareontwikkelaar?

Een consultant levert een advies en vertrekt. Een softwareontwikkelaar bouwt wat er in de opdracht staat. Een Forward Deployed Engineer bepaalt zelf wat er gebouwd moet worden, bouwt het, en blijft tot het bij jou draait. Het verschil zit niet in kennis maar in wie het resultaat op zijn bord krijgt.

Alle drie kunnen ze goed zijn in hun vak. Het gaat hier niet over wie de slimste is. Het gaat over waar de opdracht ophoudt, want dat bepaalt wat er van jou verwacht wordt zodra ze weer weg zijn.

Wanneer is een consultant de betere keuze?

Als je een vraag hebt die groter is dan één systeem. Moet je een markt op, een organisatie verbouwen of een keuze maken die jaren doorwerkt, dan wil je iemand die dat vaker heeft gezien en die het naast elkaar kan leggen. Daar hoort een advies bij, geen code.

Er is nog een geval waarin het advies precies goed is: als je zelf de uitvoering aankunt. Bedrijven met een eigen IT-afdeling hebben soms alleen een buitenstaander nodig die zegt welke van de drie richtingen de minst slechte is. De rest doen ze zelf, en beter dan een invalkracht.

Waar het misgaat, is als het rapport ook de uitvoering had moeten zijn. Een adviesrapport kan volledig gelijk hebben en toch niets veranderen. Dat is geen kritiek op consultants; het is een eigenschap van rapporten.

Wanneer heb je gewoon een ontwikkelaar nodig?

Als al vaststaat wat er moet komen. Weet je precies welk scherm, welke koppeling of welke functie je wilt, dan wil je iemand die dat goed en degelijk bouwt. Dan is meedenken over de vraag niet nodig en betaal je er alleen maar voor.

Dit is vaker het geval dan mensen denken. Een webshop uitbreiden, een bestaande koppeling verbouwen, een app onderhouden: dat is bouwwerk met een duidelijke opdracht. Wie daar iemand op zet die het gesprek ingaat over de bedrijfsstrategie, maakt het onnodig duur en langzaam.

De valkuil zit aan de voorkant. Als jij de opdracht opschrijft en de opdracht klopt niet, dan krijg je precies wat je vroeg. Dat is dan geen fout van de ontwikkelaar. Er zijn genoeg keurig gebouwde systemen die niemand nodig had.

Wanneer is een Forward Deployed Engineer de juiste?

Als je wel weet dat er iets knelt, maar niet welke opdracht daaruit volgt. Dan heb je iemand nodig die naast je mensen gaat zitten, zelf ziet waar het weglekt, en dezelfde week iets bouwt om te kijken of dat klopt. Uitzoeken en bouwen zijn hier niet twee fasen maar één beweging.

Het tweede geval: je hebt al iets aangeschaft dat niet gebruikt wordt. Een pakket, een pilot, een AI-proef die na de demo is blijven liggen. Daar zit meestal geen technisch probleem maar een afstand tussen wat het ding kan en hoe mensen werken. Iemand die alleen bouwt lost dat niet op en iemand die alleen adviseert ook niet.

Zo ging het bij een bedrijf waar de offertes en de bijbehorende stukken alle kanten op gingen. Niemand had daar om software gevraagd; het was gewoon rommelig geworden. Wat er nodig bleek, staat bij een proces dat alle kanten op ging. En hoe zo’n dag er praktisch uitziet, staat bij hoe zo’n dag eruitziet.

Waarom lopen deze rollen in vacatures door elkaar?

Omdat de titel populair werd en er van alles onder geplakt wordt. Er staan inmiddels vacatures online met Forward Deployed Engineer boven een functie die neerkomt op klantondersteuning of op het inrichten van een pakket. De titel zegt dus weinig; de dagindeling zegt alles.

Wil je weten waar je aan toe bent, stel dan drie vragen. Hoeveel dagen zit je bij de klant? Bouw je zelf, of begeleid je iemand anders die bouwt? En wie beslist wat er gebouwd wordt? Zit je vier dagen per week op een hoofdkantoor sheets bij te werken, dan is het geen vooruitgeschoven werk, wat er ook boven de vacature staat.

Aan de inkoopkant geldt hetzelfde. Vraag niet naar de titel maar naar het laatste project: wat stond er, wat draait er nu, en wie gebruikt het? Wie daarop een concreet antwoord geeft, heeft het gedaan.

Wat gaat er mis als je verkeerd kiest?

Meestal geen ramp, wel verspilling. Een consultant op een bouwvraag levert een plan waar je niets mee kunt. Een ontwikkelaar op een vage vraag bouwt netjes het verkeerde. Beide kosten je een paar maanden en, erger, de energie van je mensen om het nog een keer te proberen.

Dat laatste is de echte schade. Na een mislukte poging is de volgende twee keer zo moeilijk te verkopen aan je eigen team. “We hebben het al geprobeerd” is een sterkere zin dan welk businesscase-sommetje ook, en hij blijft jaren hangen.

Zelf ben ik niet de juiste voor het inrichten van standaardpakketten en niet voor dikke adviesrapporten. Past een pakket goed bij je bedrijf, dan hou je dat en koppel je het hooguit aan de rest. Er is dan een partner van die leverancier die het beter doet dan ik, en die niets anders doet.

Kun je ze ook combineren?

Ja, en dat gebeurt vaker dan je denkt, maar zet ze niet gelijktijdig op hetzelfde probleem. Laat eerst iemand vaststellen wat er werkelijk speelt en pas daarna bouwen. Twee partijen die tegelijk aan hetzelfde stuk trekken, leveren twee rekeningen en één misverstand op.

Een werkbare volgorde: eerst één gesprek over waar het knelt, dan één klein stuk bouwen om te kijken of die diagnose klopt, en dan pas beslissen of er een groter traject nodig is. Weet je niet waar het vastzit, dan is dat eerste gesprek de hele opdracht — daarover gaat als je niet weet waar het vastzit.

Twijfel je nog of je zoiets inhuurt of in dienst neemt, dan is inhuren of iemand aannemen de volgende pagina. En wil je de rol zelf nog eens nalezen, dan staat bij wat de rol precies is waar de term vandaan komt.