Killing 360 reviews: Hvordan vi sluttet å rangere folk og begynte å administrere arbeidet

Hallo! Jeg heter Vitalina, og jeg er kontoadministrator hos SToFU Systems.

Vi er den typen selskap der prosesser blir født i bevegelse og først senere får navn, regler og voksenoppsyn. I starten hadde vi ikke egen lederskole, så vi kopierte det «alle kopierer». En av de lånte ledelsesvanene var 360-tilbakemeldinger.

På papiret ser 360 ut som noe rettferdig og modent. Mange kilder. Mindre partiskhet. "Objektivitet". Mmmm!

I praksis ble det noe annet. For oss var ikke 360 ​​et verktøy som styrket laget. Det var et verktøy som rolig trakk teamet fra hverandre. Formelt sett så det riktig ut, men i virkelig arbeid presset det i feil retning. Så vi kuttet det ut. La oss gå steg for steg.

Hva er 360?

360 er når du samler inn tilbakemeldinger om en person "fra alle sider": fra lederen, kolleger, tilstøtende lagkamerater og noen ganger klienter. Vanligvis det er et spørreskjema med vurderinger og spørsmål som "hva går bra", "hva kommer i veien", "hva bør endres".

Det gjorde vi også. Vi sendte ut et spørreskjema, samlet inn svar, aggregerte dem og skrev anbefalinger. Formelt sett så alt ryddig ut. Det var datapunkter. Det var konklusjoner. Det var en «utviklingsplan».

For å gjøre det klart hva slags «spørreskjema» vi snakker om, vil jeg gi et veldig forenklet eksempel på hva som vanligvis stilles i 360. Dette er ikke et ord-for-ord-sitat fra skjemaet vårt, men typisk logikk.

For eksempel: "Hva skal en person fortsette å gjøre?". Så: "Hva skal en person begynne å gjøre?". Så: "Hva skal en person slutte med?". Og et annet spørsmål som alltid virker uskyldig: «Beskriv en situasjon da samhandlingen var vanskelig og hvorfor».

Og sammendraget ser ofte ut som en liten rapport fra et kollektivt altseende øye. Omtrent slik:

Styrker: tar opp oppgaver raskt, hjelper andre, forsvinner ikke fra radaren. Risikoer: «klar» betyr noen ganger «nesten klar», diskusjonen på møter kan være skarp, i chatten svarer han i fragmenter. Hva du skal gjøre videre: bli enige om definisjonen av ferdig, synkroniser forventningene, bli enige om eskaleringsformatet.

På papiret er alt bra. Vakkert, til og med. Men det er én detalj. Den er skrevet av mennesker som jobber sammen hver dag. Og når du legger til anonymitet, eller forsinket tilbakemelding "til senere", det slutter å være et utviklingsverktøy og begynner å leve et eget liv. Se for deg et prosjektteam av fem personer. Så sier noen: «Her er anonym tilbakemelding». Anonym. I et lag på fem. Og i denne virkeligheten begynner 360 å vise sitt sanne ansikt.

Hvorfor 360 ble et verktøy for å trekke teamet fra hverandre

1. Punkt én. Ros – én linje, kritikk – en trebindsroman

Når ting er bra, skriver folk kort. "Alt er ok." "Komfortabelt arbeid." "Godt gjort". Dette er tilbakemelding på nivå med et klistremerke på en skolenotisbok. Når noe er galt, begynner litteraturen. Med detaljer, med eksempler, med følelser. Og teknisk sett er dette normalt: negativ er lettere å spesifisere enn positiv. Men i 360 er det problemet: hele denne "romanen" kommer så tilbake til én person som en generalisert dom fra laget.

Selv om du formulerer det så forsiktig som mulig, den menneskelige hjernen lyder det slik: «Vi kom alle sammen og skrev ned hva er galt med deg." Og det er det. Etter det, ethvert forsøk på «konstruktiv tilbakemelding» føles som en høring i retten. Du ville et utviklingsverktøy, og fikk en kollektiv nemnd.

Vi spurte oss selv ærlig: hva prøver vi egentlig å gjøre med denne praksisen? Det disiplinerer formatet, ja, men det ødelegger tilliten.

Fra livet ser det slik ut. En rapport kommer til en person, hvor det er tre setninger "alt er ok", og to lerreter "det er derfor det ikke er ok". Og hjernen husker selvfølgelig ikke tre "ok", men to "ikke ok". For det er slik oppmerksomhet er ordnet: det gjør vondt, så det er viktig! Og fra det tidspunktet, personen beveger seg ikke mot utvikling, men mot selvforsvar. De begynne å bevise at "det ikke er sant", eller at «det var konteksten», eller at «dere er heller ikke helgener». Og i dette øyeblikket blir 360 til et ritual der alle som om de ville godt, men det ble som vanlig.

2. Punkt to. Anonymitet i et lite team er selvbedrag

Det er et kjent ledelseseventyr: "Anonym tilbakemelding fjerner frykt." Anonymitet? Virkelig? I små prosjektteam? I virkeligheten betyr det nesten alltid «jeg skal gjette hvem som har skrevet dette!».

En person får flere ubehagelige bemerkninger, og deretter kommer til neste prosjektmøte hvor de samme 3-5 personene sitter. De tenker ikke på «organisasjonsutvikling». De tenker: "Hvilken en av dere var det?" Og det starter en veldig giftig prosess: alle sammen forblir ytre høflig, men under er det et skjult lag av mistillit.

Det er ikke alltid det eksploderer i åpen konflikt. Det rett og slett gjør laget kaldere. Mindre sammenhengende. Mindre villig til å hjelpe. Og så lurer vi på hvorfor folk ikke deler problemene sine "i de tidlige stadiene". Men fordi de allerede er en gang delt - og det returnerte til dem anonymt en liste over krav.

3. Så snart 360 påvirker beslutninger om markedsføring, begynner lekene

Her var det mest interessante. Og det tristeste.

På en av våre koordineringssamtaler la vi merke til noe merkelig. En person kan være høflig, støttende og lett å jobbe med i samtaler. Inne i laget kan de se ut som en komplett kjæreste. Og så du gir dem et "anonymt" spørreskjema der de kan "vurdere andre", og plutselig synker poengsummen eller kritikken blir overdreven. Vi så den effekten selv. Det virket direkte mot integriteten.

Forestill deg situasjonen. Du forteller teamet, "360 vurderinger teller mot opprykk." Og i samme sekund slår du en del av team inn i spillere, ikke kolleger. Fordi hvis "påvirkning"-knappen vises i systemet, noen vil trykke på den. Ikke alltid fra det onde. Noen ganger bare ved å føle urettferdighet ("og hvorfor blir han forfremmet, han er..."). Noen ganger fra konkurranse. Noen ganger fordi «det er slik verden fungerer». Og i det øyeblikket får du det du ønsket unngå: politikk, spilling, "i tilfelle lavere" karakterer.

Dette er forresten en av grunnene til at mange forskere og utøvere anbefales å dele tilbakemeldinger for utvikling og administrative vedtak (penger, karakterer, promo). CIPD sier det ganske rett ut: snakk om det er bedre å skille evalueringer/administrative vedtak fra samtaler, hvor det gis tilbakemelding med tanke på utvikling. Her er en PDF fra bevisgjennomgangen deres (praksissammendrag): www.cipd.org/...​e-review_tcm18-111378.pdf

4. Punkt fire (vår smertefulle innsikt). 360 erstatter ofte lederens arbeid

Etter flere sykluser endte vi opp med en setning som først hørtes ut som en fornærmelse og deretter hørtes ut som sannheten.

Hvis en leder trenger en 360 for å forstå hvordan folk jobber og hvor problemene er, den lederen har ikke et system med observerbare signaler. Det er ingen beregninger. Det finnes ingen vanlige samtaler. Det er ingen rytme. Eller alt dette eksisterer "et sted", men blir faktisk ikke brukt.

Og 360 blir en krykke: «Vi skal nå samle spørreskjemaet og til slutt vi skal lære sannheten." Og da får du ikke "sannheten" og et emosjonelt bilde, multiplisert med anonymitet, gjetting og politiske spill.

Så dette høres ikke ut som "det gikk dårlig for oss, derfor er 360 ond", vil jeg legge til en referanse.

Det er en studie om tilbakemeldinger fra flere kilder. Konklusjonen er i utgangspunktet: "ikke forvent magi". I en metaanalyse av 24 longitudinelle studier skriver Smither, London og Riley at forbedring etter 360 tilbakemeldinger er vanligvis beskjedne, og at du ikke bør forvente en stor "masseoppgradering" etter én bølge av tilbakemeldinger. Sjansen for forbedring vokser når en person ser et reelt behov for å endre seg, tar imot tilbakemeldingene, tror de kan endre seg, setter konkrete mål, og faktisk gjør noe, i stedet for å bare "lese en PDF og gå videre." Her er selve teksten (PDF): www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

Ok, vi fjernet 360. Hva erstattet den?

Vi sluttet å måle folk etter antall billetter

Én billett kan passe til en uke med forskning, en vanskelig avgjørelse, ti samtaler og bare 20 linjer med kode. I en annen - 50 funksjoner som faktisk kom ut av en kjøring av AI-agenten på 20 minutter.

Hvis du bare måler billetter, måler du faktisk ikke arbeidet, men hvordan prosessen din kutter arbeidet i biter

Derfor endret vi spørsmålet. Ikke "hvor mange oppgaver lukket jeg?" men: Hva ble levert, hvilken verdi skapte det, hva var kvaliteten, var det forutsigbart, og var statusene ærlige?

Hvordan vi definerte "resultat" uten ledelsesteater

Vi konvergerte om et enkelt rammeverk.

Et resultat er når verdien er levert, kvaliteten er akseptabel, teamet er forutsigbart og fremdriften er transparent.

Verdien er ikke "koden er skrevet". Det er «brukeren eller kunden fikk et bedre resultat» eller «det ble lettere for teamet for å støtte systemet".

Kvalitet er ikke "Jeg liker koden din". Dette er konsekvenser: feil i produktet, hendelser, revisjoner.

Forutsigbarhet er ikke «vi klarer det alltid». Det er: "vi forstår ærlig hva vi har tid til og hva vi ikke har, og vi lyver ikke for oss selv om det."

Åpenhet er når "nesten ferdig" ikke blir til en livsfilosofi.

Beregninger

Når folk hører ordet "metrics", mange umiddelbart husk den litt traumatiserte arbeideren fra tidligere erfaring: den som ble slått over hodet med tall.

Beregninger bør ikke være en pisk. De skal være briller. Uten dem er en leder ofte blind. Og når lederen er blind, begynner han å lete etter «objektivitet» i spørreskjemaer. Vel, du har det.

Vi forlot beregningene på teamnivå, fordi de fleste problemene er systemiske! Og hvis vi ikke vil lete etter de skyldige, men korrigere prosessen, må vi måle prosessen!

Vi har ærlig talt ikke funnet opp noe her. DORA (DevOps Forskning og vurdering) fremmer allerede en veldig praktisk sett med leveringsberegninger: hvor raskt du leverer endring og hvor smertefulle feil er når endringer går galt. Her er hurtigguiden deres: dora.dev/guides/dora-metrics.

Det er også en viktig bemerkning som jeg gjerne vil slå fast på veggen til alle som noen gang har ønsket å lage KPI-målinger: "ikke gjør metrikken til målet"! Fordi så snart du sier "vi må distribuere N ganger per dag", en del av teamet begynner å distribuere ikke verdi, men et tall. Dette er det gamle historien om at når en metrikk blir målet, slutter den å være en indikator. DORA viser eksplisitt til Goodharts lov og beskriver typiske fallgruver. Her er siden om "de fire/fem nøklene" med enkle ord: dora.dev/...​s/dora-metrics-four-keys

Og en viktig ting til som DORA vanligvis legger vekt på: konteksten er viktig. Disse beregningene vises best innen én team eller tjeneste og over tid, ikke ved å sammenligne en mobilapplikasjon med en stormaskin, eller et lite team med en plattform for 200 personer.

Hvis du ikke er et teknisk team, er logikken den samme. Istedenfor "distribuer" du kan ha "klienten akseptert resultatet"; istedenfor "hendelse" du kan ha "eskalering"; i stedet for "rollback", "rework etter justering". Poenget er fortsatt det samme: hvor raskt vi flytter verdi gjennom systemet og hvor mye feilen koster oss.

Og nå - det veldig viktige "ikke gjør det". Ikke konverter disse beregningene til individuelle KPIer! For da begynner folk å optimalisere ikke produktet, men antallet. KPI på «utplasseringer», og plutselig har du utplasseringer for utplasserings skyld. KPI på "syklustid", og oppgaver blir brutt ned til det absurde bare for å "lukke dem raskt", mens harde deler stille forsvinner inn i skyggene. KPI på "hendelser", og hendelser begynner å bli omdøpt til "særheter" eller "uventede brukerscenarier".

Det første som hjalp oss var forutsigbarhet. Enkel spørsmål: hva lovet vi i planleggingen og hva som faktisk ble gitt. Ikke for skam. For forståelse. For hvis du hele tiden lover 10 og gjør 6, da er ikke problemet "late folk". Problemet er i estimering, prioriteringer, WIP, blokkere, kontekstbytte. Med andre ord i ledelsen.

Det andre er leveringstid. Hvor lang tid tar oppgaven? på vei fra «tatt på jobb» til «faktisk levert». Det er veldig nøkternt. For det viser seg ofte at vi "skriver kode" raskt, men "leverer" sakte. Og så kan du se hvor flaskehalsen er: gjennomgang, testing, løslatelse, forsoning, avhengigheter.

Den tredje er WIP. Hvis teamet er "på jobb" samtidig ti problemer på en gang, så er det ingen som egentlig gjør noe. Mer presist, alle gjør alt på en gang. Og så lurer vi på hvorfor fremgang føles sakte og nervøs. Når hjernen er spredt i et tynt lag over ti oppgaver blir det ikke mer produktivt. Det blir bare mer sliten.

En annen ting som hjalp oss til å tenke klarere var dette: Hvis du vil at arbeidet skal gå raskere gjennom systemet, er svaret ofte å ikke presse hardere på folk. Det er for å redusere batchstørrelsen. Mindre endringer er lettere å gjennomgå, teste, frigi og rulle tilbake. DORA påpeker det samme direkte: mindre partier forbedrer vanligvis både hastighet og stabilitet. Det høres opplagt ut helt til et team faktisk prøver å leve etter det i en måned.

Kvalitet: vi sluttet å krangle «det virker for meg» og begynte å se på konsekvensene

Å vurdere «kvalitet» med spørreskjemaer er en dårlig idé. Fordi "kvalitet" i spørreskjemaet handler det ofte om sympati, stil og smak.

Vi gikk videre til konsekvensene.

Hvor mange defekter nådde produksjonen. Hvor seriøse var de? Hvordan endrer trenden seg?

Hvor mange hendelser har vi hatt. Hvor lang tid tok det før vi ble friske? Gjentas de samme grunnene?

Hvor mange revisjoner. Hvor mange oppgaver ble "bestått" og deretter returnert. Fordi «klar» viste seg å ikke være klar.

Du krangler ikke lenger om "hvem som er best". Du ser hva som egentlig skjer med produktet.

En motintuitiv konklusjon: Hvorfor vurdere en person i det hele tatt?

Jo lenger vi gravde, jo oftere snublet vi over et merkelig spørsmål.

Hvorfor vurderer vi en person? Å nekte en forfremmelse? For å vise hvem "stjernen" er? For å sammenligne folk?

Og da vi snakket ærlig om det, viste det seg at de fleste av våre virkelige behov ikke handlet om rangering mennesker. De handlet om teamprestasjoner: gjør vi hva vi lovet, er kvaliteten god, er arbeidet forutsigbart, brenner vi ut, og får klienten hva forventer de?

Altså om systemet.

Og i så fall er det første evalueringsobjektet teamet og prosessen. Og ikke en person som mål.

Teamet underpresterer, så vi gjennomgår helheten kjede: ansettelse, onboarding, oppgavedefinisjon, planlegging, gjennomgang, testing, utgivelse, kommunikasjon, avhengigheter. Dette er ledelsesmessig vanskeligere, ja. Men det er mer ærlig.

Noen ganger ser det veldig jordnært ut. For eksempel når "vi hadde ikke tid igjen", det første spørsmålet er ikke "hvem bremser", og "hvor forsvant tiden". For tiden kan forsvinne ikke i "arbeid", men i venting: oppgaver ligger i gjennomgang, stå i testing, blokkert etter avtale, eller det er rett og slett for mange av dem parallelt.

Når noen sliter, hva vi sjekker først

Vi ser også noen ganger situasjoner når noen «ikke drar». Men i stedet for et spørreskjema, gjør vi en enkel diagnose.

Har dette problemet alltid vært der? I så fall er problemet sannsynlig i ansettelse eller onboarding. I så fall fikser du ansettelsesprosessen, ikke personen med spørreskjemaer.

Var det normalt før og så ble det ille? Da det kan være konteksten: utbrenthet, endring av oppgaver, rollekonflikt, personlige forhold. Dette er sonen for normalt lederarbeid: finne ut hva som skjedde, reduser belastningen, hjelp personen til å komme seg tilbake kontroll, og lag en kort 2-4 ukers restitusjonsplan.

Har personen en klar forståelse av hvilken suksess ser ut som i nær fremtid? For ofte er det ikke problemet at personen er "svak". Det er at vi plasserte dem i tåke og kalte det forventninger.

Og en nyanse til som vi også hadde. Hvis en person mislyktes flere ganger, kan lederen noen ganger heve subjektivt bar: "nå bevis at du ikke er en fiasko." Dette fungerer ofte på et underbevisst nivå, og det fungerer dårlig for laget. Det er vanligvis bedre å gjøre det motsatte: redusere omfanget, gjøre oppgavene mindre, fjern støyen, gi en person en sjanse til å konsekvent gjøre et par ting godt og få tilbake selvtilliten. Dette er en vanskelig oppgave for ledere. Og det er nettopp derfor vi ser veldig nøye etter hos lederne vi ansetter.

Konklusjoner

Selvfølgelig kan 360-en fungere. I store selskaper, hvor anonymitet virkelig er mulig.

Når teamet allerede har en kultur med direkte tilbakemeldinger, og 360 er et tilleggssignal, ikke det viktigste "sannhet".

Det hadde vi ikke. Vi hadde små team, høyt tempo og høye kostnader for mistillit.

360 så ut som et voksent verktøy på papiret. I vår virkeligheten har det blitt en mekanisme som samler frykt på ett sted, gjetting, konkurranse og «kollektiv dømmekraft».

Vi kuttet ut 360 og gikk tilbake til det grunnleggende: enkle teamberegninger, åpne samtaler og transparente statuser.

Materialer og lenker (hvis du vil grave dypere)

DORA — software delivery performance metrics. En begrunnet forklaring av de fem metrikkene og fellene lagene faller i når de misbruker dem.

DORA — DORA’s software delivery performance metrics. Kortversjon med historisk "hvorfor fire/fem" og en advarsel om spill med beregninger.

DORA Research: 2024 — DORA Report. Full rapport (last ned PDF på forskjellige språk).

Smither, London (2005) — meta-analysis on multisource feedback. Hvorfor du ikke bør forvente en magisk effekt fra én 360-bølge.

CIPD — Performance feedback: an evidence review (PDF). Om hvordan tilbakemelding fungerer/ikke fungerer og hvorfor det ofte er skadelig å forveksle «vurdering» med «utvikling».

CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Hvis du fortsatt gjør en 360, er det noe å tenke på før start, ikke etter brannen.

CCL — SBI feedback model. Et veldig enkelt rammeverk for "ingen snarveier" tilbakemelding.

Google SRE — Postmortem Culture: Learning from Failure. Om ulastelige postmortems og hvorfor shaming-kultur dreper læring.

Amy Edmondson (1999) — Psychological Safety (PDF). Primærkilde om psykologisk sikkerhet i team.

WEF — Feedforward technique. Om hvordan man kan flytte tilbakemeldinger i retning av «hva vi gjør videre» og ikke «hva som skjedde i går».

Goodhart’s law. En av de mest nyttige "anti-teoriene" for alle som ønsker å lage KPI-målinger.

Spørsmål til fellesskapet

Hva synes samfunnet om 360? Bruker du det? Hvordan har din erfaring vært?

Hvordan løser man problemet med «anonymitet» når teamet er lite og alle forstår alt?

Og hvilke leverings-/kvalitetsmålinger hjelper deg faktisk med å administrere prosessen i stedet for å tegne pene rapporter?

Takk for din tid og oppmerksomhet.