Wat is Technical Leadership?
Technical Leadership gaat voor mij niet over degene zijn die technisch het meeste bepaalt. Het gaat erom dat je richting kunt geven wanneer technische keuzes impact hebben op het team, het product en de toekomst van een platform.
Dat betekent eerst begrijpen wat er speelt, vervolgens structuur aanbrengen en daarna samen een keuze maken die technisch goed is, maar ook praktisch uitvoerbaar blijft.
Ik zie Technical Leadership daarom vooral als het nemen van eigenaarschap. Niet alleen over code, maar ook over architectuur, technische risico's, onderhoudbaarheid en de manier waarop een team gezamenlijk vooruitgaat.
Wat vind ik belangrijk?
Een goede technische oplossing hoeft niet de meest geavanceerde oplossing te zijn. Sterker nog, complexiteit toevoegen is meestal makkelijker dan complexiteit voorkomen.
Binnen Technical Leadership let ik daarom vooral op:
Eerst begrijpen: voordat ik een technische richting voorstel wil ik het probleem, de context en de belangen begrijpen.
Bewust eenvoudig blijven: architectuur moet een probleem oplossen en geen nieuw probleem introduceren.
Eigenaarschap: wanneer ik een technisch risico of structureel probleem zie, wacht ik niet totdat iemand anders het oppakt.
Samen vooruit: technische richting werkt alleen wanneer het team begrijpt waarom bepaalde keuzes worden gemaakt.
Duurzaamheid: een oplossing moet vandaag werken, maar ook over een paar jaar nog beheersbaar zijn.
Voor mij betekent technisch leiderschap dus niet alleen vooruitdenken. Het betekent ook bewust bepalen welke techniek je juist niet nodig hebt.
Hoe gebruik ik Technical Leadership?
Ik gebruik Technical Leadership vooral wanneer een team tegen vraagstukken aanloopt die groter zijn dan één ticket of één service.
Bijvoorbeeld wanneer datastromen steeds moeilijker beheersbaar worden, wanneer een architectuur niet meer aansluit op hoe een product groeit of wanneer bestaande technische keuzes onnodig veel beheer, kosten of complexiteit veroorzaken.
Ik probeer zo'n vraagstuk eerst terug te brengen naar de essentie. Wat proberen we daadwerkelijk op te lossen? Waar zit het risico? Wat gebeurt er wanneer we niets veranderen?
Daarna vertaal ik dat naar een technische richting die voor het team begrijpelijk en uitvoerbaar blijft.
Ik vind het daarbij belangrijk dat kennis niet bij één persoon blijft hangen. Een goede technische keuze wordt sterker wanneer het team begrijpt waarom die keuze gemaakt is en deze daarna zelfstandig kan onderhouden en verder ontwikkelen.
Waar heb ik Technical Leadership toegepast?
Recent heb ik Technical Leadership sterk toegepast binnen het Car Platform van ANWB.
Daar kwam ik terecht in een backend waarin Spring Kotlin, MongoDB en Redis werden gebruikt en waarin verschillende externe databronnen samenkwamen. Binnen die omgeving heb ik een architecturale omslag ingezet richting een duidelijker event-driven model, waarbij verantwoordelijkheden tussen verschillende delen van het platform beter werden gescheiden.
Ik heb daarnaast een asynchrone task scheduler ontworpen voor langlopende processen en de overgang naar Redis Streams geleid om berichtverwerking betrouwbaarder en beter beheersbaar te maken. Daarbij ging het niet alleen om het implementeren van techniek, maar vooral om bepalen welke technische richting het platform nodig had om verder te kunnen groeien.
Een ander recent voorbeeld is mijn rol als Senior Lead Java Backend Developer binnen het Maritime Applications Team van Port of Amsterdam. Daar werkte ik aan bedrijfskritische applicaties zoals Lock Schedule, MyPort, HAP List en de Zeehavengeld Applicatie. Binnen zo'n omgeving betekent Technical Leadership voor mij vooral begrijpen welke systemen kritisch zijn voor de operatie en technische veranderingen gecontroleerd doorvoeren zonder stabiliteit uit het oog te verliezen.
Mijn ervaring met Technical Leadership
Mijn recente ervaring heeft Technical Leadership steeds meer een vast onderdeel van mijn rol gemaakt.
Waar ik vroeger vooral keek naar hoe ik een technisch probleem goed kon implementeren, kijk ik tegenwoordig veel eerder naar waarom een probleem bestaat, welke gevolgen een keuze heeft voor andere onderdelen van het platform en hoe een oplossing zich op lange termijn gaat gedragen.
Daarbij combineer ik mijn ervaring met distributed systems, Java en Kotlin, event-driven architecturen, consistency-modellen, CI/CD en Platform Engineering met een praktische manier van werken.
Ik hoef daarbij niet altijd degene te zijn die de oplossing zelf bouwt. Wanneer het team de context begrijpt, gezamenlijk achter de richting staat en zelfstandig verder kan, is het technische leiderschap voor mij juist geslaagd.
Veelgestelde vragen die ik krijg over Technical Leadership
Moet je Lead Developer zijn om technisch leiderschap te tonen?
Nee. Technical Leadership begint voor mij bij eigenaarschap. Een probleem herkennen, begrijpen waarom het bestaat en verantwoordelijkheid nemen voor een structurele oplossing kan vanuit iedere technische rol.
Hoe voorkom je dat Technical Leadership verandert in alles zelf bepalen?
Door eerst te begrijpen en daarna het gesprek aan te gaan. Ik heb vaak een duidelijke technische mening, maar wil ook weten welke context of informatie anderen hebben die ik misschien nog niet zie.
Hoe weet je wanneer een architectuur aangepast moet worden?
Wanneer de huidige structuur structureel tegen het product begint te werken. Toen datastromen binnen het Car Platform steeds moeilijker beheersbaar werden, was alleen lokaal optimaliseren niet voldoende. Dan moet je naar het ontwerp van het systeem zelf kijken.
Hoe houd je technische oplossingen eenvoudig?
Door regelmatig terug te gaan naar het probleem. Technologie is voor mij nooit het doel. Als dezelfde behoefte met minder componenten, minder beheer en minder afhankelijkheden opgelost kan worden, heeft dat meestal mijn voorkeur.
Wat vind je het belangrijkste onderdeel van Technical Leadership?
Dat een team na een technische beslissing sterker achterblijft. Niet alleen met betere software, maar ook met meer begrip van het systeem en waarom bepaalde keuzes gemaakt zijn.