War on talent: Zo creëer je de juiste engineeringcultuur

Er is meer behoefte aan engineering-talent, en de strijd om talent neemt alleen maar toe. Als een organisatie al een engineer vindt, is er nog een grote kans dat deze nieuwe werknemers binnen een jaar vertrekken, soms zelfs al binnen een maand. De reden hiervoor is dat die organisaties niet de juiste omgeving bieden – ze begrijpen de mentaliteit van de engineer niet. Wat houdt de engineering-mentaliteit in?

Engineers zijn professionals zoals alle anderen, maar ze hebben een aantal specifieke eigenschappen die relevant zijn om de juiste engineeringcultuur te kunnen creëren. In dit verband kan een ‘engineer’ als volgt worden gekenmerkt:

– Engineers maken producten. Hun carrière draait om het maken of aanpassen van een product. Het woord “product” moet hier ruim worden geïnterpreteerd. Het kan om software of een fysiek voorwerp gaan, maar ook om een gewijzigd team of de bedrijfscultuur. Het is echt een creatieve baan: engineers creëren dingen.

– Engineers houden zich bezig met hoe goed een product is gebouwd. Samen met andere rollen zijn ze verantwoordelijk voor bijvoorbeeld economische haalbaarheid en geschiktheid voor gebruik, maar de engineers hebben de primaire verantwoordelijkheid voor de productkwaliteit, de prestaties en andere technische eisen.

– Engineers leven in een meritocratie. Engineers zijn kenniswerkers en ontlenen daarom hun trots aan wat ze weten en hoe goed ontwikkeld hun producten blijken te zijn. Op een gebied waar de stand der techniek zich snel verder ontwikkelt, moeten engineers ook wat kennis betreft voorop blijven lopen, omdat ze anders met hun carrière achteropraken.

Engineers zijn makers

Engineers zijn makers. Hun invloed op de wereld bestaat uit de producten die ze maken en daar zijn ze dan ook met recht trots op. Engineers willen ergens in de wereld iets aanwijzen en zeggen: “Dat heb ik gemaakt.”

Ik was eens aangenaam verrast – en voelde me trots – toen iemand mij bloemen voor mijn verjaardag stuurde: niet vanwege de bloemen zelf, maar vanwege het postlabel op de doos dat was afgedrukt met een programma dat ik voor het postbedrijf had ontwikkeld…

Een goede engineeringcultuur zorgt ervoor dat de engineer zich kan identificeren met het product dat hij maakt via het type werk dat hij doet. De meeste organisaties pakken dit verkeerd aan door zich met name te richten op het werk dat een persoon of team doet. Het blijkt zelfs uit de manier waarop we werknemers aanduiden: ze hebben functietitels als “programmeur”, “tester” of “widgetopschoner”, maar die titels geven alleen aan wat ze doen en niet wat ze maken. Voor een maker spreekt er veel meer trots uit “ik heb dit product gemaakt ” dan uit “ik heb deze taak uitgevoerd”.

Om dit punt toe te lichten: Ik hielp ooit eens een grote retailer met acht Scrum-teams. Die waren opgezet afhankelijk van hun functie: je had een team van Oracle-databaseprogrammeurs, een team van Java-programmeurs, een team van testers, enzovoorts. De Scrum-teams werden echter opgezet rond producten: in dit geval de productcatalogus, de webwinkel, het interne financiële systeem, enzovoorts. Natuurlijk is er altijd wel enige weerstand tegen zo’n verandering, maar er bleek vooral wat weerstand te komen van de enige Oracle-programmeur in het catalogusteam. Ze dacht dat ze, afzonderlijk van haar Oracle-collega’s, alleen zou zijn.

Maar toen gebeurde er iets interessants: ze werd juist veel gelukkiger en voelde zich meer verbonden. Toen ik haar sprak, viel het mij op dat haar eigen identiteit was veranderd. Vóór de verandering noemde ze zichzelf “een Oracle-programmeur”; nu was ze “een lid van het catalogusteam”. Het verschil in motivatie was opvallend en toen ik haar erop aansprak, vertelde ze me dat ze vroeger opdrachten kreeg onder de noemer “Oracle-werk”, maar die eigenlijk weinig te maken hadden met de kerntaken van het bedrijf. Nu voelde ze zich direct verbonden als er een nieuwe productcategorie live ging in de webwinkel, en ze was daar dan trots op.

Het makersschema en het managersschema

Het feit dat engineers makers zijn betekent ook dat ze vaak complexe ideeën en structuren moeten bedenken en onthouden. Dit vergt focus en deze focus wordt vaak verstoord door de omgeving, rituelen, ritmen en interacties in een organisatie.

Paul Graham van YCombinator heeft een heel goed essay geschreven waarin deze term werd geïntroduceerd. Sindsdien is de term ook in andere publicaties opgepikt, zoals in deze goed geschreven post op Farnham Street.

De essentie van “het verschil tussen makers en managers” is dat makers lange, ononderbroken blokken tijd nodig hebben om hun focus te behouden en hun mentale model op te bouwen. Als programmeur was ik pas aan het eind van de werkdag echt “productief” en was ik aan het begin van de dag vaak bezig met het opbouwen van het mentale model van het probleem dat op dat moment speelde. Elke verstoring van die focus is als het omverblazen van een kaartenhuis: je moet weer helemaal opnieuw beginnen, waardoor je veel tijd verliest. 

Een goede engineeringcultuur zorgt ervoor dat makers kunnen werken volgens het makersschema.

Uitdaging en beheersing

Waarom beklimt een bergbeklimmer de berg? Omdat die er is. Engineers worden gemotiveerd door het overwinnen van moeilijk op te lossen problemen. Net als het oplossen van een puzzel is het een boeiende uitdaging en het overwinnen van de uitdaging geeft voldoening. In de lezing “Drive” van Dan Pink (prachtig geïllustreerd door RSAnimate) wordt beheersing genoemd als een van de drie belangrijkste drijfveren. Door bij de oplossing van een probleem te leren en te verbeteren, bereikt de engineer een beheersingsniveau, en die beheersing is wat hem voldoening geeft. Zodra hij de materie echter beheerst, is de uitdaging weg en wordt het saai. En dan gaat hij op naar de volgende uitdaging.

De cyclus van uitdaging – beheersing – verveling is de reden waarom automatiseren, het schrijven van scripts en het bouwen van aangepaste tools zo belangrijk is voor een engineer. De materie die hij beheerst kan nu automatisch worden afgehandeld, waardoor hij tijd heeft om uit te kijken naar nieuwe uitdagingen.

Deze uitdagingencyclus past niet automatisch bij alle organisaties. Sommige hebben alleen maar eindeloze varianten op dezelfde website nodig, of moeten alleen maar kleine aanpassingen in een volwassen product aanbrengen. Een organisatie met een goede engineeringcultuur houdt hier rekening mee om ervoor te zorgen dat hun engineers uitgedaagd en geïnteresseerd blijven. Dit hoeft niet eens zo vaak te zijn: hackathons, ship-it days en varianten op een dag van georganiseerde vrijheid zijn belangrijke initiatieven om gehoor te geven aan die uitdagingskriebel.

Er is zelfs een nog belangrijker reden dat een engineer voortdurend op zoek is naar nieuwe uitdagingen: zijn carrière hangt ervan af. Engineers leven in een meritocratie waarin de succesvolste engineers degenen zijn die de moeilijkste problemen aankunnen en van de huidige stand der techniek op de hoogte zijn. Als een engineer gedwongen is om met verouderde technologie te blijven werken, loopt hij het risico dat zijn marktwaarde zo sterk afneemt dat hij niet meer inzetbaar is…

Een goede engineeringcultuur zorgt dat haar engineers geïnteresseerd blijven en helpt hen om hun marktwaarde te verbeteren met nieuwe uitdagingen. Deze uitdagingen vloeien idealiter voort uit het product dat ze maken. Als dat niet het geval is, dan is het belangrijk om ze op andere manieren uitdagingen te bieden, bijvoorbeeld door hackathons of verkenningsopdrachten in te voeren.

Engineers zijn gefocust op het product van morgen

Hoewel het leuk is om ergens in de wereld een product te hebben, weten engineers dat ze ervoor moeten zorgen dat het product snel en met kwaliteit verder kan worden ontwikkeld. En dat is lastig. Engineers maken zich daarom meer zorgen om de gereedheid voor het product van morgen dan om het huidige product.

Het is een lastige evenwichtsoefening. Enerzijds kun je het product van vandaag altijd heel snel leveren door het onderhouds- en aanpassingsgemak van het product overboord te gooien. Anderzijds kun je te ver gaan door nog een abstractie- of indirectielaag toe te voegen met het oog op een verandering die misschien nooit plaatsvindt. Ervaren engineers weten hoe ze deze twee in evenwicht moeten houden, maar het is niet iets wat je van tevoren volledig kunt voorspellen.

Een onderwerp dat hiermee verband houdt, is aanlever- en onderhoudsgemak. Wanneer zich een probleem voordoet, is de totale reparatietijd de tijd die nodig is om het probleem op te sporen, te analyseren en te verhelpen. In de praktijk bestaat de tijd die nodig is om het probleem te analyseren uit 80-90% van de bestede tijd. Investeren in een snelle analyse van problemen levert een enorme tijdbesparing op en neemt een grote bron van ergernis voor engineers weg.

Een goede engineeringcultuur erkent het belang van het onderhoudsgemak van het product van morgen en laat engineers evenveel ruimte voor aanpassingsmogelijkheden als voor gebruiksmogelijkheden.

Elegantie en functionele schoonheid

Engineers zijn geobsedeerd door elegantie en schoonheid, maar niet in de traditionele zin. Voor een engineer zit de schoonheid in de manier waarop het product is gebouwd, niet in hoe het er aan de buitenkant uitziet. Mijn collega Theo lichtte dit in ons gesprek mooi toe:

“Toen ik met Lego speelde, zag ik echt niet welke kleur de Lego-stenen hadden: ik ging volledig op in het maken van een elegant ophangsysteem. Voor mij was dat de mooiste auto die ik kon maken.”

Een kunstschilder kent het gevaar van te lang aan een schilderij werken. Wanneer het schilderij af is, bestaat de neiging om details steeds verder te verfraaien, met het gevaar dat het werk in zijn geheel wordt verpest. Engineers kunnen dezelfde neiging hebben als ze te ver gaan, maar het duidt wel op een sterke motivatie: de wens om iets te maken dat elegant en mooi is. Iedere software-engineer weet dat “elegante code” of “mooie code” een verdedigbaar streven is, en is in alles wat hij maakt altijd op zoek naar dat gevoel van elegantie.

Aan de andere kant heb je de neerslachtigheid die kan ontstaan als je in een vuile en deprimerende omgeving moet werken. Druk, gebrek aan kennis en tijdgebrek leiden tot shortcuts en gemakkelijke, maar lelijke fixes. Engineers moeten niet alleen kijken naar iets wat in hun ogen lelijk en onelegant is, maar als zij het zelf hebben gemaakt, worden ze ook nog eens voortdurend geconfronteerd met de schande van de kwaliteit die ze hebben geleverd. Je moet de kracht van dit effect niet onderschatten: slechte code is echt een deprimerende omgeving.

Een goede engineeringcultuur respecteert de behoefte van engineers om elegantie en functionele schoonheid te creëren, en zorgt ervoor dat ze de interesse en technische kennis hebben om een volwassen gesprek over technische onderwerpen te voeren. Vanuit een engineeringcultuur bezien is het blind doorjagen van functionele wijzigingen zonder aandacht voor elegantie en functionele schoonheid zo ongeveer het stomste wat je kunt doen.

Dit wil niet zeggen dat we het belang van de organisatie moeten opofferen voor de persoonlijke wensen van engineers. Volgens de engineer dragen schoonheid en elegantie bij tot een goed functionerend product, wat volledig aansluit op de behoeften van de organisatie. Toch kan het bieden van ruimte voor het opschonen van code een zakelijk voordeel hebben waar je niet eerder aan had gedacht: het geluk dat voortvloeit uit het werken in een schone en mooie omgeving.

Het aantrekken en vasthouden van je engineers houdt in dat je moet weten wat hen drijft. Onthoud dat ze makers zijn en dat ze een makersschema hebben. Zorg dat ze voldoende worden uitgedaagd, ondersteun hen in hun carrière, help hen om het product van morgen te bouwen, en steun hen in hun zoektocht naar elegantie. Je zult ervan versteld staan wat ze voor jou doen.