In september 2000 werkte ik nog niet zo lang in de detachering. Mijn werkgever Stan vond het een goed idee om mij wat technische ervaring te laten opdoen en regelde daarom een traineeopdracht bij het Unix Security-team van de toenmalige Postbank in Arnhem. Ik was bepaald geen techneut, en dat ben ik eigenlijk nooit geworden, al leek het mij verstandig om wat meer te begrijpen van de techniek achter de IT-systemen waarmee ik werkte. Dat die leeropdracht zou uitgroeien tot een van de meest leerzame ervaringen uit mijn loopbaan, had ik op dat moment niet kunnen vermoeden.

Mijn teamleider bij de Postbank was Richard Vos, een bijzonder ervaren Unix-specialist die onze organisatie goed kende. Richard was zo iemand die ontzettend veel van zijn vak wist en die kennis ook graag met anderen deelde. Hij gaf mij een overzichtelijke opdracht waarmee ik de verschillende Unix-systemen van de Postbank kon leren kennen. Ik moest alle gebruikers en groepen op de verschillende machines inventariseren, hun identificatienummers vergelijken en vervolgens een voorstel maken om eventuele afwijkingen op te schonen.

Om te begrijpen wat er vervolgens gebeurde, is een klein beetje kennis van Unix handig. Binnen Unix heeft iedere gebruiker een identificatienummer, een zogenaamde UID. Zo kan een gebruiker met de naam Anton bijvoorbeeld nummer 784 hebben. De naam maakt het voor mensen herkenbaar, terwijl het systeem zelf met nummers werkt om onder andere toegangsrechten vast te stellen. Ook groepen hebben dergelijke nummers. Wanneer verschillende systemen onderling communiceren of bestanden uitwisselen, is het belangrijk dat deze identificaties correct op elkaar aansluiten.

De Postbank beschikte destijds over verschillende Unix-systemen die onderling gegevens uitwisselden. Zo was er Girofoon, waarmee klanten telefonisch konden bankieren, en waren er systemen voor het opvragen en verwerken van saldoinformatie. Op meerdere machines kwamen dezelfde gebruikersaccounts voor, zodat duidelijk was welke gebruiker of welk proces toegang tot bepaalde informatie had. Wanneer een gebruiker op de ene machine nummer 784 had en op een andere machine nummer 912, kon dat ongewenste verschillen opleveren. Mijn opdracht was om die afwijkingen zichtbaar te maken en een voorstel te schrijven om ze te corrigeren.

Ik ging enthousiast aan de slag, maakte overzichten van alle gebruikers en groepen en zette de nummers netjes naast elkaar in tabellen. Vervolgens schreef ik een wijzigingsvoorstel waarin precies stond welke accounts op welke machines moesten worden aangepast. Richard beoordeelde mijn werk, keurde het voorstel goed en gaf mij toestemming om de wijzigingen uit te voeren. Het leek een prima oefening voor iemand die Unix nog moest leren kennen.

Een prachtige nazomerdag

Het was een donderdagmiddag, als mijn geheugen mij niet bedriegt. Mijn toenmalige Braziliaanse vriendin was op vakantie in Nederland en zou mij die middag bij de Postbank komen ophalen. Het was prachtig nazomerweer, de zon scheen volop en het was heerlijk warm. Josie had aan de overkant van de straat, recht tegenover de Postbank, een bankje gevonden waar ze in haar zomerse jurkje heerlijk van het zonnetje kon genieten terwijl ze op mij wachtte.

Binnen was ik ondertussen bezig met het uitvoeren van mijn goedgekeurde wijzigingen. Het ene gebruikersaccount na het andere werd netjes aangepast en alles verliep volgens plan. Ik begon er inmiddels aardig vertrouwen in te krijgen dat ik deze opdracht zonder problemen kon afronden.

Totdat ik op de Girofoon-machine bij een gebruiker kwam die de naam ‘root’ droeg.

Voor wie Unix niet kent, root is de belangrijkste gebruiker van het systeem, de zogenaamde superuser. Deze gebruiker beschikt over vrijwel onbeperkte bevoegdheden en speelt een essentiële rol bij systeembeheer en belangrijke processen. Normaal gesproken heeft root identificatienummer 0, waarmee deze gebruiker een bijzondere positie inneemt binnen Unix.

Alleen had root op deze machine een afwijkend nummer, ergens in de 700, meen ik mij te herinneren. Dat was mij tijdens mijn inventarisatie natuurlijk opgevallen en ik had het keurig opgenomen in mijn wijzigingsvoorstel. Net als bij de andere afwijkingen stelde ik voor om het bestaande account te verwijderen en opnieuw aan te maken met het juiste nummer.

Richard had dat voorstel goedgekeurd, dus ik voerde de wijziging uit zoals ik die had beschreven.

Het verwijderen van root verliep probleemloos. Toen ik het account vervolgens opnieuw wilde aanmaken, ontdekte ik alleen dat dit niet meer lukte. Ik probeerde verschillende commando’s, controleerde mijn handelingen en bleef zoeken naar een oplossing. Inmiddels had ik anderhalf uur lang vergelijkbare wijzigingen uitgevoerd en die waren allemaal goed gegaan. Ik begreep werkelijk niet waarom deze ene gebruiker ineens zoveel problemen opleverde.

Ondertussen begon het om mij heen steeds onrustiger te worden. Collega’s liepen heen en weer, overlegden met elkaar en probeerden kennelijk een serieus probleem op te lossen. Ik kreeg die onrust wel mee, al was ik vooral geconcentreerd op mijn eigen werkzaamheden. Ik baalde dat ik mijn opdracht niet kon afronden en bleef proberen om root opnieuw aan te maken.

Op een gegeven moment kwam Richard bij mij staan en vroeg hoe het ging. Ik vertelde hem dat het niet zo best ging, omdat ik één gebruiker met geen mogelijkheid opnieuw aangemaakt kreeg. Toen hij vroeg welke gebruiker dat was, antwoordde ik dat ik root had verwijderd en hem nu niet meer terug kon krijgen.Richard keek mij aan, draaide zich vervolgens naar de rest van het team en riep:

‘Jongens! We hebben de oorzaak!’

De impact van één kleine wijziging

Wat ik op dat moment onvoldoende had beseft, was dat ik zojuist een van de belangrijkste gebruikersaccounts van het systeem had verwijderd. Door het ontbreken van root konden belangrijke systeemprocessen niet meer functioneren en was een cruciaal onderdeel van de betalingsverwerking van de Postbank ontregeld. En de Postbank was in die tijd een van de grootste banken van Nederland. Dagelijks werden er miljoenen financiële transacties verwerkt. Een verstoring van de systemen kon daardoor gevolgen hebben voor een enorm aantal klanten en bedrijven.

Gelukkig speelde dit zich af in 2000, toen een groot deel van de daadwerkelijke betalingsverwerking nog ’s nachts in batches plaatsvond. De betalingen die die nacht verwerkt moesten worden, stonden dus nog niet onmiddellijk stil. Het probleem moest alleen wel voor de nachtelijke verwerking zijn opgelost. Als dat niet zou lukken, konden de gevolgen de volgende dag bijzonder groot zijn.

Mijn collega’s waren inmiddels druk bezig om de situatie te herstellen. Zelf voelde ik mij behoorlijk verantwoordelijk voor wat er was gebeurd en wilde ik graag helpen. Alleen had ik geen idee hoe je een verdwenen root-account op een dergelijk systeem moest herstellen. De mensen om mij heen beschikten over de technische kennis die daarvoor nodig was en ik kon weinig anders doen dan hen hun werk laten uitvoeren.

Dus besloot ik mij nuttig te maken door koffie en andere drankjes te halen voor de collega’s die zich uit de naad werkten om het probleem op te lossen.

Daar stond ik dan, als enthousiaste Unix-trainee die met één eenvoudige wijziging een belangrijk onderdeel van het betalingsverkeer van een van de grootste banken van Nederland had ontregeld. Mijn belangrijkste bijdrage aan het herstel was inmiddels het verzorgen van de koffie.

En dan was er ook nog Josie

Ondertussen zat Josie nog steeds heerlijk buiten in het zonnetje op haar bankje tegenover de Postbank. Ze had mij inmiddels gebeld om te vragen hoelang het nog zou duren, want onze oorspronkelijke afspraak om samen naar huis te gaan was behoorlijk uitgelopen.

Richard vroeg op een gegeven moment of mijn vriendin inderdaad buiten zat te wachten. Toen ik dat bevestigde, zei hij dat ik haar onmiddellijk naar binnen moest halen. Ik vond dat een wat merkwaardige reactie en legde uit dat Josie daar waarschijnlijk weinig voor voelde. In Brazilië was het volgens haar helemaal niet gebruikelijk om zomaar bij de werkgever van je partner naar binnen te lopen. Zij beschouwde dat als een professionele omgeving waar ze als bezoeker weinig te zoeken had.

Richard bleef echter aandringen en verzekerde mij dat hij later wel zou uitleggen waarom hij dat zo belangrijk vond.

Ik ging naar beneden om Josie op te halen en vertelde haar in de lift wat er aan de hand was. Ik had een behoorlijk serieus probleem veroorzaakt en wilde eigenlijk blijven totdat alles was opgelost. Dat begreep ze gelukkig prima en eenmaal boven stelde Richard zich netjes aan haar voor. Uiteraard maakte hij ook de nodige grapjes over haar vriend, die inmiddels een hele afdeling aan het werk had gezet.

Toen ik Richard vervolgens vroeg waarom hij er zo op had aangedrongen dat Josie naar binnen zou komen, vertelde hij iets wat ik totaal niet wist.

De straat tegenover de Postbank was tot enkele jaren daarvoor namelijk een bekende tippelzone geweest.

En precies daar zat mijn jonge Braziliaanse vriendin, in haar zomerse jurkje, heerlijk ontspannen op een bankje in het zonnetje, volkomen onwetend van de vroegere functie van die plek.

Josie had zich al afgevraagd waarom er toch zoveel automobilisten naar haar toeterden en zwaaiden. Ze had de belangstelling wel opgemerkt, alleen begreep ze niet goed waar die vandaan kwam. Met de uitleg van Richard werd dat ineens een stuk duidelijker.

Zo hadden we die middag allebei voor de nodige opschudding gezorgd, ieder aan een andere kant van dezelfde straat, zonder dat we zelf aanvankelijk begrepen wat er aan de hand was.

Een les die ik nooit meer vergat

Tegen zeven uur ’s avonds waren mijn collega’s een heel eind op weg met het herstel. Richard kwam naar mij toe en vertelde dat hij het waardeerde dat ik was gebleven en mijn verantwoordelijkheid wilde nemen. Tegelijkertijd zag hij dat ik technisch niets meer kon bijdragen. Hij stelde daarom voor dat ik samen met Josie naar huis zou gaan en nog even van de avond zou genieten.

Ik vroeg hem wel om mij een sms te sturen zodra het probleem was opgelost, omdat ik toch graag wilde weten of alles weer normaal functioneerde. Die sms kwam gelukkig en de nachtelijke betalingsverwerking kon doorgaan. De Postbank haalde de volgende dag de krant niet.

De dag erna belde Stan, mijn werkgever, mij op. Hij lag werkelijk in een deuk toen hij hoorde wat er was gebeurd. Volgens hem had ik ongeveer de beste Unix-les gekregen die iemand aan het begin van zijn technische ontwikkeling kon meemaken. Hij wist één ding zeker: deze fout zou ik nooit meer maken. Daarin had hij volkomen gelijk.

Inmiddels zijn we 26 jaar verder en heb ik in mijn loopbaan heel wat ervaringen opgedaan. Toch is deze donderdagmiddag in Arnhem mij altijd bijgebleven, vooral vanwege twee lessen die veel verder reiken dan alleen de techniek.

De eerste les kan ik samenvatten in een zin die ik sindsdien regelmatig gebruik:

Al is de opdracht nog zo klein, de impact kan gigantisch zijn.

Die uitspraak raakt voor mij aan iets wat in procesmanagement en changemanagement nog altijd van groot belang is. We werken voortdurend met wijzigingen, klein en groot, waarbij het verleidelijk kan zijn om eenvoudige of routinematige werkzaamheden als vanzelfsprekend te beschouwen. Een wijziging die al tientallen keren zonder problemen is uitgevoerd, roept nu eenmaal minder vragen op dan een complexe aanpassing aan een belangrijk systeem.

Toch zegt de eenvoud van een wijziging bijzonder weinig over de mogelijke gevolgen ervan. Juist wanneer iets vertrouwd aanvoelt, bestaat het risico dat we minder kritisch kijken naar de afhankelijkheden tussen systemen en processen. Welke onderdelen worden geraakt door de wijziging? Wat gebeurt er wanneer de uitvoering anders verloopt dan verwacht? En beschikken we over een goede mogelijkheid om de oorspronkelijke situatie te herstellen? Dat zijn vragen die aandacht verdienen, ongeacht de omvang van de change.

Hetzelfde geldt voor de beoordeling en goedkeuring van wijzigingen. Of dat nu gebeurt door een Change Manager, binnen een CAB (Change Advisory Board) of via een vooraf vastgesteld proces voor routinematige wijzigingen, een goedkeuring heeft alleen waarde wanneer de mogelijke risico’s daadwerkelijk zijn overwogen. Een eenvoudige change hoeft geen ingewikkelde procedure te doorlopen, zolang de zorgvuldigheid waarmee naar de mogelijke impact wordt gekeken behouden blijft.

Mijn ervaring bij de Postbank is daarvan een treffend voorbeeld. Ik had mijn inventarisatie netjes uitgevoerd, de verschillen vastgelegd en een voorstel geschreven dat vervolgens door een ervaren specialist was goedgekeurd. Voor ons beiden leek het een overzichtelijke administratieve correctie. We hadden onvoldoende stilgestaan bij wat die ene aanpassing kon betekenen voor de werking van het systeem.

Daar hoort nog een andere les bij. Wanneer je tijdens werkzaamheden vastloopt en zelf geen oplossing kunt vinden, is het belangrijk om tijdig hulp te vragen. Je kunt immers niet altijd overzien welke andere processen afhankelijk zijn van het onderdeel waarmee jij bezig bent. Wat voor jou een klein technisch probleem lijkt, kan ergens anders al veel grotere gevolgen hebben.

Verantwoordelijkheid begint bij jezelf

De tweede les die ik die middag leerde, gaat over leiderschap en verantwoordelijkheid. En naarmate ik ouder word en meer ervaring opdoe, merk ik dat juist deze les steeds meer betekenis voor mij krijgt.

Richard heeft mij die middag namelijk nooit de schuld gegeven van wat er was gebeurd. Hij had alle aanleiding om boos te zijn. Een relatief onervaren trainee had een belangrijk systeem ontregeld en zijn hele team moest zich inspannen om de gevolgen te herstellen. Toch koos hij ervoor om op een heel andere manier met de situatie om te gaan.

Hij vertelde mij dat ik precies had uitgevoerd wat in mijn wijzigingsvoorstel stond. Ik had mijn analyse gemaakt, de afwijkingen gevonden en zorgvuldig beschreven welke wijzigingen ik wilde uitvoeren. Ook het verwijderen en opnieuw aanmaken van root stond gewoon in dat voorstel. Richard had het gelezen en goedgekeurd.

Daarom vond hij dat de verantwoordelijkheid bij hem lag. Als ervaren Unix-specialist en teamleider had hij de mogelijke gevolgen moeten herkennen en mij moeten behoeden voor deze fout. Hij nam die verantwoordelijkheid zonder aarzeling op zich en gaf mij daarmee een voorbeeld dat ik mijn hele verdere loopbaan ben blijven onthouden.

Als je wilt dat mensen verantwoordelijkheid durven nemen, moet je ook bereid zijn verantwoordelijkheid voor hen te nemen.

Die gedachte heeft mij in mijn eigen ontwikkeling sterk beïnvloed. Leiderschap heeft voor mij nooit uitsluitend te maken gehad met een formele positie of een hiërarchische verantwoordelijkheid. Ook wanneer je functioneel verantwoordelijk bent voor mensen, processen of resultaten, heb je invloed op de manier waarop anderen hun werk kunnen doen en zich daarbij voelen.

Een veilige werkomgeving ontstaat wanneer mensen weten dat ze eerlijk kunnen zijn over wat er misgaat. Wanneer ze vragen durven stellen, onzekerheden durven uitspreken en fouten kunnen toegeven zonder onmiddellijk bang te hoeven zijn voor de gevolgen voor henzelf. Dat vraagt van degene die verantwoordelijkheid draagt dat hij ook naar zijn eigen aandeel durft te kijken.

Richard deed dat op een middag waarop de druk behoorlijk groot was. Hij beschermde een onervaren medewerker, nam zijn eigen verantwoordelijkheid serieus en liet zien dat je van een fout vooral iets kunt leren wanneer mensen de ruimte krijgen om er open over te spreken.

Ik heb die middag dus aanzienlijk meer geleerd dan de basisbeginselen van Unix. Ik leerde hoe een kleine handeling grote gevolgen kan hebben, hoe belangrijk zorgvuldigheid is bij het beoordelen van wijzigingen en hoeveel verschil het maakt wanneer iemand verantwoordelijkheid neemt voor de mensen die aan hem zijn toevertrouwd.

En voor wie zich afvraagt of ik sindsdien nog weleens iets met Unix heb gedaan: daar ben ik de afgelopen 26 jaar ver vandaan gebleven.

Koffie haal ik gelukkig nog steeds graag voor de jongens en meiden die er meer verstand van hebben.