Killing 360 Reviews: hoe we stopten met het beoordelen van mensen en begonnen met het beheren van werk

Hallo! Mijn naam is Vitalina en ik ben accountmanager bij SToFU Systems.

Wij zijn het soort bedrijf waar processen in beweging komen en pas later namen, regels en toezicht van volwassenen krijgen. In het begin hadden we geen eigen managementschool, dus kopieerden we wat ‘iedereen kopieert’. Een van die geleende managementgewoonten was 360-feedback.

Op papier ziet de 360 ​​eruit als iets eerlijks en volwassens. Veel bronnen. Minder vooringenomenheid. "Objectiviteit". Mmmm!

In de praktijk werd het iets anders. Voor ons was 360 geen tool die het team versterkte. Het was een hulpmiddel dat het team stilletjes uit elkaar trok. Formeel leek het correct, maar in het echte werk ging het de verkeerde kant op. Dus hebben we het eruit geknipt. Laten we stap voor stap gaan.

Wat is 360?

360 is wanneer je feedback over een persoon verzamelt "van alle kanten": van de manager, collega's, aangrenzende teamgenoten en soms klanten. Gebruikelijk het is een vragenlijst met beoordelingen en vragen als ‘wat gaat goed’, ‘wat zit in de weg’, ‘wat moet er veranderen’.

Dat hebben wij ook gedaan. We stuurden een vragenlijst uit, verzamelden de antwoorden, verzamelden ze en schreven aanbevelingen. Formeel zag alles er netjes uit. Er waren datapunten. Er waren conclusies. Er was een "ontwikkelingsplan".

Om duidelijk te maken over wat voor soort ‘vragenlijst’ we het hebben, zal ik een heel vereenvoudigd voorbeeld geven van wat er doorgaans in 360 wordt gevraagd. Dit is geen woord-voor-woord citaat uit ons formulier, maar typische logica.

Bijvoorbeeld: "Wat moet iemand blijven doen?". Vervolgens: "Wat moet een mens gaan doen?". Vervolgens: "Waar moet een mens mee ophouden?". En nog een vraag die altijd onschuldig lijkt: "Beschrijf een situatie waarin de interactie moeilijk was en waarom."

En de samenvatting ziet er vaak uit als een klein verslagje van een collectief alziend oog. Ongeveer zo:

Sterke punten: pakt taken snel op, helpt anderen, verdwijnt niet van de radar. Risico's: 'klaar' betekent soms 'bijna klaar', de discussie tijdens vergaderingen kan scherp zijn, in de chat antwoordt hij fragmentarisch. Wat nu te doen: overeenstemming bereiken over de Definition of Done, verwachtingen synchroniseren, overeenstemming bereiken over het escalatieformat.

Op papier is alles prima. Prachtig, zelfs. Maar er is één detail. Het is geschreven door mensen die elke dag samenwerken. En zodra je anonimiteit toevoegt, of uitstelt feedback "voor later", het is niet langer een ontwikkelingstool en begint een eigen leven te leiden. Stel je een projectteam voor van vijf personen. Dan zegt iemand: "Hier is anonieme feedback." Anoniem. In een team van vijf. En in deze realiteit begint 360 zijn ware gezicht te laten zien.

Waarom 360 een hulpmiddel werd om het team uit elkaar te trekken

1. Punt één. Lof - één regel, kritiek - een roman in drie delen

Als het goed gaat, schrijven mensen kort. "Alles is oké." "Comfortabel werk." "Goed gedaan". Dit is feedback op het niveau van een sticker op een schoolschrift. Wanneer er is iets mis, de literatuur begint. Met details, met voorbeelden, met emoties. En technisch gezien is dit normaal: negatief is gemakkelijker te specificeren dan positief. Maar in 360 is dat wel zo het probleem: deze hele ‘roman’ komt dan in veralgemeniseerde vorm terug op één persoon oordeel van het team.

Zelfs als je het zo zacht mogelijk formuleert, het menselijk brein leest het als volgt: "We kwamen allemaal bij elkaar en schreven het op wat is er mis met je." En dat is het. Daarna, elke poging daartoe ‘constructieve feedback’ voelt als een hoorzitting in de rechtbank. Je wilde een ontwikkelingsinstrument, en kreeg een collectief tribunaal.

We hebben ons eerlijk afgevraagd: wat proberen we er eigenlijk mee te doen? deze praktijk? Het disciplineert het formaat, ja, maar het vernietigt het vertrouwen.

Vanuit het leven ziet het er zo uit. Er komt een melding bij een persoon, waar er drie zijn zinnen "alles is oké", en twee doeken "daarom is het niet oké". En de hersenen onthouden natuurlijk niet drie "oks", maar twee "niet oké". Want zo is aandacht geregeld: het doet pijn, dus het is belangrijk! En vanaf dat moment, de persoon beweegt zich niet in de richting van ontwikkeling, maar in de richting van zelfverdediging. Zij begin te bewijzen dat "het niet waar is", of dat "het de context was", of dat "jullie ook geen heiligen zijn". En op dit moment verandert 360 in een ritueel waarbij iedereen alsof ze goed wilden, maar het bleek zoals gewoonlijk.

2. Punt twee. Anonimiteit in een klein team is zelfbedrog

Er is een bekend managementsprookje: “Anonieme feedback neemt angst weg.” Anonimiteit? Echt? In kleine projectteams? In werkelijkheid betekent het bijna altijd: "Ik ga raden wie dit heeft geschreven!".

Een persoon ontvangt verschillende onaangename opmerkingen, en dan komt naar de volgende projectvergadering waar diezelfde 3-5 mensen zitten. Ze denken niet aan ‘organisatieontwikkeling’. Ze denken: "Welke één van jullie was het?" En dat zet een heel giftig proces op gang: iedereen blijft uiterlijk beleefd, maar daaronder schuilt een laag wantrouwen.

Het ontaardt niet altijd in een openlijk conflict. Het is eenvoudig maakt het team kouder. Minder samenhangend. Minder bereid om te helpen. En dan vragen we ons af waarom mensen hun problemen niet delen "in de beginfase". Maar omdat ze al een keer zijn gedeeld – en het kwam anoniem naar hen terug een lijst met beweringen.

3. Zodra 360 promotiebeslissingen beïnvloedt, beginnen de spellen

Hier was het meest interessante. En het meest trieste.

Tijdens een van onze coördinatiegesprekken merkten we dat iets vreemds. Iemand kan beleefd, ondersteunend en prettig in de omgang zijn tijdens telefoongesprekken. Binnen het team kunnen ze eruit zien als een echte lieverd. En dan je overhandigt ze een ‘anonieme’ vragenlijst waarin ze ‘anderen kunnen beoordelen’, en plotseling daalt de score of wordt de kritiek overdreven. Dat effect hebben we zelf gezien. Het werkte regelrecht in tegen de integriteit.

Stel je de situatie voor. Je zegt tegen het team: '360 beoordelingen tellen mee promotie." En in dezelfde seconde maak je deel uit van de team in spelers, niet in collega's. Want als de knop "invloed" verschijnt in het systeem, iemand zal erop drukken. Niet altijd van het kwade. Soms gewoon op gevoel onrecht ("en waarom krijgt hij promotie, hij is..."). Soms uit concurrentie. Soms omdat ‘zo de wereld werkt’. En op dat moment krijg je wat je wilde vermijd: politiek, gamen, “voor het geval dat lagere” cijfers.

Dit is trouwens een van de redenen waarom veel onderzoekers en praktijkmensen wordt geadviseerd om feedback te delen voor ontwikkeling en administratieve beslissingen (geld, cijfers, promo). De CIPD zegt het heel bot: praat erover het is beter om evaluaties/bestuurlijke beslissingen te scheiden van gesprekken, waar feedback wordt gegeven met het oog op ontwikkeling. Hier is een pdf van hun bewijsbeoordeling (praktijksamenvatting): www.cipd.org/...​e-review_tcm18-111378.pdf

4. Punt vier (ons pijnlijke inzicht). 360 vervangt vaak het werk van de manager

Na verschillende cycli eindigden we met een zin die eerst als een belediging klonk en daarna als de waarheid klonk.

Als een manager een 360 nodig heeft om het te begrijpen hoe mensen werken en waar de problemen zitten, die manager beschikt niet over een systeem van waarneembare signalen. Er zijn geen statistieken. Er zijn geen reguliere gesprekken. Er is geen ritme. Of dat bestaat allemaal ‘ergens’, maar wordt niet daadwerkelijk gebruikt.

En 360 wordt een kruk: “we gaan nu de vragenlijst verzamelen en tot slot we zullen de waarheid leren." En dan begrijp je de "waarheid" niet en een emotioneel beeld, vermenigvuldigd met anonimiteit en giswerk en politieke spelletjes.

Dit klinkt dus niet als "het ging slecht voor ons, daarom is 360 slecht", ik zal een verwijzing toevoegen.

Er bestaat een onderzoek naar feedback uit meerdere bronnen. De conclusie is eigenlijk: "verwacht geen magie". In een meta-analyse van 24 longitudinale onderzoeken schrijven Smither, London en Riley die verbetering daarna 360-feedback is doorgaans bescheiden, en dat mag je niet groot verwachten "massale upgrade" na één golf van feedback. De kans op verbetering groeit wanneer iemand een reële noodzaak tot verandering ziet, accepteert de feedback, gelooft dat ze kunnen veranderen, stelt concrete doelen, en doet daadwerkelijk iets, in plaats van alleen maar "een pdf te lezen". en verder gaan." Hier is de tekst zelf (PDF): www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

Oké, we hebben 360 verwijderd. Wat is er voor in de plaats gekomen?

We zijn gestopt met het meten van mensen op basis van het aantal kaartjes

Op één kaartje past een week onderzoek, een moeilijke beslissing, tien oproepen en slechts 20 regels code. In een andere — 50 functies die daadwerkelijk uit één run van de AI-agent kwamen binnen 20 minuten.

Als je alleen kaartjes meet, ben je ook daadwerkelijk aan het meten niet het werk, maar hoe uw proces het werk vermindert in stukken

Daarom hebben we de vraag veranderd. Niet "hoeveel taken heb ik afgesloten?" Maar: Wat is er opgeleverd, welke waarde heeft het gecreëerd, wat was de kwaliteit, was het voorspelbaar en waren de statussen eerlijk?

Hoe we ‘resultaat’ definieerden zonder managementtheater

We zijn tot een eenvoudig raamwerk gekomen.

Er is sprake van resultaat als er waarde wordt geleverd, de kwaliteit acceptabel is, het team voorspelbaar is en de voortgang transparant is.

Waarde is niet "de code is geschreven". Het is 'de gebruiker of klant kreeg een beter resultaat' of 'het werd gemakkelijker voor het team om het systeem te ondersteunen".

Kwaliteit is niet "Ik vind je code leuk". Dit zijn gevolgen: bugs in het product, incidenten, revisies.

Voorspelbaarheid betekent niet dat we het altijd redden. Het is: "we begrijpen eerlijk waar we tijd voor hebben en wat niet, en we liegen er niet over tegen onszelf."

Transparantie is wanneer ‘bijna klaar’ geen levensfilosofie wordt.

Statistieken

Wanneer mensen het woord ‘statistieken’ horen, zullen velen dat meteen doen denk aan de licht getraumatiseerde werknemer uit eerdere ervaringen: degene die met cijfers op zijn hoofd werd geslagen.

Statistieken mogen geen zweep zijn. Het zouden glazen moeten zijn. Zonder hen is een manager vaak blind. En als de manager blind is, gaat hij in vragenlijsten op zoek naar ‘objectiviteit’. Nou, je snapt het.

We hebben de statistieken op teamniveau gelaten, omdat de meeste problemen systemisch zijn! En als we niet willen zoeken naar de schuldigen, maar het proces willen corrigeren, dan moeten we het proces meten!

We hebben hier eerlijk gezegd niets uitgevonden. DORA (DevOps Onderzoek en Evaluatie) bevordert al een zeer praktische reeks leveringsstatistieken: hoe snel u verandering doorvoert en hoe pijnlijk mislukkingen zijn als veranderingen misgaan. Hier is hun korte handleiding: dora.dev/guides/dora-metrics.

Er is ook een belangrijke opmerking die ik graag wil benadrukken aan de muur voor iedereen die ooit KPI-statistieken wilde maken: "Maak van de metriek niet het doel"! Want zodra je zegt "we moeten N keer per dag inzetten", onderdeel van de team begint geen waarde in te zetten, maar een getal. Dit is de oude verhaal dat zodra een maatstaf het doel wordt, deze ophoudt dat te zijn een indicator. DORA verwijst expliciet naar de wet van Goodhart en beschrijft typische valkuilen. Hier is de pagina over de "vier/vijf sleutels" in eenvoudige woorden: dora.dev/...​s/dora-metrics-four-keys

En nog een belangrijk ding dat DORA normaal gesproken benadrukt: context is belangrijk. Deze statistieken kunnen het beste binnen één worden bekeken team of dienst en in de loop van de tijd, niet door te vergelijken een mobiele applicatie met een mainframe, of een klein team met een platform voor 200 personen.

Als je geen technisch team bent, is de logica hetzelfde. In plaats van "implementeren" u heeft mogelijk "klant heeft het resultaat geaccepteerd"; in plaats van "incident" er kan sprake zijn van "escalatie"; in plaats van "terugdraaien", "herwerken". na uitlijning". Het punt is nog steeds hetzelfde: hoe snel we waarde verplaatsen door het systeem en hoeveel de fout ons kost.

En nu - het zeer belangrijke "doe dat niet". Zet deze statistieken niet om in individuele KPI's! Want dan gaan mensen niet het product, maar het aantal optimaliseren. KPI op "implementeert", en plotseling heb je implementaties omwille van de implementaties. KPI op "cyclustijd", en taken worden tot absurditeit opgesplitst om ze "snel af te sluiten", terwijl harde delen stilletjes in de schaduw verdwijnen. KPI op "incidenten", en incidenten worden hernoemd naar "eigenaardigheden" of "onverwachte gebruikersscenario's".

Het eerste wat ons hielp was voorspelbaarheid. Eenvoudig vraag: wat hebben we beloofd in de planning en wat er daadwerkelijk werd gegeven. Niet uit schaamte. Voor begrip. Want als je voortdurend 10 belooft en er 6 doet, dan is het probleem niet "luie mensen". Het probleem zit in de schatting, prioriteiten, WIP, blokkers, contextwisseling. Met andere woorden: in het bestuur.

De tweede is de levertijd. Hoeveel tijd kost de taak? op weg van ‘naar het werk gebracht’ naar ‘daadwerkelijk afgeleverd’. Het is heel ontnuchterend. Want dat blijkt vaak dat we snel ‘code schrijven’, maar ‘leveren’ langzaam. En dan zie je waar het knelpunt zit: reviewen, testen, vrijlating, verzoening, afhankelijkheden.

De derde is WIP. Als het team tegelijkertijd ‘aan het werk’ is tien problemen tegelijk, dan doet niemand echt iets. Meer precies, iedereen doet alles tegelijk. En dan vragen we ons af waarom vooruitgang voelt langzaam en nerveus. Wanneer de hersenen in een dunne laag zijn verspreid bij tien taken wordt het niet productiever. Het wordt gewoon meer moe.

Iets anders dat ons hielp helderder na te denken was dit: als je wilt dat werk sneller door het systeem beweegt, is het antwoord vaak niet om mensen harder op te dringen. Het is bedoeld om de batchgrootte te verkleinen. Kleinere wijzigingen zijn gemakkelijker te beoordelen, testen, vrijgeven en terugdraaien. DORA maakt rechtstreeks hetzelfde punt: kleinere batches verbeteren meestal zowel de snelheid als de stabiliteit. Het klinkt voor de hand liggend totdat een team er daadwerkelijk een maand lang naar probeert te leven.

Kwaliteit: we zijn gestopt met ruzie maken ‘zo lijkt het mij’ en zijn gaan kijken naar de gevolgen

Het beoordelen van de "kwaliteit" met vragenlijsten is een slecht idee. Omdat "kwaliteit" in de vragenlijst gaat het vaak over sympathie, stijl en smaak.

We gingen verder met de gevolgen.

Hoeveel defecten bereikten de productie. Hoe serieus waren ze? Hoe verandert de trend?

Hoeveel incidenten hebben we gehad. Hoe lang duurde het voordat we herstelden? Worden dezelfde redenen herhaald?

Hoeveel revisies. Hoeveel taken zijn "geslaagd" en vervolgens geretourneerd. Want ‘klaar’ bleek nog niet klaar te zijn.

Je maakt geen ruzie meer over ‘wie de beste is’. Je ziet wat er werkelijk met het product gebeurt.

Een contra-intuïtieve conclusie: waarom überhaupt een persoon evalueren?

Hoe langer we groeven, hoe vaker we een vreemde vraag tegenkwamen.

Waarom beoordelen we een persoon? Een promotie weigeren? Om te laten zien wie de "ster" is? Om mensen te vergelijken?

En toen we er eerlijk over spraken, bleek het ook dat de meeste van onze werkelijke behoeften niet te maken hadden met rangorde mensen. Ze gingen over teamprestaties: doen we wat wat we beloofd hebben, is de kwaliteit goed, is het werk voorspelbaar, branden we op, en krijgt de cliënt wat? zij verwachten?

Dat wil zeggen, over het systeem.

En als dat zo is, dan is het eerste object van evaluatie het team en het proces. En niet een persoon als doelwit.

Het team presteert ondermaats, dus we bekijken het geheel keten: werving, onboarding, taakdefinitie, planning, beoordeling, testen, release, communicatie, afhankelijkheden. Dit is bestuurlijk moeilijker, ja. Maar het is eerlijker.

Het ziet er soms heel down-to-earth uit. Wanneer bijvoorbeeld "we hadden weer geen tijd", de eerste vraag is niet "wie gaat langzamer", en "waar is de tijd verdwenen". Omdat de tijd kan verdwijnen niet in "werk", maar in wachten: taken liggen in beoordeling, in testfase, geblokkeerd door overeenkomst, of er zijn er simpelweg te veel naast elkaar.

Als iemand het moeilijk heeft, wat we eerst controleren

Ook zien we wel eens situaties waarin iemand ‘niet trekt’. Maar in plaats van een vragenlijst doen we een eenvoudige diagnose.

Is dit probleem er altijd al geweest? Als dat zo is, is het probleem waarschijnlijk bij aanwerving of onboarding. In dat geval regelt u het aanwervingsproces, niet de persoon met vragenlijsten.

Was het eerst normaal en daarna werd het erg? Dan het kan de context zijn: burn-out, verandering van taken, rolconflict, persoonlijke omstandigheden. Dit is de zone van normaal managementwerk: ontdek wat er is gebeurd, verminder de last, help de persoon terug te krijgen controle en stel een kort herstelplan van 2 tot 4 weken op.

Heeft de persoon een duidelijk begrip van wat succes is? ziet er in de nabije toekomst uit? Want vaak is het probleem dat niet dat de persoon "zwak" is. Het is dat we ze in de mist hebben geplaatst en noemde het verwachtingen.

En nog een nuance die we ook hadden. Als een persoon meerdere keren mislukt, kan de manager soms subjectief verhogen bar: "Bewijs nu dat je geen mislukkeling bent." Dat werkt vaak op onbewust niveau, en het werkt slecht voor het team. Het is meestal beter om het tegenovergestelde te doen: de reikwijdte verkleinen, de taken kleiner maken, verwijder de ruis, geef iemand de kans om consequent een paar dingen goed te doen en het zelfvertrouwen terugkrijgen. Dit is een moeilijke taak voor beheerders. En dat is precies waarom wij heel goed kijken bij de managers die we inhuren.

Conclusies

Natuurlijk kan de 360 ​​werken. In grote bedrijven, waar anonimiteit echt mogelijk is.

Wanneer het team al een cultuur van directe feedback kent, en 360 is een extra signaal, niet het hoofdsignaal "waarheid".

Dat hadden wij niet. We hadden kleine teams, een snel tempo en veel wantrouwen.

De 360 ​​zag er op papier uit als een volwassen hulpmiddel. In onze werkelijkheid is het een mechanisme geworden dat angst op één plek verzamelt, giswerk, concurrentie en "collectief oordeel".

We hebben 360 verwijderd en zijn teruggegaan naar de basis: eenvoudige teamstatistieken, open gesprekken en transparante statussen.

Materialen en links (als je dieper wilt graven)

DORA — software delivery performance metrics. Een gegronde uitleg van de vijf statistieken en de valkuilen waar teams in trappen als ze deze misbruiken.

DORA — DORA’s software delivery performance metrics. Korte versie met historisch "waarom vier/vijf" en een waarschuwing over games met statistieken.

DORA Research: 2024 — DORA Report. Volledig rapport (download PDF in verschillende talen).

Smither, London (2005) — meta-analysis on multisource feedback. Waarom je van één 360-golf geen magisch effect moet verwachten.

CIPD — Performance feedback: an evidence review (PDF). Over hoe feedback wel/niet werkt en waarom het verwarren van ‘beoordeling’ met ‘ontwikkeling’ vaak schadelijk is.

CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Als je toch een 360 doet, is er voor de start iets om over na te denken, niet na de brand.

CCL — SBI feedback model. Een heel eenvoudig raamwerk voor feedback zonder snelkoppelingen.

Google SRE — Postmortem Culture: Learning from Failure. Over onberispelijke autopsie en waarom het beschamen van cultuur het leren doodt.

Amy Edmondson (1999) — Psychological Safety (PDF). Primaire bron over psychologische veiligheid in teams.

WEF — Feedforward technique. Over hoe je feedback kunt verschuiven in de richting van ‘wat we nu gaan doen’ en niet ‘wat er gisteren is gebeurd’.

Goodhart’s law. Een van de nuttigste ‘anti-theorieën’ voor iedereen die KPI-statistieken wil maken.

Vragen voor de Gemeenschap

What does the community think about 360? Gebruik je het? Hoe was jouw ervaring?

Hoe los je het probleem van ‘anonimiteit’ op als het team klein is en iedereen alles begrijpt?

En welke leverings-/kwaliteitsstatistieken helpen u daadwerkelijk het proces te beheren in plaats van mooie rapporten op te stellen?

Bedankt voor uw tijd en aandacht.