Functietitels vervormen de werkelijkheid

In Being at Work¹ maakt Mark Cole een interessante observatie over het vervormende effect van functietitels. Cole benadert deze problematiek vanuit existentialistisch perspectief, dus in zijn analyse betekent dit: een vervormend effect op de zelfperceptie.

Hij geef het voorbeeld van een manager die meent dat hij doortastend moet zijn, “omdat dat nu eenmaal is wat een goede leider doet.” Maar als zulke doortastendheid helemaal niet in zijn aard ligt, en ook eigenlijk niet past in het beeld van de persoon die hij wil zijn, dan handelt hij te kwader trouw.

Natuurlijk blijft dit fenomeen niet tot managers beperkt. Ik heb vaak zat gezien dat mensen lager in de hiërarchie niet-functionerende processen en patronen accepteren, omdat ze menen dat het verbeteren van deze zaken een taak is van een ander – iemand in een leiderschapspositie, zoals de senior of de tech lead of de manager. Dat heeft hen overigens nooit tegengehouden te klagen over die processen en patronen bij de koffieautomaat.

Wie werkt, speelt een rol en voegt zich naar de verwachtingen die horen bij die rol. Persoonlijk heb ik weinig moeite met deze observatie – het idee dat een persoon te allen tijden authentiek moet zijn, is me altijd al – wat is het woord? – puberaal voorgekomen. Maar daar maak ik een belangrijke kanttekening bij: iemand die veertig uur per week volslagen inauthentiek handelt, doet zichzelf geen plezier. Cole heeft een punt, in zoverre dat als de rol en het authentieke zelf te ver uit elkaar liggen, dit op termijn tot existentiële crises kan leiden.

Programmeren en analyseren

Maar functietitels hebben ook een vervormend effect op de werkvloer zelf. Hun effect op de manier waarop werknemers hun taak opvatten, kan desastreuze gevolgen hebben.

Mijn team heeft bijvoorbeeld tijden geworsteld met het op orde krijgen van de Product Backlog. We hadden een ruw idee van het werk dat onze kant op kwam, maar we leken het maar niet voor elkaar te krijgen om Product Backlog Items (PBI’s) aan te maken die voldoende uitgewerkt waren om op te pakken.

Wanneer dit punt periodiek voorbijkwam in onze Retrospective, dan was het antwoord keer op keer: “We hebben eigenlijk een analist nodig. Daar staat een vacature voor uit, maar we hebben er nog niemand voor gevonden.” De implicatie: we moeten wachten tot er een analist is aangenomen om dit probleem voor ons op te lossen.

Dat veronderstelt: een analist analyseert (en verwerkt deze analyse in PBI’s) – en programmeurs zetten die analyse (i.e. PBI’s) om in code. Analyse en implementatie zijn twee verschillende taken – en de functietitels impliceren dat deze ook door twee verschillende personen dienen te worden uitgevoerd.

Maar waarom zou een programmeur niet een businessprobleem kunnen analyseren? Wat houdt een programmeur tegen om met een stakeholder aan tafel te gaan zitten en te vragen: wat probeer je te bereiken? Wat heb je daarvoor nodig? Waar loop je nu tegenaan? Waarom is dat een probleem?

Met Cole meen ik: wat ons tegenhoudt is de functietitel. Of liever: wat ons tegenhoudt zijn de verwachtingen die deze titels – onterecht! – scheppen over de manier waarop we het werk dienen te verdelen. De titel zelf is niet het probleem; het probleem is hun vervorming ten aanzien van de werkelijkheid.

En natuurlijk beperkt dit probleem zich niet tot programmeurs en analisten. Er zijn ook programmeurs – gelukig steeds minder – die menen dat testen de taak is van de tester. En programmeurs die menen dat technisch beheerders verantwoordelijk zijn voor de uitrol naar productie (zie ook deze blog). En dat teamhygiëne iets is van de scrum master.

Essentieel

Het probleem begrijpen is een essentieel onderdeel van softwareontwikkeling. Een ontwikkelaar die geld aanneemt om prachtige code te schrijven om een niet-bestaand probleem op te lossen, is een slechte softwareontwikkelaar.

Het schrijven van geautomatiseerde tests is een essentieel onderdeel van softwareontwikkeling. Een ontwikkelaar die vandaag een belangrijk probleem oplost zonder enig oog te hebben voor het feit dat de werkelijkheid, en dus het probleem, morgen zal veranderen, is een slechte ontwikkelaar.

Het uitrollen van code is een essentieel onderdeel van softwareontwikkeling. Een ontwikkelaar die volledig doorgeteste, onderhoudbare code schrijft die nooit een eindgebruiker zal bereiken, is een slechte ontwikkelaar.

Samenwerken met teamgenoten is een essentieel onderdeel van – werk in het algemeen. Wie niet kan samenwerken maakt zichzelf een knelpunt, en wie zichzelf een knelpunt maakt, is een slechte ontwikkelaar.

Ik zeg niet: een softwareontwikkelaar moet een expert zijn op al deze gebieden. Maar een goede softwareontwikkelaar heeft wel kennis van al deze gebieden – en werkt nauw samen met mensen die wél expert zijn op deze gebieden. Want een goede softwareontwikkelaar realiseert zich dat zijn functietitel zijn rol niet definieert, maar slechts het zwaartepunt van zijn werkzaamheden aangeeft.

boeken · filosofie · software ontwikkelaar (rol) · verantwoordelijkheid