Wat doet een Forward Deployed Engineer echt?

In vacatures staat het netjes verdeeld in vier verantwoordelijkheden. In de praktijk lopen die vier op één dag door elkaar heen, en de volgorde bepaalt de klant. Hieronder wat elk van die vier in gewone taal betekent, en wat je ervan merkt als je een bedrijf met twintig man hebt.

Wat doet een Forward Deployed Engineer op een dag?

Een Forward Deployed Engineer doet vier dingen door elkaar heen: hij bouwt werkende software bij de klant, hakt vage bedrijfsvragen in stukken die je kunt bouwen, koppelt terug wat hij op de werkvloer hoort, en zorgt dat het blijft draaien tussen systemen die er al stonden.

De rol zelf staat elders uitgelegd; dit is de uitwerking ervan. Wat de vier taken bindt is dat ze allemaal op locatie gebeuren. Niet in de zin van fysiek aanwezig zijn — soms werk ik dagen op afstand — maar in de zin dat het gesprek en de code op dezelfde plek ontstaan. Wie eerst een half jaar analyseert en daarna gaat bouwen, doet iets anders. Hoe die rol precies verschilt van andere vakken, staat bij de rol zelf.

Wat betekent bouwen als je maar één klant hebt?

Dat je in weken denkt in plaats van in kwartalen, en dat je durft weg te gooien. Je bouwt voor één bedrijf, dus je hoeft niets algemeen te maken. Wat je wint is snelheid; wat je opgeeft is de zekerheid dat het over drie jaar nog past. Die ruil moet je bewust maken.

Een productbouwer moet rekening houden met duizend klanten die allemaal net iets anders willen. Dat kost hem ontwerptijd, en terecht. Werk je voor één bedrijf, dan mag je precies hún prijsregels, hún vier vestigingen en hún ene rare uitzondering hardcoderen. Dat voelt vies als je uit de productwereld komt. Het is hier meestal het goede antwoord.

Wat er dan uitkomt ziet er van buiten klein uit. Bij een van mijn eigen bedrijven kwam er een klantkaart waarin aanvragen van meerdere websites binnenkomen, met hun herkomst erbij. Geen indrukwekkend systeem. Wel het einde van vijf mensen die dezelfde gegevens overtypten.

Hoe maak je van een vage vraag een concrete taak?

Door door te vragen tot er een werkwoord overblijft. “We moeten iets met AI” is geen opdracht. “Onze offertes blijven liggen” is er een. Het gesprek dat daartussen zit, is het lastigste deel van het werk en gaat vrijwel nooit over techniek. Het gaat over waar het werkelijk pijn doet.

Mijn vaste route is simpel. Wie doet dit nu, hoe vaak per week, wat gaat er mis als het misgaat, en wat zou er dan gebeuren? Vier vragen. Na die vier is meestal duidelijk of er iets te bouwen valt, of dat er iemand een afspraak moet maken met een collega.

Er komt regelmatig uit dat de vraag klopt maar het antwoord niet. Iemand wil een pakket vervangen omdat de rapportage niet deugt, terwijl het probleem is dat drie mensen verschillende velden invullen. Nieuw pakket kopen lost dat niet op. Andere afspraak wel.

Dit is trouwens ook de stap waarin het antwoord soms nee is. Bij lage aantallen, rommelige gegevens of een proces dat eerst opgeruimd moet worden, is bouwen de dure route. Wanneer dat het geval is, staat bij soms bouw je beter niets.

Wat doe je met wat je op de werkvloer hoort?

Je onthoudt het en je brengt het terug. Wie bij klanten zit, hoort dezelfde klacht bij het derde bedrijf voor de derde keer. Dat is geen anekdote meer, dat is een patroon. In een softwarebedrijf gaat dat naar de productmensen. Werk je zelfstandig, dan wordt het je volgende bouwsteen.

Bij mij is dat letterlijk hoe het meeste ontstaan is. Een plattegrond waarop je je pand intekent en die zelf uitrekent hoeveel wifi-zenders er nodig zijn: die kwam er omdat dezelfde vraag telkens terugkwam bij offertes voor netwerken. Een configurator die maatwerk per regel doorrekent: die kwam er omdat het narekenen elke keer weer een half uur kostte.

Het valse eind van deze taak is dat je alles wilt generaliseren. Niet elke klacht is een patroon. Twee klanten die iets willen is toeval, en wie op toeval bouwt, maakt een product waar niemand op zat te wachten.

Waarom is betrouwbaar draaien lastiger dan bouwen?

Omdat je bouwt in een omgeving die je niet hebt gekozen. Er staat een pakket uit 2011, er is een export die elke maandag met de hand gedraaid wordt, en er is één collega die weet waarom veld negen leeg moet blijven. Daar moet jouw ding tussen passen, zonder dat de rest omvalt.

Dit is het deel dat in een demo nooit te zien is en dat achteraf de meeste tijd kost. Een koppeling die het vier maanden doet en dan stil stopt omdat een leverancier zijn versie heeft verhoogd. Een wachtwoord dat verloopt. Een veld dat ineens een andere naam heeft. Wat je daar tegen doet is niet slim, het is saai: melden als het misgaat, en niet stilletjes verder gaan. Waarom je dat pas weken later merkt als je het niet inbouwt, staat bij twee systemen die elkaar niet verstaan.

En er is een menselijke kant. Iets draait pas echt als mensen het gebruiken zoals bedoeld. Ik heb systemen zien sneuvelen die technisch prima werkten, puur omdat niemand meer wist waarom een stap erin zat. Uitleggen hoort dus bij het opleveren, niet erna.

Hoe ziet zo’n dag er bij een mkb-bedrijf uit?

Rommeliger dan hierboven. Een ochtend naast iemand zitten die zijn werk doet, een uur bouwen, een gesprek waarin blijkt dat het net anders is, en een middag waarin je het opnieuw doet. De vier taken zijn geen fasen. Ze wisselen elkaar per uur af.

Wat ik bijna altijd op de eerste dag doe, is opschrijven waar een gegeven voor de tweede keer wordt ingetypt, en door wie. Dat lijstje is meestal korter dan mensen denken en pijnlijker dan ze verwachten. Bij een bedrijf waar de binnendienst offertes maakte, bleek daar het hele verhaal in te zitten: wat er gebeurde toen het overtypen wegviel.

Verschil met een groot bedrijf: in het mkb praat je met de eigenaar zelf. Dat scheelt drie lagen goedkeuring en het betekent ook dat een besluit dezelfde dag valt. Daar staat tegenover dat er niemand is om het van je over te nemen als jij weggaat. Dat is een reëel risico en je hoort het aan het begin te bespreken, niet aan het eind.

Wat doet hij juist niet?

Hij schrijft geen adviesrapport, hij richt geen standaardpakketten in en hij bouwt niets na wat al bestaat en prima werkt. Zit er een pakket dat past, dan koppel je het en ga je door. Werk overnemen dat een leverancier beter doet, is duur en het maakt het bedrijf afhankelijk van jou.

Nog iets wat er niet bij hoort: eeuwig blijven. Als het draait en de mensen het snappen, is het klaar. Iemand die na twee jaar nog steeds onmisbaar is, heeft iets niet goed opgeleverd.

Wanneer is dit werk klaar?

Als het draait zonder jou, en de mensen die het gebruiken kunnen navertellen wat het doet. Dat tweede is de echte toets. Software die werkt maar die niemand kan uitleggen, is uitgesteld gedoe: de eerste keer dat er iets verandert, zet iemand het uit.

Daarom leg ik aan het begin al vast wanneer we klaar zijn. Niet met een datum, maar met een zin: wat moet er dan gebeuren zonder dat iemand ingrijpt? Wie dat vooraf opschrijft, merkt vaak dat het kleiner is dan gedacht. En wie wil weten wat je daarvoor moet kunnen, leest de vaardigheden na op een eigen pagina.