Het blijkt dat het OP ‘gevangen in het midden’ zit: een ‘ondergeschikte’ heeft bij corporate officers geklaagd dat een teamleider/projectmanager hem in de steek laat. Dit lijkt om verschillende redenen op een softwareteam. Hoewel dit niet strikt relevant is, is het misschien wel een probleem dat van iemand in een ‘engineering’-rol wordt verwacht dat hij zijn tijd beheert zoals een winkelbediende - om 8.00 uur ‘s ochtends en om 17.00 uur ’s middags ’s middags ’s middags’. Het klinkt alsof er ook andere zaken zijn, maar die zijn niet gespecificeerd.
De vraag, zoals gepost, is ‘Wat moet ik het senior management vertellen?’. Dit suggereert dat de OP’s eerste zorg is hoe hij door zijn eigen managers wordt waargenomen. Vanuit het perspectief van de senior manager zijn twee ego’s in een kattenstrijd verwikkeld - de ene schrijft code en de andere beheert een project. Dit impliceert een zekere sociale afstand tussen de ‘ontwikkelaar’ en de ‘toezichthouder’. De supervisor lijkt te proberen de ondergeschikte te vertellen: ‘je bent ingehuurd om te doen wat je gezegd wordt - stel de autoriteit niet in vraag’. Hoewel de eigenlijke locatie niet uit de inhoud blijkt, klinkt dit als een winkel ergens in Azië.
Wat het senior management wil horen is dat de twee strijdende partijen hebben uitgewerkt hoe ze hun werk kunnen doen met een minimum aan wrijving. Zal hij alle negatieve punten van zijn overste meenemen of wat?‘ zou een slechte zet zijn - echt slecht. Het enige wat de senioren op dit moment zien is dat twee werknemers ruzie maken in plaats van dat ze hun werk gedaan krijgen.
Dus, op het gevaar af 'de vraag niet te beantwoorden’, stel ik voor dat:
- Het OP zoekt uit welke metrieken van toepassing zijn op het meten van de prestaties van de ontwikkelaar. Het is niet waarschijnlijk dat dit inklokt en uitklokt. Het is waarschijnlijk de productie van deliverables - code, documentatie, fixes, en gebruikersondersteuning in een redelijke hoeveelheid tijd. Dit kan net zo goed van toepassing zijn op andere vormen van engineering - chipontwerp, architectuurproject of brug. Deze hebben allemaal complexe mengsels van ‘core design’, documentatie, herzieningen en reacties op de feedback van de consument.
- Als je de metrieken hebt uitgezocht, pas ze dan toe op de ontwikkelaar/engineer. 3. Schrijft hij code, lost hij problemen op en ondersteunt hij gebruikers naar tevredenheid? Zo ja, stop dan met hem te provoceren met dingen die hem duidelijk storen. Kijk of het mogelijk is om tijdsproblemen te identificeren die niet zichtbaar zijn tijdens de werkuren, zoals nachtelijke telefoontjes, werk in het weekend of andere activiteiten die de normale 40 uur per week verstoren.
- Er is enige waarde in de introspectie. Is de OP bezig met een machtsspel, alleen maar om de ‘rang’ vast te stellen of te behouden? Mensen in technische functies krijgen de hele tijd ruzie met ‘lijnmanagers’ over kleding, pauzes, taal, werktijden en gebruikers- of klantcontactprotocollen. De engineers zien het gedrag van managers als hinderlijk - meer bezig met de schijn en de randvoorwaarden dan met het voor elkaar krijgen van dingen. Het OP zou deze gelegenheid kunnen aangrijpen om uit te zoeken of gewoontes die in een ander soort organisatie (of familiestructuur) zijn aangeleerd, hier contraproductief zijn.
Na die dingen te hebben gedaan, is het tijd om bij de ontwikkelaar te gaan zitten - idealiter buiten het kantoor - bijvoorbeeld tijdens de lunch. Stimuleer en laat de ontwikkelaar praten over de manier waarop de tijd wordt besteed, dag in dag uit - de brokken die beschikbaar zijn voor het coderen/ontwerpen, de onderbrekingen van supervisors, onderbrekingen van gebruikers, problemen die hem bezig houden tijdens niet-werkuren, speculatieveranderingen ‘out of the blue’, etc. Wees niet verbaasd als het gesprek uitwijkt - als dat zo is, duwt u het terug - voorzichtig.
Probeer uit te zoeken welke bepaalde gebeurtenissen iemand zouden triggeren om te laat te komen of om een lange pauze te nemen - onder de dingen die de eerste triggeren (uit mijn persoonlijke ervaring) is het hebben van slechts een vaag begrip van wat er nu te doen is. Ik zat thuis vaak twee of drie uur in mijn relaxfauteuil en dacht na over hoe ik iets moest structureren, en toen het antwoord arriveerde, ging ik naar mijn werk en deed het. Ik heb genoeg supervisors gehad die klaagden over mijn aankomsttijd - geen enkele over de kwaliteit van wat ik deed.
Als de ingenieur veel wordt onderbroken, is het de taak van de OP’s om uit te zoeken hoe ze die moeten onderscheppen, zodat er minder van hen zijn. Dit betekent in het bijzonder dat er niet willekeurig meer wordt onderschept. Waar komen de onderbrekingen vandaan en kunnen ze worden verminderd? Dit is vaak wat supervisors moeten doen - de decks vrijhouden zodat de programmeurs / ontwerpers / engineers zich kunnen richten op het eruit halen van hun spullen.
Als de ontwikkelaar niet echt in staat is om uit te leggen waar zijn tijd naartoe gaat, dan kan er een competentieprobleem zijn. Nogmaals, dit is gericht op de uitvoer, niet op de tijdklok. Worden deadlines gemist omdat er niets gedaan wordt of omdat iemand anders steeds van gedachten verandert? Als de programmeur steeds opnieuw moet beginnen, dan wordt er niets gedaan. Zo ja, waarom gebeurt dit dan? Van de supervisors wordt verwacht dat ze de eisen vastleggen, zodat het team naar een vast doel kan werken.
Als al die dingen zouden gebeuren, zou de supervisor zou aan het senior management kunnen rapporteren dat de productiviteit verbetert en dat gebruikers de computerinfrastructuur krijgen die ze nodig hebben.