1 probleem, 2 handelswijzen

Vandaag de dag heb je in een gemiddeld bedrijf 2 soorten mensen: de problem solvers, en de problem managers.

De problem solvers zijn het makkelijkst om te verklaren: iemand heeft een probleem, schakelt een problem solver in en het probleem geraakt opgelost. Typische voorbeelden van problem solvers: loodgieter, elektricien, mechanieker, netwerk engineer.

De problem managers zijn moeilijker te beschrijven. Het zijn die mensen die eigenlijk te weinig weten of kunnen om een probleem op te kunnen lossen, maar door anderen wel worden aangesproken om het probleem van de baan te helpen.

Binnen de IT gaat het meestal zo:

• Tester A vindt een probleem. Maakt een defect (bug) aan. (Of stuurt een mail, belt, … whatever.)
• Het probleem belant meestal op de schoot van zijn manager, manager A. Een typische problem manager. Heeft een heel team onder zich, en is alleen globaal op de hoogte van de gebruikte systemen en architectuur.
• Manager A weet niet echt waar het probleem aan gelegen is, en stuurt het door naar de manager van het ontwikkelteam, manager B.
• Die op zijn beurt is ook een problem manager, maar destructief: hoe minder problemen zijn team moet oplossen, hoe makkelijker hij zijn targets haalt. Vandaar zijn initiële reactie: de bug negeren en/of terugsturen naar tester A, of diens manager.
• Op de dagelijkse defect meeting haalt tester A zijn gram: hij vertelt aan de business user over het gevonden defect, wat die laatste onmiddelijk beschouwt als een showstopper. Met zo’n probleem kunnen we niet in productie gaan. het defect wordt teruggestuurd naar manager B.
• Deze stuurt het probleem door naar een beschikbare ontwikkelaar, die al snel inziet dat het probleem niet aan zijn code ligt, maar aan iets in de hardware. De ontwikkelaar stuurt een weinigzeggende mail naar de hele zooi: tester, beide managers en de business user, waarin hij de schuld steekt op de hardware.

Op dit moment hebben we 5 mensen in de rol van problem manager, maar niemand die optreed als problem solver. Waarom niet? Omdat problem solvers zich traditioneel laag in de hiërarchie bevinden. Ze zijn geweldig in hun taak, specialiseren zich gedurende vele jaren, maar blijven steeds op dezelfde post. De managers boven hen veranderen om de haverklap van functie en kennen de bewuste problem solvers helemaal niet.

Op zo’n moment heb je een ouwe rot nodig die weet wie je moet contacteren. En weet je wat? Die worden steeds zeldzamer.

Idealiter beschikt elke organisatie over een verhouding van 1 problem manager over 8 problem solvers. Maar omdat iedereen tegenwoordig een bedrijfswagen wilt en half de Vlaamse beroepsbevolking hoger onderwijs genoten heeft, trekt die verhouding alsmaar meer scheef.

Problem managers roepen tegen elkaar om een oplossing te zoeken, maar etaleren te weinig kennis ter zake. Het is niet (steeds) dat ze niet bereid zijn de handen uit de mouwen te steken, ze weten alleen niet hoe.

Wat kan je doen als je zelf in de rol van problem manager zit? Heel snel de problem solvers vinden. Niet door meetings, niet door te communiceren via telefoon en mail. Door rond te lopen. Door te praten met mensen. Door eens na te gaan in je bugtracking systeem wie er nu eigenlijk die bugs effectief heeft opgelost.

En laat ons hopen dat de verhouding niet verder scheeftrekt…