De gemiddelde softwareontwikkelaar beschikt naar eigen zeggen slechts over een kwart van de vaardigheden die nodig is om dit beroep optimaal uit te oefenen. Ook bij de meeste andere it-functies is de gemiddelde competentie-score bar slecht. De ‘skill gap’ is daar ten minste vijftig procent. Dit wil zeggen dat betrokken it’ers minder dan de helft van de competenties bezit die voor hun functie nodig zijn.
Dit blijkt uit onderzoek van Exin, een onafhankelijk certificerings- en accreditatie-instituut uit Utrecht dat zich richt op het it-domein. De Software Improvement Group, waar Exin onder valt, bericht hierover in zijn ‘Benchmark Report 2023’.
Exin ontwikkelde de Astride-benchmark, een portal waar it’ers aangeven welke competenties ze hebben. Astride is gebaseerd op een wetenschappelijk raamwerk dat 121 verschillende competenties koppelt aan 31 ‘werkprofielen’. Sinds eind vorig jaar hebben meer dan 5.500 it’ers uit 180 landen deze tool ingevuld.
Deelnemers kunnen maximaal tachtig punten scoren. Maar in de meeste functies eindigen ze ver onder veertig punten. Uitzonderingen zijn ‘digital transformation leaders’ en ‘information security managers’. Beide groepen scoren als enige boven de veertig.
Op grote afstand volgen ‘digital educators’, ‘product owners’, cio’s, service managers, enterprise architects en scrum masters. De grootste groep deelnemers bestaat uit projectmanagers, die qua skills in de middenmoot eindigen.
Onder het gemiddelde
Onder het gemiddelde komen dus de developers. Çomponent-integratie, testen en het documenteren zijn bij hen ondergeschoven kindjes. Het laagst scoren beroepsgroepen als ‘dataspecialist’, ‘quality assurance manager’, ‘business-analist’, ‘data-administrator’ en ‘data-scientist’.
De ene functie vereist uiteraard meer competenties dan de andere. Enterprise-architecten en digitale transformatie-leiders beschikken over de meeste vaardigheden. Dat geeft hen ook mogelijkheden andere functies te bekleden. Gebaseerd op hun ‘vaardigheidsset’ kunnen ook cio’s, information security managers, digital consultants en devops-experts gemakkelijk van baan veranderen.
Er wordt volgens mij te veel verwacht dat je skills verwerft buiten de werkuren.
Terwijl er volgens mij een win-win kan zijn als er tijdens de werkuren de nodige aandacht besteed wordt aan skill-verwerving.
Ik durf me afvragen of er werkgevers zijn die schrik hebben aan skill-optimalisatie te doen, omdat de werknemer dan misschien vlugger zijn heil gaat zoeken ergens anders.
Maar je kan het ook anders zien, zouden werknemers niet minder geneigd zijn ergens anders zijn heil te zoeken als er meer aandacht besteed wordt aan skill-verwerving tijdens de werkuren ?
Het verbaast mij niet. Ik beperk me tot het MBO-opleiding Informatica. Studenten slagen heel gemakkelijk voor een examen/toets. De norm om te slagen is laag. Het aantal geslaagden per jaar is belangrijker dan de kwaliteit van afgestudeerden, heb ik gemerkt. Ik had een jaar les gegeven op een HBO en daar werd geleerd dat queries gewoon hard worden gecodeerd. Dat zegt wel wat. Dus bedrijven moeten investeren in cursussen of opleidingen aan nieuwe medewerkers, zou ik zeggen.
Een rol vervullen dient in mijn bescheiden mening aan drie eisen te voldoen: kunnen, willen en doen.
“Kunnen” is inhoudelijk: dat kan wat mij betreft via een opleiding of zelftraining, Het interesseert me geen biet hoeveel diploma’s iemand heeft, het gaat erom of hij of zij het kan! Overigens moeten we bij het “kunnen” uitkijken dat we niet het schaap met (inmiddels) acht poten aan het zoeken zijn. Kap daar gewoon mee, werkgevers. Toets de rol tegenover het werk dat voor die rol er de komende drie jaar ligt, en neem daar iemand op aan, niet op alle mogelijke vakkennis die een rol (vaak in de optiek van managers of vakideologen) zou moeten omarmen.
“Willen” heeft alles met de persoonlijke intrinsieke motivatie te maken. Dat kan je niet leren, dat moet in je zitten. Dat is de aard van het beestje. Noem het drive, betrokkenheid, whatever. Dit kun je alleen ervaren, niet uitvragen.
“Doen” ziet hem echt in die skills. Ik heb ooit een collega gehad die domweg niet kon communiceren via de telefoon. Hij was uitermate goed in zijn rol qua kennis (“kunnen”) en had zeker de intrinsieke motivatie (“willen”). Pavlov-reactie van het management, “laten we de goede man op trainingen sturen”. Al stuur je hem duizend jaar op training, het zou nooit gaan werken. Als team (vakbroeders) hebben we voorgesteld dat anderen de telefoon ter hand namen en de professional op de achtergrond het uitzoekwerk lieten doen. Probleem opgelost. Natuurlijk moet een dergelijke constructie van werken wel passen binnen de organisatie (qua resources en werkprocessen).
Waar we uit moeten kijken is dat met name bij dat “Doen” de feitelijke omstandigheden van de organisatie in spe, waar de rol vervult moet worden, niet een onmogelijke werksituatie heeft gecreëerd, waar geen enkele skill het gaat overleven. Dan krijg je gesprekken met opdrachtgevers met de cliche uitspraken als “je bent nummer 5 al die dit gaat proberen, we verwachten van je dat jij het kan, anders ben je slecht in je functie” of “ik verwacht van je heel zelfstandig en een hands-on attitude hebt, en hier heb je het handboek soldaat hoe je precies moet werken”. Bij mij heeft dat wel eens geleid dat mijn opdrachtgever naar huis mocht. De context waarin je je rol moet uitvoeren is zeer relevant voor het slagen van je eigen functioneren. Als die context in en in verrot is, kun je twee dingen doen: onderzoek de (on)mogelijkheden om het tij te keren of kies je heil ergens anders.
Vissen die niet in bomen kunnen klimmen en vogels die niet kunnen zwemmen heeft Exin vooral de slag gemist als onafhankelijk certificerings- en accreditatie instituut. Na PDI en AMBI ben ik me op andere certificerings- en accreditatie instituten gaan richten omdat kennis niet geïnstitutionaliseerd is. Wat betreft de vleugels uitslaan in een polder herken ik ‘skill gap’ van ontwikkelaars zoals Dino. De behoudendheid van oude honden die geen nieuwe kunstje willen leren gaat om het risicomijdend gedrag. Verandering is eng want ik heb de accreditatie van Enterprise architect volgens TOGAF via de praatplaten maar ik hecht er geen waarde aan. PRINCE2 heb ik niet omdat ik IPMA gedaan heb, de PMBOK sprak me aan wat een leven lang leren begint met een aangeboren nieuwsgierigheid.
Als autodidact draaide ik het spelletje om, ik behaalde de MCSE+ accreditatie zonder enige training door de handleiding te lezen. En vervolgens gaf ik training waarvoor ik beloond werd met een leuke (eerste klas) reis naar een congres voor nieuwe inspiratie. Want het voorbij de dijken denken wordt lastig als een organisatie ingedeeld is in loketten. Pavlov-reactie van het management waarop Attila wijst gaat vooral om het belletje van de markt, volgen of vooruit lopen. In vastroesten of veranderen hoor ik – in verschillende functies – dan ook al 30 jaar hetzelfde over communicatie. Functie elders gaat om een rugzak aan ervaring, aan alle kanten van tafel heb ik wel wat geleerd van de spelletjes.
Behoudende Dino versus een veranderlijke organisatie veranderd er niks aan de accreditatie van de resources. Want sticker 350 van de certificatie in vaardigheden of inzichten is de titel van de rol niet zo interessant. De directeur zonder mandaat is even vervelend als de manager zonder kennis want in de risicomijdende organisaties heb je nog sneller een kind dan een besluit.
Behoudend in patchen, maar vooruitstrevend in hybrid cloud.
Beetje mal, maar weer eenvoudig te verklaren met follow-the-money.
Die snoepreisjes en zelf vaardigheden bijhouden is echt niet alleen iets van jou.
Nou ja bijhouden … de old school van PRINCE2, IPMA, PMBOK, MCSE en dan wijzen naar “De behoudendheid van oude honden die geen nieuwe kunstje willen leren” 😛
Met je 30 jaar ervaring in hetzelfde horen over communicatie over vastroesten verandering.
“congres voor nieuwe inspiratie”, mijn god.
Schrijf eens wat software op github/gitlab en geef een linux training 🙂
Follow-the-mon(k)ey is het software onderhoud veelal verplaatst naar lagelonenlanden, goedkoper dan gratis wordt het niet. Voor niets code schrijven voor GitHub/GitLab is hetzelfde als schrijven voor Computable. Institutionele kennisdeling van een expertgroep was leuk zo lang het duurde want show-me-the-money leverde het steeds minder op. Competenties aangaande het spelinzicht leren dat schrijven van algoritmen meer oplevert dan het schrijven van code. Find-the-money wordt uitspitten van logfiles commercieel interessant want filosofisch gezegd moet je de som der delen begrijpen omdat systeembeheer meer is dan servers knuffelen.
Zijn en tijd beloofde Brain Valentine tijdens Microsoft Management Summit in 2002 om van Windows het best beheerde PLATFORM ter wereld te maken. Met beide voeten in de klei klonk dat voor een nuchtere Hollander als John F. Kennedy die eerder een reis naar de maan beloofde op basis van nog uit te vinden technologie:
“We choose to go to the moon in this decade and do the other things not because they are easy.”
In de wet van de remmende voorsprong was de overgang van muis naar CLI/API dan ook zeker niet makkelijk omdat het scripten niet in het curriculum van MCSE zat. Ander platform, ander curriculum ging de didactiek van training niet om het leren van een kunstje maar om weten wat er onder de motorkap zit door het lezen van de systeem documentatie. Net zo saai als het doorspitten van logfiles maar te goed van vertrouwen leerde deze inspanning dat het best beheerde platform niet om de code gaat maar om de processen. Bluf van open source dat de code te lezen is maar dat niemand deze moeite neemt is geen FUD maar een feit door statistisch gegeven aangaande de verwerkingssnelheid van het menselijk brein.
Terughoudendheid in patchen wordt ingegeven door een behoudendheid naar stabiliteit en prestatie aangaande de som der delen. MTBF/MTTR van een platform gaat meer om het dilemma van onderhoudbaarheid door tekorten aan service engineers de snelheid van patchen. De cloud beheerbaar maken of beheersbaar begint bij de infrastructuur, ik moest dan ook lachen toen een manager tegen mij zei dat ik werkeloos zou worden door virtualisatie. De voorspelling die gebaseerd was op nog uit te vinden technologie van draadloos stroom. Het delivery model van Utility/Cloud Computing van services uit de kraan kan namelijk niet zonder de galvanische realiteit van een fysieke infrastructuur.
En wat betreft het plaatsingsmodel van een workload in de hybride cloud is er zoiets als een data fabric, de waterleiding die voor het transport zorgt. Diameter van de waterleiding bepaalt het aantal liters wat je er in een gegeven tijd doorheen krijgt. Natuurkunde voor kleuters gaat de didactiek van uitleg om de gebruikte metafoor. Zeker als we het over abstracties gaan hebben zoals wel bleek uit alle reacties op het eerder schrijven van ‘code’ op deze community. Virtuele snoepreisjes als gevolg van COVID zijn ook leuk maar er gaat niets boven het zijn & tijd van fysieke aanwezigheid voor de roddels aan de hotelbar.
Ik begrijp nu waarom ze je naar een “congres voor nieuwe inspiratie” stuurden.
ff rust..