Teamsfeer en betrokkenheid, en dan pas het gereedschap

Hier is een leuke oefening als je al wat jaren en werkgevers op je cv als developer hebt staan. Geef al die projecten eens een intuïtief punt. Bij een tien zou je morgen meteen weer willen beginnen en bij een drie nog niet als ze je het dubbele salaris boden. Denk er vooral niet te lang over na. Klaar? Geef nu elk project afzonderlijk punten voor de volgende drie eigenschappen.

 

De eerste zou je het nerd appeal kunnen noemen: gebruikte je innovatieve tools, technologieën en/of werkvormen? De tweede gaat over de sfeer binnen het team en de organisatie: hoe hartelijk, behulpzaam en professioneel was die? Hoe zat het tenslotte met je affiniteit tot de organisatie en het product waar je aan werkte? Kreeg je daar een gevoel van trots van, of liet dat je vrij onverschillig? Misschien werkte je wel aan een product waar je moreel niet achter kon staan, zoals bemiddeling van stoute afspraakjes voor mensen in een vaste relatie.

 

Als ik terugkijk op twintig jaar in de IT, scoorden de projecten en werkgevers waar ik ‘t het best naar mijn zin had altijd hoog op teamsfeer en voelde ik affiniteit met het product en verbondenheid met de organisatie, zelfs als inhuurkracht. Technieken en hardware waren daar meestal ondergeschikt aan. Toen ik in 2012 een project louter koos omdat ik met Google Web Toolkit kon werken, liep dat uit op een teleurstelling. Toch lijken met name recruiters te denken dat IT’ers allereerst een werkomgeving zoeken waar ze met de hipste technieken kunnen werken. Of je er ook met inspirerende collega’s aan waardevolle producten kunt werken, beschouwen ze kennelijk als vanzelfsprekend, maar dat is het zeker niet.

 

{ MOET JE ALTIJD EARLY ADAPTER WILLEN ZIJN? }

Ik snap die nadruk op innovatie wel. Het Java-wereldje is immers klein en als je goede developers wil aantrekken, moet je als bedrijf niet bekend staan als die stoffige Java 6 dinosaurus die hun monoliet nog op JBoss 4 draait. Ik ben ook niet happig op zulke projecten. Zoiets ruikt verdacht naar onbeheersbare technical debt. En als het team graag met legacy werkt, heb ik er niets te zoeken. Daarentegen leerde mijn eerste kennismaking met Docker in 2013 mij dat je ook niet per se early adopter moet willen zijn, zeker niet als een techniek nog in de kinderschoenen staat. Een JavaEE /Oracle stack is misschien niet heel hip, maar ik heb liever een saaie en voorspelbare productie-omgeving dan een innovatieve die op willekeurige zondagavonden kuren heeft. “Kom bij ons en je mag werken met AWS, Serverless, Kotlin, Firebase, etc.”. Allemaal hele coole spullen, maar vertel me eerst maar eens met wie ik mag werken. Want in een fijn team ga je fluitend naar je werk, terwijl die coole stack er niet meer toe doet als je een of twee arrogante einzelgängers in je groep hebt.

 

Een disfunctioneel team is niet acceptabel en een verantwoordelijke organisatie moet tijdig maatregelen nemen als zoiets dreigt. Daar zijn boekenkasten over volgeschreven, maar ook zonder dure coaches kun je zelf al veel doen om de binding in je team te verbeteren. Het begint met de juiste instelling jegens je collega’s: ga ervan uit dat het gemotiveerde vakmensen zijn en behandel elkaar zodanig. Werk zoveel mogelijk samen in wisselende combinaties. Dat is niet eenvoudig; integendeel zelfs. Je moet veel beter nadenken over het ontwerp om een codeerklus met drie mensen aan te pakken, maar het resultaat is navenant beter. Het is misschien aantrekkelijker om jezelf in te graven in een probleem en trots als eerste met de oplossing te zwaaien. Maar met dit sologedrag kweek je geen teamgeest. Laat mensen trouwens de samenwerkingsvorm kiezen waar ze zich prettig bij voelen. Niet iedereen doet bijvoorbeeld graag aan Pair Programming. Wees kritisch op elkaars werk, maar maak het niet persoonlijk. Het leuke aan development is dat het zo breed is dat seniors altijd nog kunnen leren van juniors. En de belangrijkste tip: niemand houdt van betweters.

 

{ EAT YOUR OWN DOG FOOD }

Tenslotte vind ik naast teamgeest je betrokkenheid bij het product en de organisatie een stevige factor van betekenis. Zeg eens eerlijk, hoe vaak heb je jouw eindgebruikers daadwerkelijk het product zien gebruiken? Misschien ben je zelf wel die eindgebruiker. Gefeliciteerd, in dat geval hoor je bij de club van eat your own dog food. Ik heb dat zelf niet vaak meegemaakt. Als de klant tevreden was, het team leuk en de techniek boeiend zat ik daar niet zo mee. En toch laat je dan een waardevolle kans liggen. Bij het Havenbedrijf Rotterdam hadden ze dat goed begrepen. Tijdens de introductie bezochten we het coördinatiecentrum op de Kop van Zuid, waar je kilometers ver de schepen kon zien die de verkeersregelaars met onze software in goede banen leidden. Daarna konden we ze tijdens een rit met een patrouillevaartuig ook nog van dichtbij zien. Ondanks dat we niet de eindgebruikers waren van onze eigen software, werden we wel vanaf de eerste dag bij het proces betrokken.

 

Concluderend zou ik willen stellen dat bedrijven beter moeten beseffen dat developers interesses, normen en waarden hebben die verder reiken dan regels code kloppen.

Misschien nemen sommigen een matige teamsfeer voor lief als ze kunnen werken aan een geweldig innovatief product, zoals een super-efficiënte auto-accu die in vijf minuten laadt. Wie weet. Zelf weet ik in ieder geval zeker dat ik als niet-roker, die zijn grootvader nooit gekend heeft vanwege een vroege tabaksdood, bijvoorbeeld nooit zou willen werken voor Philip Morris of een lobbyist van die industrie. Deze voorbeelden zijn bewust wat gechargeerd, maar ertussenin valt een wereld te winnen. Als developer kun je meer interesse tonen in hoe de eindgebruikers jouw product gebruiken, ook als je niet rechtstreeks aan de gebruikersinterface werkt. Voor het management is hier nog een grotere taak weggelegd, want om meer betrokkenheid te creëren, moet je je mensen wel actief betrekken. Wees dus waakzaam dat er geen eilandcultuur ontstaat. Betrokken medewerkers zijn enthousiaste medewerkers, en enthousiaste mensen zijn doorgaans productief en trouw aan je bedrijf. Daar kun je zakelijk toch niks op tegen hebben?

 

Jasper is na 20 jaar in verschillende rollen nog altijd nieuwsgierig, zowel over het development vak zelf als over de technieken erachter.