IT-ontwikkeling bestaat al meer dan 60 jaar en heeft radicale transformaties ondergaan vanaf de opkomst van de eerste programmeertalen en OS-ontwikkeling tot de internetboom en de huidige AI tijdperk. Hoewel programmeertools en -benaderingen voortdurend veranderen, blijft één ding constant: alleen ontwikkelaars die zich kunnen aanpassen en nieuwe kennis en vaardigheden kunnen beheersen, overleven.
Ik ben de chief software officer van een team van zeventig man dat een voorspellend onderhoudssysteem (PdM) ontwerpt: een oplossing gebaseerd op het Industrial Internet of Things (IIoT) en AI. Zonder voortdurende groei kunnen onze ontwikkelaars niet concurrerend blijven. Hetzelfde geldt voor bijna elke branche; Wanneer individuen niet meer aan hun vaardigheden werken, kan een bedrijf zijn voorsprong verliezen.
Hier ziet u hoe we een systeem hebben gecreëerd waarin professionele ontwikkeling een integraal onderdeel van het werk is en hoe we ontwikkelaars helpen stagnatie te voorkomen en te boven te komen.
MOET IEDEREEN GROEIEN?
Elk team heeft specialisten die de voorkeur geven aan routinewerk, en tot op zekere hoogte hebben teams mensen nodig die het goed doen in een functie die geen groei vereist.
Maar om een project gestaag te laten ontwikkelen, ben ik van mening dat dergelijke experts niet meer dan 20% van het team mogen uitmaken. Als hun aandeel groter is, zullen andere ontwikkelaars uiteindelijk hun passieve collega’s gaan navolgen. Optimaal zou de meerderheid – ongeveer 80% – actief hun expertise moeten ontwikkelen en verbeteren.
Niet iedereen in de 80% hoeft nieuwe ideeën te genereren. De driver-to-performer-ratio is afhankelijk van de ontwikkelingsfase van het bedrijf. Een start-up heeft 80% chauffeurs nodig, omdat zij degenen zijn die vooruitgang boeken. Omgekeerd vereisen duurzame kwaliteitsleads in volwassen bedrijven voortdurend het aanscherpen van hun vaardigheden in plaats van een fontein van ideeën.
ONTWIKKELING DOOR KLEINE ACTIES
Het aanmoedigen van ontwikkelaars om hun vaardigheden te verbeteren kan klein beginnen. Een onderschatte tool is bijvoorbeeld dat iemand tests schrijft om zijn code te controleren, wat verplicht is voor iedereen in ons team, inclusief senior specialisten. Veel teams gebruiken vaker codereviews dan het schrijven van tests. Maar wanneer een ontwikkelaar een test schrijft, kan het zijn dat hij/zij ontdekt dat de methode of functie te omslachtig is, met veel uitzonderingen en afhankelijkheden, en dat het bijna onmogelijk is om deze volledig te testen. Als gevolg hiervan beginnen ze hun code opnieuw te ontwerpen en zoeken ze naar oplossingen om de logica ervan te verbeteren. Ze bestuderen aanvullend materiaal, zoals technische blogs en best-practicegidsen, en overleggen met collega’s om hun expertise te verdiepen.
Testen hebben echter beperkingen. Zodra iemand patronen leert, snel en vol vertrouwen tests schrijft, stopt de groei en begint de routine. Dit verleidt ontwikkelaars om hun werk te automatiseren.
GEVAL VOOR GEVAL AANPAK
Er zijn veel redenen waarom professionals pauzeren in hun ontwikkeling. Ze kunnen tevreden zijn met hun positie/vaardigheden, zich vervelen of te maken krijgen met uitdagende externe omstandigheden. De meeste van onze ontwikkelaars zijn bijvoorbeeld Oekraïens en ons werk is beïnvloed door de grootschalige Russische invasie in Oekraïne, wat voor iedereen grote stress heeft veroorzaakt.
Teamleden hebben verschillend gereageerd: ongeveer 30% verloor de motivatie om iets te doen, en nog eens 30% heeft een diepe duik in hun ontwikkeling genomen. Eén sterke junior verdiepte zich zo diep in zijn studie dat hij in slechts zes maanden de theorie op senior niveau beheerste. De rest paste zich eenvoudig aan en keerde terug naar hun gebruikelijke tempo.
Na meer dan 10 jaar in technologiemanagement realiseerde ik me dat iedereen verschillende motivaties heeft om zijn vaardigheden te verbeteren. Jouw taak is niet om ze onder druk te zetten, maar om te begrijpen wat hen tegenhoudt en wat hen stimuleert. Enkele praktijken die ik nuttig heb gevonden als ontwikkelaars stagneren zijn:
- Zorg voor nieuwe context. Bied de ontwikkelaar de mogelijkheid om aan een ander project te werken of van domein te veranderen. Een nieuwe omgeving brengt nieuwe uitdagingen met zich mee, vereist aanpassing en leren.
- Huidige uitdagingen. Geef de ontwikkelaar een taak die creatief denken en onafhankelijk onderzoek vereist. Geef geen antwoord. Hierdoor kunnen zij initiatief nemen en verantwoordelijkheid nemen voor het resultaat.
- Moedig leren aan. Als iemand ontwikkelingsmogelijkheden zoekt, geef hem dan de middelen. Compenseer bijvoorbeeld een congres- of workshopdeelname.
- Pas de verwachtingen aan. Soms is iemand tevreden met zijn expertise. In dit geval is het belangrijk om het eens te zijn: als de ontwikkelaar geen groei wil, zoekt hij geen promotie.
Elke specialist moet een eigen ontwikkelingsplan hebben. Twee keer per jaar stellen we het op, op basis van een diepgaande evaluatie. We stellen doelen die voldoen aan de verwachtingen van het bedrijf en de belangen van de ontwikkelaar.
DE SYSTEMATISCHE AANPAK VAN HET BEDRIJF
Mijn ervaring is dat ontwikkelaars zich vaak niet meer concentreren op het verbeteren van hun vaardigheden als ze overbelast raken. Na intensief werken hebben ze niet langer de energie om te leren. Leren door te werken is ons uitgangspunt. Wij geloven dat ontwikkelaars hun vaardigheden kunnen verbeteren door praktijkervaring, dus integreren we deze aanpak in de ontwikkelingsplannen van onze medewerkers.
- Dagelijks: geef ze een korte technische samenvatting en werk met code door middel van tests en recensies.
- Sprints van twee weken: Elke sprint omvat twee tot drie dagen waarop een ontwikkelaar een nieuwe aanpak, technologie, enz. kan uitproberen.
- Eén keer per maand: Interne clubs – sessies op elke afdeling van een uur tot 90 minuten waarin ze ervaringen kunnen delen, praktische workshops kunnen geven en best practices kunnen uitwisselen.
- Eens in de drie tot zes maanden: sessies van drie uur met externe sprekers, geavanceerde training.
LAATSTE GEDACHTEN
Ik ben ervan overtuigd dat ontwikkeling begint met dialoog. Je moet begrijpen wat iemand motiveert. Ik geloof ook dat er geen verkeerde beslissingen bestaan, alleen maar verschillende standpunten. Ontwikkelaars moeten niet bang zijn om het oneens te zijn, omdat kritisch denken en constructieve discussie altijd de teamgroei bevorderen.
Illia Smoliienko is de Chief Software Officer voor Waites.
