Van top engineer naar overbelaste teamlead: een fout die veel IT-bedrijven maken

"Ik wil gewoon weer kunnen coderen."

Sjoerd kijkt me aan en zegt: "Christel, ik ben er eigenlijk wel klaar mee."

Een paar maanden geleden werd hij teamlead van een klein developmentteam. Iedereen vond het een logische stap. Sjoerd was tenslotte een van de beste engineers van de afdeling. Hij kende de techniek door en door, collega's kwamen graag bij hem voor advies en hij was degene die de meest complexe vraagstukken wist op te lossen.

Zelf zag hij de nieuwe rol ook wel zitten. Hij dacht dat hij zijn technische kennis kon combineren met het begeleiden van collega's. Een mooie volgende stap in zijn carrière.

De praktijk bleek anders.

Zijn dagen bestaan inmiddels uit één-op-één gesprekken, planningen, escalaties, afstemming met andere afdelingen en collega's die continu iets van hem nodig hebben. Zodra hij denkt even tijd te hebben om zich te verdiepen in een technisch vraagstuk, verschijnt er weer een Teams-bericht of staat er iemand aan zijn bureau.

Aan het einde van de dag realiseert hij zich dat hij nauwelijks nog aan coderen is toegekomen. "Ik ben alleen maar bezig met gedoe," zegt hij. "Ik los de hele dag problemen van anderen op. Als ik eerlijk ben, vraag ik me af of ik niet gewoon weer senior engineer moet worden."

Het bijzondere is dat Sjoerd dit niet zegt omdat hij zijn collega's niet leuk vindt of omdat hij leidinggeven niet belangrijk vindt. Hij zegt het omdat hij het gevoel heeft dat hij nergens meer echt goed in is. Hij mist het technische werk waar hij energie van kreeg en tegelijkertijd heeft hij het idee dat hij als leidinggevende voortdurend achter de feiten aanloopt. In de afgelopen jaren heb ik veel IT-leads gesproken en eerlijk gezegd hoor ik dit verhaal verrassend vaak.

Een promotie naar een compleet nieuw vak

Binnen IT is het heel gebruikelijk dat de beste vakspecialist doorgroeit naar een leidinggevende rol. Dat is ook niet zo vreemd. Als iemand inhoudelijk sterk is, het vertrouwen van collega's heeft en goed presteert, lijkt dat een logische volgende stap.

Toch zit daar een belangrijke denkfout.

We gaan er vaak vanuit dat iemand die een goede engineer is, automatisch ook een goede leidinggevende wordt. Terwijl de vaardigheden die je succesvol maken als engineer bijna volledig verschillen van de vaardigheden die je nodig hebt om een team te leiden. Als engineer word je dagelijks beloond voor het oplossen van problemen. Je analyseert, zoekt de oorzaak en komt met een oplossing. Dat is precies waar je goed in bent geworden. Als leidinggevende werkt diezelfde reflex juist regelmatig tegen je.

Mensen zijn geen technische vraagstukken

Wanneer een medewerker vastloopt, is de neiging groot om direct mee te denken. Wanneer twee collega's een conflict hebben, neem je het gesprek over. Wanneer een klant ontevreden is, stap jij ertussen om het op te lossen. Dat voelt behulpzaam.

Sterker nog, het voelt alsof je doet waarvoor je bent aangenomen.

Maar ondertussen gebeurt er iets waar veel leidinggevenden zich niet bewust van zijn. Iedere keer dat jij het probleem oplost, leert je team onbewust dat jij uiteindelijk degene bent met het antwoord.

Daardoor kom je steeds meer in een patroon terecht waarin iedereen afhankelijk van je wordt. Niet omdat je team niet capabel is, maar omdat jij onbedoeld hebt laten zien dat jij het uiteindelijk toch wel oplost. En precies daar ontstaan de overvolle agenda's, de continue onderbrekingen en het gevoel dat je alleen nog maar brandjes aan het blussen bent.

Gedrag begrijpen is belangrijker dan gedrag corrigeren

Veel leidinggevenden proberen dit op te lossen door duidelijkere afspraken te maken, vaker feedback te geven of strakker te sturen. Soms helpt dat even, maar vaak verandert er weinig. Dat komt omdat gedrag bijna nooit op zichzelf staat. Iemand die geen eigenaarschap neemt, doet dat niet zomaar. Iemand die weerstand laat zien, probeert vaak iets duidelijk te maken. En iemand die afwacht, heeft daar meestal een reden voor.

Vanuit de gedragspsychologie weten we dat gedrag altijd ontstaat in een bepaalde context. Juist die context bepaalt of mensen initiatief nemen, verantwoordelijkheid voelen en zich durven uitspreken.

Wanneer je als leidinggevende leert kijken naar wat er achter gedrag schuilgaat, veranderen je gesprekken vanzelf. Je stelt andere vragen, je luistert anders en je merkt dat je minder hoeft te corrigeren omdat je eerder begrijpt wat iemand nodig heeft.

Goed leiderschap maakt jezelf uiteindelijk minder belangrijk

Misschien is dat wel de grootste paradox van leidinggeven. Veel nieuwe IT-leads denken dat ze onmisbaar moeten zijn. In werkelijkheid is het tegenovergestelde waar. Een goede leidinggevende zorgt ervoor dat een team steeds zelfstandiger wordt. Dat collega's elkaar helpen, verantwoordelijkheid nemen en problemen oplossen zonder dat jij overal tussen hoeft te zitten. Dat vraagt iets anders dan technische kennis. Het vraagt dat je begrijpt hoe mensen leren, samenwerken, gemotiveerd raken en omgaan met verandering. En precies daarom geloof ik dat leiderschap binnen IT veel meer aandacht verdient dan het nu vaak krijgt.

Niet omdat engineers slechte leidinggevenden zijn, maar omdat ze een nieuw vak leren zonder daarvoor de juiste bagage mee te krijgen.

Sjoerd had geen hekel aan leidinggeven.

Hij had vooral nooit geleerd hoe je leidinggeeft.

En dat is een wereld van verschil.