Brugwachters, kanovaarders, mieren en ondersteuners

022-Thumbnail brugwachtershuisje
Waarschijnlijk kent iedereen het verhaal van de brugwachter, die steeds meer managementlagen boven zich kreeg, totdat de kosten zo uit de hand liepen dat er maatregelen nodig waren en de brugwachter werd ontslagen.
En anders vast wel het verhaal van de kanorace, waarbij het team met één kanovaarder en zeven instructeurs het steeds moest afleggen tegen het team met zeven kanovaarders en één instructeur, zodat de conclusie uiteindelijk onontkoombaar was: die ene kanovaarder presteerde onder de maat.
Maar anders toch zeker het verhaal van de mier, die zo wanhopig werd van alle dieren die haar werk in goede banen kwamen leiden dat ze ten slotte werd weggestuurd, ‘omdat zij blijk gaf van een tekort aan motivatie en een houding had die tot conflicten leidde’.
 
Als er zoveel verhalen de ronde doen over hetzelfde onderwerp – een overdosis management – kan het haast niet anders of we hebben hier een situatie te pakken die zeer herkenbaar is.
Tenminste, voor de brugwachters, kanovaarders en mieren onder ons.
(Het is niet duidelijk of ook managers zich in de beschrijvingen herkennen.)
 
Uit deze verhalen zou je zomaar de conclusie kunnen trekken dat elke vorm van management onnodige overhead is en dat we beter af zijn zónder.
Die conclusie is onjuist.
Dat neemt niet weg dat al dat gemanage wel een beetje is doorgeslagen.
 
Laten we voor het gemak even stellen dat een organisatie bestaat uit de onderdelen werkvloer en management.
Dan zijn we het er vermoedelijk over eens dat het management organiseert, coördineert, controleert en nog allerlei andere nuttige taken uitvoert, maar dat het de werkvloer is die het eigenlijke product maakt, datgene waar de organisatie zijn bestaansrecht aan ontleent.
Maar als dat zo is, waar komt dan die wijdverbreide neerbuigendheid ten opzichte van de werkvloer vandaan, en tegelijkertijd het grote belang dat juist aan management wordt gehecht?
Ik denk dat het antwoord op die vraag simpel is: omdat het management in de positie is om te bepalen wat belangrijk is.
En managers vinden managen nu eenmaal belangrijk.
En daar zouden wij allemaal begrip voor moeten hebben, want niemand van ons is ook maar een haar beter. Zou bijvoorbeeld het kantinepersoneel het voor het zeggen krijgen, dan kwam eerst de catering, en daarna heel lang niets. Ging de financiële afdeling er over, dan waren de cijfers het enige echte hart van het bedrijf. En dan hebben we het nog niet eens over software-ontwikkelaars; zelfs zonder dat ze iets wordt gevraagd, laten de meeste ontwikkelaars die ik ken regelmatig weten dat er maar één type werk is dat er echt toe doet, en dat is ontwikkelen.
 
Nu zouden we die ongefundeerde gewichtigdoenerij van managers natuurlijk kunnen afdoen met een geamuseerde glimlach – gun ze ook wat en ze zijn toch lekker bezig!
Maar daarvoor is die overwaardering van management toch te hinderlijk.
Zo was er bijvoorbeeld het geval van de ICT-specialist die een autoriteit was op zijn vakgebied en veelvuldig werd geraadpleegd door vakbroeders binnen en buiten zijn eigen organisatie. Op een dag paste zijn werkgever de functiewaardering aan en bleek dat deze inhoudelijke topper helaas niet langer senior kon blijven, omdat hij niet voldeed aan een van de belangrijkste nieuwe eisen voor het seniorschap: minstens vijf mensen ‘aansturen’ (wat dat dan ook maar moge betekenen). Er moest een halve opstand aan te pas komen voordat hij zijn functie en salaris mocht behouden.
Daarmee vergelijkbaar zijn de situaties waarin een collega met voortreffelijke inhoudelijke kwaliteiten alleen nog een carrière(- en salaris)stap kan maken door over te stappen naar een managementfunctie. Een managementfunctie vraagt echter andere talenten dan een inhoudelijke. Zo heb ik meerdere malen uitstekende techneuten heel matige managers zien worden – wat zowel voor de werkvloer als het management een achteruitgang was, en waarschijnlijk al helemaal voor de persoon in kwestie. (Die als manager wel meer verdiende natuurlijk, dat dan weer wel.)
 
Managementfuncties trekken dus niet alleen mensen aan die daar geknipt voor zijn vanwege hun kwaliteiten en interesses, maar ook mensen die uit zijn op een hogere beloning en dito status.
En dan heb je nog de figuren die graag de baas willen zijn.
Maar zeker in een ICT-organisatie is de werkvloer vaak net zo hoog opgeleid als het management, zo niet hoger. Die mensen hebben geen behoefte aan een baas die ze vertelt wat ze moeten doen, want dat weten ze zelf minstens zo goed.
Ze hebben wel belang bij iemand die zorgt dat ze lekker hun werk kunnen doen. Die faciliteert, zich dienstbaar opstelt, coacht, luistert naar wat de inhoudelijk specialisten te vertellen hebben. Of zoals Steve Jobs het zei: ‘It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.’
Kortom, ze hebben geen behoefte aan een baas, maar aan de juiste ondersteuning.
 
In de loop der jaren zijn de managementgelederen gegroeid, gegroeid en verder gegroeid, tot een omvang die menigmaal in geen verhouding meer staat tot hun bijdrage aan de organisatiedoelstellingen.
De werkvloer torst de last van te veel lagen management, die allemaal hun stempeltjes willen drukken, hun vinkjes willen zetten en hun plasjes willen doen.
In dat management zijn de goede managers ondergesneeuwd geraakt onder de baantjesjagers.
Een tegenbeweging is inmiddels op gang gekomen; er wordt beweerd dat de manager zijn langste tijd wel heeft gehad.
Maar managen – in de zin van strategie bepalen, organiseren, structureren, coördineren, enzovoorts – is een nuttige activiteit, die in een organisatie van enige omvang niet gemist kan worden. Als de manager wordt afgeschaft, zullen deze taken alsnog worden uitgevoerd, maar dan meer versnipperd en waarschijnlijk deels door mensen die dat niet goed kunnen en die er trouwens ook helemaal geen zin in hebben.
 
Dus laten we nou niet het kind met het badwater weggooien.
We moeten niet af van managen op zich, maar van de uitwassen daarvan.
En dat kan prima door management als zodanig te behouden, maar wel terug te brengen tot de juiste proporties.
Bijvoorbeeld door het nemen van een aantal eenvoudige maatregelen:
 
Herwaardering van functies, met als uitgangspunt de bijdrage aan de organisatiedoelstellingen
Als het perspectief wordt losgelaten dat managen sowieso een hogere bezigheid is dan het realiseren van een product, en er objectief wordt gekeken welke bijdrage een functie levert aan het organisatieresultaat, dan zal blijken dat niet alleen management-, maar ook inhoudelijke functies lange doorgroeipaden hebben.
Voor specialisten zijn er dan geen financiële prikkels meer om hun functie voor een managementfunctie te verruilen. Ze zullen die overstap alleen nog maken als dat werk hen inhoudelijk trekt – en daar is uiteraard niets op tegen.
 
‘Management’ wordt ‘ondersteuning’
Managen is geen doel op zich, maar een middel, dat ervoor moet zorgen dat de noodzakelijke processen binnen een organisatie soepel verlopen. De benaming ‘ondersteuning’ is daarvoor eigenlijk beter op zijn plaats.
Laten we die term dan ook gaan gebruiken.
Het zal degenen die niet uit zijn op de inhoud maar op de status van een functie, vrijwel zeker ontmoedigen. ‘Manager’, ‘chef’ of ‘baas’ klinkt op feestjes toch net wat anders dan ‘ondersteuner’…
 
Ook het omdraaien van het organogram kan een frisse kijk geven op de zaken:
 
022-Organogram ondersteboven
 
Zeg nou zelf, een heel ander gezicht!
 
De zaken weer in het juiste perspectief gaan zien, zal een organisatie alleen maar voordelen opleveren.
Goede vakinhoudelijke mensen blijven behouden voor hun werk.
In de managementlagen zullen de door status en geld gedreven collega’s overstappen naar een andere organisatie of opgelucht terugkeren naar hun plek op de werkvloer.
De echte managers, die begrijpen en leveren waar de organisatie behoefte aan heeft, komen vanzelf bovendrijven. Het zijn er dan niet alleen een stuk minder, maar ze zijn vooral ook beter, en ze komen eindelijk weer eens aan hun eigenlijke werk toe.
 
De organisatie weer in balans.
Brugwachters, kanovaarders, mieren en ondersteuners: iedereen gelukkig.
 
Waar wachten we eigenlijk nog op?
 
022-Brugwachtershuisje

Pokkending

021-Thumbnail decor
Wij IT-ers zijn onophoudelijk bezig om het de opdrachtgever en de eindgebruiker naar de zin te maken.
Zweten, zwoegen, ploeteren, niets is ons te veel.
Alles om die kreten van blijde verrassing te horen.
Die welgemeende complimenten in ontvangst te nemen.
Die dolgelukkige gezichten te zien.
Nee nee nee, hijs ons maar niet op de schouders, wij moeten snel weer verder!
Er is immers nog zoveel te doen!
 
Afijn, waarom verder uitweiden; dat dit het leven is van de gemiddelde IT-er, is immers algemeen bekend.
Wat echter niet iedereen weet, is dat we ook weleens iets doen waarbij ultiem gebruikersgeluk niet ons primaire doel is.
Wel ons secundaire, natuurlijk.
Maar toch: een ongewone situatie, waar beide partijen dan ook vaak heel wat moeite mee hebben.
 
Waar gaat het om: de Proof of Concept, kortweg de PoC.
Wat je doet tijdens zo’n PoC – de naam zegt het al – is het beproeven van een concept.
Nieuwe dingen testen dus. Van alles uitproberen.
Met als doel: leren.
Alle tijd die je tijdens zo’n traject besteedt aan wat je al weet of kunt, houdt je af van de dingen waar het je werkelijk om te doen is. ‘Het slimmigheidje’, ‘de korte klap’ en zelfs ‘de vieze truc’, normaal gesproken uit den boze, zijn bij een PoC daarom vaak een prima keus.
Heeft je PoC bijvoorbeeld niets te maken met autorisatie? Dan mogen de testusers die je aanmaakt toch gewoon alles. Kun je met vijf ‘poppetjes’ aantonen wat je wilt aantonen? Dan maak je je er niet druk over dat het in werkelijkheid om duizenden personen zal gaan. En heb je even snel wat invoer nodig die verder niet van belang is? Dan is hard coderen geen enkel probleem.
Alles mag, zolang je maar te weten komt wat je te weten wilde komen.
Geleerde lessen zijn dus het eigenlijke resultaat van zo’n PoC, die echter ook nog een bijproduct heeft: een proeflap, een probeersel. Een pokkending, zeg maar.
Als het goed is tenminste.
Want wie uiteindelijk iets gemaakt blijkt te hebben dat prima in elkaar zit, is misschien niet erg creatief geweest. Een beetje voorzichtig. Heeft vooral binnen de lijntjes gekleurd. En daarmee vast niet alles geleerd wat er te leren viel.
 
Ook bij een demo kan het zo zijn dat het tastbare product niet het doel is, maar een middel.
Een collega moest eens aan potentiële klanten de mogelijkheden laten zien van een workflowtool, die gebruikt kon worden om snel de werkprocessen van een organisatie mee te ondersteunen.
Die tool deed het prima, we werkten er al een tijdje mee.
En die collega was een van onze beste ontwikkelaars.
Toch zat hij in een hoek van de kamer te zuchten, te steunen en steeds donkerder te kijken, want het moment van de afspraak naderde en hij had te kampen met onverwachte technische problemen.
(Een demo en technische problemen; het zal ook eens niet.)
Toen wij ons al serieus begonnen af te vragen of het nog wel voor elkaar zou komen, werd het echter ineens stil in zijn hoekje en hoorden wij nog slechts koortsachtig getik.
Met rust laten, besloten wij, het gaat goed daar.
En ja hoor, niet veel later vroeg hij ons opgelucht of hij zijn presentatie op ons mocht uitproberen.
Na wat inleidende woorden kwam hij al snel bij het praktische gedeelte.
‘Om te beginnen moet ik hier een medewerker invoeren… laten we zeggen: Jan de Vries.’ En hij tikte in: Jan de Vries. Inderdaad, verscheen op het scherm. ‘En zijn adres, laten we zeggen: Kalverstraat 1.’ Typerdetyp, ook dat ging goed. En voor onze bewonderende ogen voltrok zich het gehele werkproces: hier en daar werd wat ingevoerd en aangeklikt, en dan ging alles feilloos van het ene in het andere bakje.
Dat had onze collega snel voor elkaar gekregen!
‘Hoe heb je je problemen nou eigenlijk opgelost?’ vroegen wij na afloop.
‘Nou eh… niet.’
‘Niet?!’
En toen kwam de aap uit de mouw: alles wat we hadden gezien, was nep. Niets werkte echt. De enige medewerker waarmee deze workflow het deed, was de genoemde Jan de Vries; het leek of onze collega die ter plekke stond te verzinnen, maar in feite had hij hem hard geprogrammeerd.
En wij hadden niets gemerkt!
Als wij, die onze collega zo hadden horen mopperen, er al met beide beentjes intrapten, dan zal het wel duidelijk zijn wat een verpletterende indruk de demo later die dag maakte op het echte publiek.
Het dak ging er haast af, zo mooi vonden ze het.
Ze wilden het hebben.
En dat niet alleen: het deed eigenlijk al precies wat ze nodig hadden, dus ze wilden het nu meteen.
(Had onze collega gelijk zijn volgende probleem.)
 
Het is werkelijk wonderbaarlijk hoe goed iets eruit kan zien, ook al hangt het aan de achterkant aan elkaar van duct tape, touwtjes en paperclips.
Dat neemt niet weg dat niemand die bij zijn volle verstand is, een eerste in elkaar geknutseld probeersel voor een revolutionair nieuwe motor in zijn auto zou laten monteren, vooral niet als hij nog jarenlang voor al zijn vervoer afhankelijk zal zijn van dat ding.
Net zo min als iemand erin zou toestemmen om een bordkartonnen toneeldecor te nemen als basis voor zijn nieuwe huis.
Zo zal dus ook een opdrachtgever die begrijpt wat er aan de hand is, nooit een rammelend bijproduct willen gebruiken voor een IT-oplossing waar hij nog heel lang mee vooruit moet. Wat niet vanaf het begin goed is opgezet, schaaf je later niet meer bij.
Aan ons de taak om duidelijk zijn over wat je van een PoC, een demo, en zo meer, kunt verwachten.
En vooral ook: wat niet.
 
Uiteraard is het in ons te prijzen dat wij de gebruikersorganisatie zo graag van dienst willen zijn dat wij, onder hun enthousiasme en druk, misschien toch wel eens heel eventjes overwegen om ons pokkending niet weg te gooien, maar uit te bouwen naar hun toekomstige productiesysteem.
Maar het zou een beginnersfout zijn.
 
Gelukkig maken wij die niet.
 
Tuurlijk niet.

021-Decor voorkant
Het mag heel wat lijken…

021-Decor zijkant
…maar is ongeschikt voor gebruik

In rook op

020-Thumbnail stoomtrein
Mooi hoor, om te werken in een vak waarin de ontwikkelingen snel gaan.
De laatste paar decennia tenminste.
Voor die tijd moest de boel nog een beetje op gang komen.
 
Na de rekenmachine van Blaise Pascal in 1642, die we voor het gemak beschouwen als de eerste, mechanische computer, bleef het relatief rustig tot losjesweg begin 20e eeuw.
In 1943 zou Thomas J. Watson, hoogste baas van IBM, nog gezegd hebben dat er wereldwijd een markt was voor zo’n vijf computers.
En tot in de jaren ’50 was er op informaticagebied zo weinig te beleven dat de eerste Nederlandse programmeur gewoon bij naam bekend is: Edsger Dijkstra.
Mainframes werden daarna meer gemeengoed, maar pas in de jaren ’80, met de opkomst van de Personal Computer, begonnen de zaken echt in een stroomversnelling te raken.
Toen moest internet nog losbarsten.
En inmiddels heeft vrijwel iedereen, van jong tot oud, een computertje op zak waarmee de hele wereld binnen handbereik ligt.
 
Van het stenen tijdperk tot de moderne tijd, in minder dan een mensenleven!
 
Maar laten we nou niet doen alsof deze ontwikkelingen alleen maar vreugde met zich meebrengen.
En blijdschap.
En geluk.
Want zo is het dus niet.
En dan heb ik het niet eens over die Watson, want toen die zijn veelgeciteerde uitspraak deed liep hij al tegen de 70. Die had dus nog rustig de tijd om een gezegende leeftijd te bereiken en te overlijden voordat hij door iedereen zou worden uitgelachen.
Niets aan de hand.
Nee, ik heb het over al die collega’s die een leuk verhaal willen vertellen van een tijdje geleden, uit laten we zeggen het stoomtijdperk van de ICT, en er dan ineens achter komen dat hun publiek – net iets jonger dan zijzelf – de noodzakelijke kennis mist voor het begrijpen van de pointe. De grappige afloop. De hilarische uitsmijter.
Daar staan ze dan.
Dachten ze een geestige bijdrage te leveren aan het gesprek, valt hun verhaal plat op de grond.
(Van een uitgebreide uitleg achteraf neemt het humoristisch gehalte meestal niet toe.)
 
De eerste keer dat ik zelf zo’n historisch verhaal niet begreep, was toen ik als beginnende ICT-er de afscheidsreceptie van een oudgediende bezocht.
Zoals bij dergelijke gelegenheden gebruikelijk, werden er om me heen heel wat herinneringen opgehaald.
‘Weet je dit nog…’ ‘Ken je die nog…’
‘En wat was het toch altijd fijn werken met collega…’
Terwijl de anderen dat nog stonden te beamen, barstte de spreker onverwacht in lachen uit. ‘Ineens bedenk ik me waarom je met hem zo lekker kon werken!’ en tussen de gierende uithalen door: ‘Omdat hij de grootste handen had van iedereen!’
Pas toen iedereen de tranen weer uit zijn ogen had gewreven, hoorde ik ook wat daar zo leuk aan was: de populaire collega kon met die enorme handen in één greep meer ponskaarten oppakken dan wie dan ook. Zodat, samen met hem, iedere klus razendsnel geklaard was.
Dus.
 
Behalve verhalen waarvoor je kennis moet hebben van vaardigheden die nu geen rol  meer spelen, zijn er ook verhalen waarvoor je je juist moet realiseren dat sommige vaardigheden vroeger niet algemeen voorhanden waren.
Zo waren een paar IT-collega’s al een tijdlang aan het werk voor een belangrijke opdrachtgever, die ook gebruiker van de beoogde nieuwe functionaliteit zou worden. Ze waren keurig volgens het boekje te werk gegaan: hadden zijn behoeften nauwkeurig in beeld gebracht, processen geanalyseerd, een mooie oplossing bedacht en gebouwd en voortdurend afgestemd met hun klant. En nu was dan eindelijk hun moment van glorie gekomen: het tonen van hun ingenieuze applicatie!
Op de werkkamer van de opdrachtgever aangekomen installeerden ze een en ander op zijn PC, die een beetje aan de zijkant van het bureau stond, en startten het programma op. Trots keken ze toe terwijl het eerste schermpje verscheen. ‘Tikt u hier maar even uw naam in!’
‘Eh…,’ zei de opdrachtgever, die aarzelend achter zijn PC had plaatsgenomen en nu zijn handen onzeker boven het toetsenbord liet zweven, ‘eh… eens kijken… waar zit de S…’
 
Maar de meeste vertelhindernissen worden ongetwijfeld opgeworpen door de in de loop der jaren vrij drastisch veranderde apparatuur.
Er zijn inmiddels hele volksstammen die nog nooit een 5¼ floppy disk van dichtbij hebben gezien (de bofferds) of het diskettestation waar zo’n ding in moest: een opening die je vaak met een schuifje kon sluiten en die vrij ruim bemeten was voor de flop waarvoor hij was bedoeld.
Die floppy’s hadden maar beperkte capaciteit en daarom paste een programma van enige omvang er niet altijd in zijn geheel op. In dat geval werd het op meerdere floppy’s gezet, die na elkaar moesten worden ingelezen. Dus eerst de eerste flop erin om dat deel van het installatieprogramma uit te voeren, vervolgens de tweede en zo verder.
Maar goed, die diskettestations hè, ik zei het al, die waren dus een beetje aan de ruime kant.
Zodat het kon gebeuren dat een helpdesk (ja, om service hoefde je toen nog niet te komen, maar helpen deden ze wel) werd gebeld over een programma dat geleverd werd op vier floppen. De beller, wanhopig: ‘Hoe krijg ik dit programma in ’s hemelsnaam geïnstalleerd? Het is me uiteindelijk gelukt om er drie floppen in te krijgen, maar die vierde er nog bij, dat gaat echt niet!’
 
Het mooie: wie voldoende voorkennis heeft voor het vorige verhaal, kun je ook met een gerust hart vertellen over de IT-ers die verbouwereerd terugkwamen van een eindgesprek op een ministerie.
Het was allemaal heel goed gegaan: de opdrachtgever had de functionaliteit nogmaals gedemonstreerd gekregen, ook zelf geprobeerd en hij was zeer tevreden.
Tot slot had men hem de floppy met de programmatuur overhandigd. ‘Die moet u heel goed bewaren.’
Uiteraard, dat was logisch.
En met de snelheid die men alleen verkrijgt door jarenlange oefening greep hij zijn perforator, sloeg twee gaatjes in het schijfje en klikte het in een ordner die met een zwierige zwaai terugging op de plank.
Zo.
Opgeborgen.
 
Oudere anekdotes en sterke verhalen als deze, vertel ze vooral nog snel een keer, want het publiek dat ze begrijpt wordt steeds kleiner.
En daarmee gaan ze dus uiteindelijk in rook op.
 
Nog een geluk dat het alle dagen lachen, gieren, brullen is in de IT.
 
Er komen wel weer nieuwe.
 
020-Stoomtrein