In de praktijk
In de praktijk blijkt verantwoordelijkheid geen vastomlijnd concept te zijn. Het is een voortdurende balans tussen korte en lange termijn, tussen technische en communicatieve prioriteiten, tussen urgentie en belangrijkheid. En soms ook tussen mijn eigen verwachtingen en die van anderen.
Een voorbeeld: als ontwikkelaar weet ik precies of een taak af is. Ik hebt direct zicht op mijn werk. Maar in de rol van HoD gaat het over planning, afhankelijkheden en verwachtingen, en die begrippen zijn veel vager. Wat is ‘klaar’? Wat is ‘voldoende’? Wanneer is iets acceptabel genoeg in het grotere geheel?
Soms voelt een technische optimalisatie logisch vanuit een developer-perspectief, maar in de bredere context is het moeilijk te verantwoorden, gezien alle andere omstandigheden die spelen.
Structuur helpt
Iets dat voor jezelf helemaal helder en logisch is, kan voor een ander helemaal niet zo duidelijk zijn. Dus moet je het zien over te brengen op de ander. Gelukkig hebben we een werkproces dat daarvoor zorgt. De basis is een taak die helder beschrijft wat er moet gebeuren en waarom. Kees heeft een werkwijze opgesteld die doet denken aan Scrum en Kanban, waarbij elke taak een duidelijke flow doorloopt. Deze flow is per klant opgezet, wat ons helpt om grip en inzicht te krijgen: hoeveel werk ligt er in de pipeline.
Omdat wij als HoD ook verantwoordelijk zijn voor planning en procesoptimalisatie, hebben we aan elke taak een ureninschatting en een registratie van werkelijk bestede tijd gekoppeld. Zo krijgen we beter inzicht in de haalbaarheid van onze planning.
Samen met Kees hebben we bovendien een aparte flow opgezet voor technische optimalisaties. Niet alles hoeft projectmatig te zijn, maar het moet wel inzichtelijk zijn.
Gedeelde verantwoordelijkheid
We zijn gestart met een wekelijkse interne ‘developers updatemail’. Enerzijds als waardering voor het harde werk dat wordt verzet, een soort digitaal schouderklopje. Anderzijds om meer duidelijkheid te geven over de planning voor de komende week. Dit format staat nog in de kinderschoenen, maar we willen het verder uitbreiden: bijvoorbeeld met statusupdates en deadlines van lopende projecten.
Belangrijk uitgangspunt: developers zijn zelf verantwoordelijk voor hun planning. Als HoD geven we het eigenaarschap over de korte termijn planning terug aan het team. Wordt een deadline niet gehaald? Dan is het aan de developer om dat zelf te signaleren en hulp in te roepen waar nodig.
Keuzes maken die niet leuk zijn
Toch loop ik regelmatig tegen frustratie aan. Een collega, of ikzelf, zeg dan iets als: “Dat heeft nu geen prioriteit.” Dan kun je je afvragen: wanneer dan wel? Dingen almaar uitstellen zorgt soms voor teleurstelling. Dus, wat moet ik met dat soort taken die tussen wal en schip vallen?
Misschien hoort dat ook bij verantwoordelijkheid: keuzes maken die niet leuk zijn, communiceren dat iets niet gaat gebeuren en accepteren dat je niet alles kunt oplossen. Óf direct inplannen zodat het gewaarborgd is.
Tot slot
Mijn zoektocht naar wat verantwoordelijkheid voor mij betekent is nog niet klaar. Ik ben benieuwd hoe anderen hiermee omgaan: hoe meet jij verantwoordelijkheid? En wat doe jij als dingen anders lopen dan je had gehoopt?
