Wat komt er bij kijken een front-end lead developer te zijn? Een overzicht, persoonlijke ervaringen, tips & tricks.
En toen was ik ineens een lead developer.
De opdrachtgever waar ik enkele jaren geleden werkte, had diverse grote features op de planning staan. Een grote codebase met aanzienlijke technical debt en een dringende behoefte aan refactors. Vanuit “hogerop” was er behoefte aan een vast aanspreekpunt over de voortgang en complexiteit van het project. Het front-end team bestond uit een solide groep van zeven developers, met uiteenlopende kennis en ideeën.
Er was behoefte om één schipper aan het roer te hebben, en dat werd ik in de rol van front-end lead developer.
De afgelopen jaren was ik op meerdere projecten een front-end lead. In deze blogpost schets ik een totaalplaatje van die rol, zodat je voorbereid bent als je zelf aan de slag gaat als lead developer. Het zijn zaken waar je op kunt focussen om jezelf in te ontwikkelen met boeken, cursussen of conferenties.
Wat komt er bij kijken?
Deels houd je je bezig met de (front-end) technische kant van wat je aan het bouwen bent. Je ondersteunt het hele team om dat voor elkaar te krijgen. Het totaal plaatje van de infrastructuur houd je in de gaten; je zet een stip op de horizon. Buiten het team ben je een aanspreekpunt voor allerhande mensen, bijvoorbeeld product owners, partners en mensen van de business-kant.
De exacte invulling is anders per bedrijf. Wellicht zijn er meerdere front-end leads voor verschillende teams. Of is er een tech lead die zowel de front-end als back-end overziet.
Kort samengevat is het:
- Code
- Infrastructuur
- Mensen en interacties
Ik behandel ze in omgekeerde volgorde.
Mensen en interacties
Waar je als front-end ontwikkeling al samenwerkt met andere discipline, komt er als lead meer gewicht in de schaal. Voordat grotere nieuwe dingen gebouwd worden, worden ze uitgedacht, opgeknipt, ontworpen, doorgelicht, verbeterd en weer uitgedacht. Ook als het concreter wordt, kun je als lead invloed hebben op hoe dat binnen het team opgepakt wordt.
Tijdens die processen ben je voortdurend aan het argumenteren en overtuigen. Soms aan het coachen of mentoren. Bovenal is het heel veel overleggen in meetings.
Coachen en mentoren
Hoe help je mensen in je team effectief met hun werk? Met hun ontwikkeling als developer? Wat weerhoudt ze ervan productief te zijn in een team? Een andere blik krijgen op zaken? Zichzelf leren kennen? Wat speelt er echt bij iemand?
Niet iedereen is een geboren coach, voor mij heeft het gewerkt bewust training in deze hoek op te zoeken.
De wereld van coachen en mentoren kan best een breed onderwerp zijn om jezelf in te verbeteren. Een van de belangrijkste lessen die ik heb geleerd, is luisteren om te begrijpen in plaats van luisteren om te reageren. Nadat een ander uitgepraat is, niet direct iets te willen suggereren, maar juist om vragen te stellen ter verduidelijking.
Meetings en agendas
Meer verantwoordelijkheid betekent meer afstemming, vaak met een groter aantal mensen. Meer meetings. Ook zal er een drang ontstaan zelf af te stemmen hoe/wat/wanneer bepaalde dingen op technisch vlak ontwikkeld gaan worden.
Soms is dat noodzakelijk, vaak iets minder. Zonder duidelijke grenzen kan je agenda snel overladen raken met meeting-uitnodigingen van anderen.
Houd je agenda strakker bij en plan bewust tijd in voor zaken die je dagelijks wilt afronden. Blok je agenda bijvoorbeeld met momenten om te code reviewen. Of wanneer je pauze moet nemen.
Natuurlijk hoeft niet alles een meeting te zijn. Asynchrone afstemming in bijvoorbeeld een Slack-draadje zijn heel waardevol en laagdrempelig.
Betrokken samenwerken
Hoe werk en overleg je samen? Zijn het vaak dezelfde discussies, met dezelfde mensen aan het woord? Wordt iedereen echt gehoord en is er een open houding voor nieuwe ideeën? Vanuit de agile hoek kwam ik in aanraking met Liberating structures, die behelsen meerdere recepten om een groep aan het werk te zetten op basis van een uitnodiging. Bijvoorbeeld een uitnodiging om te brainstormen, waarbij in kleinere groepjes aan de slag gegaan wordt.
Liberating structures helpen mij een groep in mum van tijd aan het werk te zetten met een vraagstuk, op een manier dat iedere aanwezige betrokken is en input kan geven. Dit in tegenstelling tot een klassieke vergadering, waarin slechts een paar mensen met het hoogste woord de discussie bepalen.
De website van Liberating structures bevat veel informatie, ik kan het aanraden het mee te maken bij bijvoorbeeld een meetup van de Liberating Structures User Group in Nederland.
Infrastructuur
Iemand moet zorgen voor technische betrouwbaarheid en een duidelijke koers uitstippelen. Als lead developer is het aan jou je leiderschap en inzicht in te zetten om je schip zeewaardig te houden.
Dit zal zijn op basis van diverse gebieden zoals beveiliging, privacy, toegankelijkheid, het bijhouden van dependencies. Periodiek zul je een goede blik door de codebase moeten (laten) doen. Ook zal er op al deze vlakken een doel moeten worden gesteld waar het team naartoe kan werken. Het is essentieel om je kennis van architectuur, infrastructuur en techniek breed te onderhouden, zelfs als je niet alles zelf bouwt.
Een goed moment om de documentatie te beoordelen is vlak voordat een nieuwe developer aan het project begint. Diegene moet weten hoe een en ander in elkaar zit. Er moet documentatie zijn om het project in te leiden, op te zetten en aan te ontwikkelen. Tijdens onboarding heb je een mooie gelegenheid om documentatie op peil te brengen en aan te passen. Een frisse wind waait door het team en de codebase. Wellicht vloeien er betekenisvolle verbeteringen uit.
Een andere meetlat is de frequentie waarin teamleden onderdelen aanwijzen als problematisch. Als je dit bijhoud, heb je ook extra slagkracht om verbeteringen tijdig door te voeren.
Wat zou beter kunnen?
Wat moet beter?
Code
Onder aan de streep schrijf je mogelijk veel minder code.
Het grootste gedeelte van je tijd in de codebase zal zijn om kennis over te dragen tijdens pairings en in pull requests. Van elk stuk interessante code die je zou kunnen schrijven, kun je na gaan denken wie in het team dit het beste kan doen. Het beste kan zijn in een kort tijdsbestek, maar juist ook waar het meest geleerd van kan worden.
Belangrijk is om niet een bottleneck te zijn voor de rest van het team. Neem dus niet te grote zaken op je bordje, want dan is de doorlooptijd erg lang. Een veelgemaakte fout is alle code reviews zelf te willen doen, wat al snel tot een kunstmatige werkdruk leidt.
Je zou kleine tickets op je kunnen nemen, bijvoorbeeld taken die minder urgent lijken maar al langer blijven liggen.
Tot slot
Wellicht blijf je liever voor anker en hou je jouw focus het liefste bij code. Of je wordt uitgedaagd aan het roer te staan. Natuurlijk sta je er nooit alleen voor, dus hopelijk is bovenstaande een nuttig inkijkje in de rol van lead developer.