Robin Als Tech Lead: Brug tussen business en IT

Na het vorige deel, waarin we Robin’s aanpak binnen het technische team hebben belicht, gaan we nu dieper in op zijn rol als brug tussen business en IT.

Elke organisatie kent spanningen tussen de business, die een bepaalde visie wil realiseren en daarbij snelheid en impact nastreeft, en developers, die zich typisch richten op technische kwaliteit en een goed ontwikkelproces. Als Tech Lead speelt Robin een cruciale rol in het overbruggen van deze kloof. Hij houdt de bedrijfsdoelen in het oog, terwijl hij tegelijkertijd de belangen van developers bewaakt. In dit deel kijken we hoe Robin deze balans vindt en dit aanpakt.

Frictie tussen developers en business verminderen

In elk project is er wel enige – hopelijk gezonde – frictie tussen developers en de businesskant. Robin fungeert vaak als middle man. Hij hoort de grieven van developers over de business en andersom. Zijn rol is om beide partijen te helpen een zo werkbaar mogelijke middenweg te vinden.

Robin blijft in de eerste plaats een developer. Hij begrijpt en behartigt de belangen van developers, als een developer advocate die weet wat nodig is om optimaal te kunnen werken. Maar hij is ook een realist en stuurt development teams bij waar nodig. Voor developers betekent dat vaak dat ze iets moeten presenteren op een manier die voor de business aantrekkelijk en begrijpelijk is. Of dat ze een alternatieve oplossing zoeken die technisch even goed werkt, maar beter aansluit bij de behoeften van de business.

De business stakeholders zien Robin vaak als een vertrouwenspersoon met wie ze complexe kwesties kunnen bespreken. Hij begrijpt de perspectieven van alle stakeholders en hanteert steeds een open en oplossingsgerichte mindset. Vaak draait het om expectation management: zorgen dat de business realistische verwachtingen heeft van wat developers kunnen leveren. Soms betekent dat simpelweg: “Sorry, maar dit gaat meer tijd kosten dan jullie denken, vanwege de technische complexiteit.”

De beste samenwerking ontstaat volgens Robin wanneer de business volledig vertrouwen heeft in het team. Dat ze zaken zeggen als: “Jullie weten hier meer van dan ik, dus ik ga niet tegenwerken. Als dit de juiste aanpak is, dan doen we het zo.” Het mooiste is wanneer de stakeholders gewoon met een probleem of idee komen en erop vertrouwen dat het team de meest werkbare oplossing vindt.

Experimenten: “Hoe kan het dan wel?”

Elk project begint met de noden van de business en hoe die zich laten vertalen naar een technische oplossing. In het maken van die vertaalslag is Robin altijd al goed geweest. Hij identificeert snel de volgende stap, durft te springen en zet zaken in gang.

De input van de business komt vaak met interessante uitdagingen. Bijvoorbeeld wanneer een complexe functionaliteit ontwikkeld moet worden: “Volgende week MOET dit gelanceerd worden, kan het niet sneller?” De eerste reflex van een developer is dan vaak: “Onmogelijk!”. Robin geeft zelf ook realistische schattingen, maar zoekt daarnaast steeds naar manieren om out of the box te denken. Daar komt dan zijn creativiteit in probleemoplossing naar voren. Soms stelt hij een slimme MVP (Minimum Viable Product) voor—een alternatief dat wel binnen de tijd past en ook een vergelijkbare business value oplevert.

Developers en business stakeholders willen in het algemeen hetzelfde: een elegante oplossing die impact maakt. Maar hebben we overeenstemming over de richting waarin we gaan, en hebben we alle ideeën over hoe we dit gaan aanpakken gehoord? Om het gesprek op gang te brengen, stelt Robin regelmatig vragen. Hij neemt een faciliterende rol op zich en wijst waar nodig op andere mogelijke aanpakken, zonder direct op één juiste oplossing te sturen. Het gaat eerder om het testen van een nieuwe aanpak die gedragen wordt door het team.

Experimenteren is dus essentieel, omdat elke situatie en elk team anders is. Bovendien loop je het risico zaken over het hoofd te zien als je te snel op één oplossing vastpint. Door samen na te denken en ideeën te delen, vergroot je het draagvlak en benut je de collectieve intelligentie van het team. De kern van Agile werken is juist snel dingen uitproberen en snel evalueren of ze werken. Maar juist dit aspect wordt vaak overgeslagen, terwijl er wel een draaiboek van processen gevolgd wordt (zie punt hieronder over balans in structuur vinden).

Balans in structuur vinden

Na ervaring bij verschillende klanten en projecten ziet Robin dat teams vaak óf te weinig, óf juist te veel structuur hebben. Te veel structuur ontstaat wanneer developers niet het vertrouwen krijgen om zaken op hun eigen manier aan te pakken. Alles moet via een rigide proces, waardoor de velocity sterk daalt en innovatie wordt afgeremd. Aan de andere kant leidt te weinig structuur tot problemen zoals ontbrekende tickets, verouderde documentatie of een gebrek aan standaardisatie. Hierdoor gaat veel informatie verloren en ontstaan misverstanden.

In elk proces schuilt het risico op over- of onderstructurering. Soms werken teams van 15 mensen zonder dat iemand het proces actief in goede banen leidt, terwijl een klein team met slechts een paar developers juist wel een scrum master heeft die vooral in de weg loopt. Vaak zijn scheefgroeiende structuren te herkennen aan symptomen zoals daily standups die een uur duren—een duidelijk teken dat het proces vastloopt. Het is een vaak voorkomend probleem: Stand-ups, ceremonies en andere processen worden wel gevolgd “volgens een checklist”, maar de echte kritische blik op of wat er gedaan wordt ook echt nuttig is, ontbreekt vaak. Terwijl juist dat nodig is om te bepalen of bijsturen noodzakelijk is, om zo tot echte positieve verandering te komen.

Zoals Robin benadrukt, is elke omgeving en elk team anders. Voor Robin is er dus geen standaardhandleiding, geen checklist die overal toepasbaar is. In zijn ervaring kun je ideeën aandragen, maar er bestaat geen aanpak die in elke context hetzelfde resultaat oplevert. Robin merkt snel waar een proces uit balans raakt en kaart dit steeds op een respectvolle manier aan bij de verantwoordelijke. Samen zoeken ze naar de juiste ingrepen om de balans te herstellen.