Killing 360 Reviews: Hur vi slutade betygsätta människor och började hantera arbetet

Hej! Jag heter Vitalina och är kontoansvarig på SToFU Systems.

Vi är den typen av företag där processer föds i rörelse och först senare får namn, regler och vuxenövervakning. I början hade vi ingen egen managementskola så vi kopierade det som "alla kopierar". En av de lånade förvaltningsvanorna var 360-feedback.

På pappret ser 360:an ut som något rättvist och moget. Många källor. Mindre partiskhet. "Objektivitet". Mmmm!

I praktiken blev det något annat. För oss var 360 inte ett verktyg som stärkte laget. Det var ett verktyg som tyst drog isär laget. Formellt såg det korrekt ut, men i verkligheten knuffade det åt fel håll. Så vi klippte bort det. Låt oss gå steg för steg.

Vad är 360?

360 är när du samlar in feedback om en person "från alla håll": från chefen, kollegor, intilliggande lagkamrater och ibland klienter. Vanligtvis det är ett frågeformulär med betyg och frågor som "vad går bra", "vad kommer i vägen", "vad bör ändras".

Det gjorde vi också. Vi skickade ut ett frågeformulär, samlade in svar, sammanställde dem och skrev rekommendationer. Formellt såg allt snyggt ut. Det fanns datapunkter. Det blev slutsatser. Det fanns en "utvecklingsplan".

För att tydliggöra vilken typ av "enkät" vi pratar om ska jag ge ett mycket förenklat exempel på vad som brukar ställas i 360. Detta är inte ett ord-för-ord-citat från vårt formulär, utan typisk logik.

Till exempel: "Vad ska en person fortsätta att göra?". Sedan: "Vad ska en person börja göra?". Sedan: "Vad ska en person sluta med?". Och en annan fråga som alltid verkar oskyldig: "Beskriv en situation när interaktionen var svår och varför."

Och sammanfattningen ser ofta ut som en liten rapport från ett kollektivt allseende öga. Ungefär så här:

Styrkor: tar upp uppgifter snabbt, hjälper andra, försvinner inte från radarn. Risker: "klar" betyder ibland "nästan klar", diskussionen på möten kan vara skarp, i chatten svarar han i fragment. Vad du ska göra härnäst: komma överens om definitionen av klar, synkronisera förväntningar, komma överens om eskaleringsformatet.

På pappret är allt bra. Vackert, till och med. Men det finns en detalj. Den är skriven av människor som arbetar tillsammans varje dag. Och när du lägger till anonymitet, eller försenad feedback "för senare", det slutar vara ett utvecklingsverktyg och börjar leva ett eget liv. Föreställ dig ett projektteam av fem personer. Då säger någon: "Här är anonym feedback." Anonym. I ett lag om fem. Och i denna verklighet börjar 360 visa sitt sanna ansikte.

Varför 360 blev ett verktyg för att dra isär laget

1. Punkt ett. Beröm - en rad, kritik - en tredelad roman

När det är bra skriver folk kort. "Allt är ok." "Bekvämt arbete." "Bra gjort". Det här är feedback på nivån som ett klistermärke på en skolanteckningsbok. När något är fel, börjar litteraturen. Med detaljer, med exempel, med känslor. Och tekniskt sett är detta normalt: negativt är lättare att specificera än positivt. Men i 360 finns det problemet: hela denna "roman" kommer sedan tillbaka till en person som en generaliserad dom från laget.

Även om du formulerar det så försiktigt som möjligt, den mänskliga hjärnan läser det så här: "Vi samlades alla och skrev ner vad är det för fel på dig." Och det är det. Efter det, varje försök till "konstruktiv feedback" känns som en förhandling i domstol. Du ville ett utvecklingsverktyg, och fick en kollektiv nämnd.

Vi frågade oss ärligt: ​​vad försöker vi egentligen göra med denna praxis? Det disciplinerar formatet, ja, men det förstör förtroendet.

Ur livet ser det ut så här. En anmälan kommer till en person, där det finns tre fraser "allt är ok", och två dukar "det är därför det inte är ok". Och hjärnan kommer förstås inte ihåg tre "ok", utan två "inte ok". För att det är så uppmärksamheten är ordnad: det gör ont, så det är viktigt! Och från den tidpunkten, personen rör sig inte mot utveckling, utan mot självförsvar. De börja bevisa att "det inte är sant", eller att "det var sammanhanget", eller att "ni är inte heller helgon". Och i detta ögonblick förvandlas 360 till en ritual där alla som om de ville gott, men det blev som vanligt.

2. Punkt två. Anonymitet i ett litet team är självbedrägeri

Det finns en välbekant managementsaga: "Anonym feedback tar bort rädsla." Anonymitet? Verkligen? I små projektteam? I verkligheten betyder det nästan alltid "jag ska gissa vem som skrev det här!".

En person får flera obehagliga kommentarer, och sedan kommer till nästa projektmöte där samma 3-5 personer sitter. De tänker inte på "organisationsutveckling". De tänker, "Vilket en av er var det?" Och det startar en mycket giftig process: alla förblir utåt sett artig, men undertill finns ett dolt lager av misstro.

Det exploderar inte alltid i öppen konflikt. Det helt enkelt gör laget kallare. Mindre sammanhållen. Mindre villig att hjälpa. Och så undrar vi varför folk inte delar med sig av sina problem "i tidiga skeden". Men eftersom de redan är en gång delas - och det återvände till dem anonymt en lista över anspråk.

3. Så fort 360 påverkar marknadsföringsbeslut börjar spelen

Här var det mest intressanta. Och det sorgligaste.

Vid en av våra samordningsdiskussioner märkte vi något konstigt. En person kan vara artig, stödjande och lätt att arbeta med vid samtal. Inuti laget kan de se ut som en komplett älskling. Och sedan du ger dem ett "anonymt" frågeformulär där de kan "bedöma andra", och plötsligt sjunker poängen eller kritiken blir överdriven. Den effekten såg vi själva. Det fungerade direkt mot integriteten.

Föreställ dig situationen. Du säger till laget, "360 betyg räknas mot befordran." Och i samma sekund blir du en del av team till spelare, inte kollegor. För om knappen "påverkan" visas i systemet, någon kommer att trycka på den. Inte alltid från det onda. Ibland bara genom att känna orättvisa ("och varför befordras han, han är..."). Ibland från konkurrens. Ibland för att "det är så världen fungerar". Och i det ögonblicket får du vad du ville ha undvika: politik, spel, "ifall lägre" betyg.

Detta är förresten en av anledningarna till att många forskare och utövare rekommenderas att dela feedback för utveckling och administrativa beslut (pengar, betyg, promo). CIPD uttrycker det ganska rakt på sak: prata om det är bättre att skilja utvärderingar/administrativa beslut från samtal, där återkoppling ges i utvecklingssyfte. Här är en PDF från deras bevisgranskning (praxissammanfattning): www.cipd.org/...​e-review_tcm18-111378.pdf

4. Punkt fyra (vår smärtsamma insikt). 360 ersätter ofta chefens arbete

Efter flera cykler slutade vi med en fras som först lät som en förolämpning och sedan lät som sanningen.

Om en chef behöver en 360 för att förstå hur människor arbetar och var problemen finns, den chefen har inte ett system med observerbara signaler. Det finns inga mätvärden. Det finns inga regelbundna samtal. Det finns ingen rytm. Eller allt det där finns "någonstans", men används faktiskt inte.

Och 360 blir en krycka: "vi ska nu samla in frågeformuläret och slutligen vi kommer att lära oss sanningen." Och då får du inte "sanningen" och en känslomässig bild, multiplicerad med anonymitet, gissningar och politiska spel.

Så det här låter inte som "det gick dåligt för oss, därför är 360 evil", jag lägger till en referens.

Det finns en studie om feedback från flera källor. Dess slutsats är i grunden: "förvänta dig inte magi". I en metaanalys av 24 longitudinella studier skriver Smither, London och Riley att förbättring efter 360-återkoppling är vanligtvis blygsam, och att du inte bör förvänta dig en stor "massuppgradering" efter en våg av feedback. Chansen till förbättring ökar när en person ser ett verkligt behov av att förändras, accepterar feedbacken, tror att de kan förändras, sätter upp konkreta mål, och faktiskt gör något, istället för att bara "läsa en PDF och gå vidare." Här är själva texten (PDF): www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

Okej, vi tog bort 360. Vad ersatte den?

Vi slutade mäta människor efter biljettantal

En biljett kan passa en veckas forskning, ett svårt beslut, tio samtal och bara 20 rader kod. I en annan - 50 funktioner som faktiskt kom ur en körning av AI-agenten på 20 minuter.

Om du bara mäter biljetter så mäter du faktiskt inte arbetet, utan hur din process skär ner arbetet i bitar

Det är därför vi ändrade frågan. Inte "hur många uppgifter stängde jag?" men: Vad levererades, vilket värde skapade det, vad var kvaliteten, var det förutsägbart och var statusen ärlig?

Hur vi definierade "resultat" utan managementteater

Vi konvergerade på ett enkelt ramverk.

Ett resultat är när värde levereras, kvalitet är acceptabel, teamet är förutsägbart och framstegen är transparenta.

Värdet är inte "koden är skriven". Det är "användaren eller kunden fick ett bättre resultat" eller "det blev lättare för teamet för att stödja systemet".

Kvalitet är inte "jag gillar din kod". Dessa är konsekvenser: buggar i produkten, incidenter, revisioner.

Förutsägbarhet är inte "vi klarar det alltid". Det är: "vi förstår ärligt vad vi har tid för och vad vi inte har, och vi ljuger inte för oss själva om det."

Transparens är när "nästan gjort" inte blir till en livsfilosofi.

Metrik

När folk hör ordet "metrics", många direkt minns den lätt traumatiserade arbetaren från tidigare erfarenheter: den som blev slagen över huvudet med siffror.

Mätvärden ska inte vara en piska. De ska vara glasögon. Utan dem är en chef ofta blind. Och när chefen är blind börjar han leta efter "objektivitet" i frågeformulär. Tja, du fattar.

Vi lämnade mätvärdena på lagnivå, eftersom de flesta av problemen är systemiska! Och om vi inte vill leta efter de skyldiga, utan korrigera processen, måste vi mäta processen!

Vi har ärligt talat inte hittat på något här. DORA (DevOps Forskning och bedömning) främjar redan en mycket praktisk uppsättning leveransmått: hur snabbt du levererar förändringar och hur smärtsamma misslyckanden är när förändringar går fel. Här är deras snabbguide: dora.dev/guides/dora-metrics.

Det finns också en viktig anmärkning som jag skulle vilja spika fast på väggen till alla som någonsin velat göra KPI-mått: "gör inte måtten till målet"! För så snart du säger "vi måste distribuera N gånger per dag", en del av teamet börjar distribuera inte värde, utan ett nummer. Det här är det gamla berättelse om att när ett mått väl blir målet slutar det att vara det en indikator. DORA hänvisar uttryckligen till Goodharts lag och beskriver typiska fallgropar. Här är sidan om "fyra/fem nycklar" med enkla ord: dora.dev/...​s/dora-metrics-four-keys

Och ytterligare en viktig sak som DORA normalt betonar: sammanhang är viktigt. Dessa mätvärden visas bäst inom en team eller tjänst och över tid, inte genom att jämföra en mobilapplikation med stordator eller ett litet team med en plattform för 200 personer.

Om du inte är ett tekniskt team är logiken densamma. I stället för "deploy" kan du ha "klienten accepterat resultatet"; i stället för "incident" du kan ha "eskalering"; istället för "rollback", "omarbeta efter justering". Poängen är fortfarande densamma: hur snabbt vi flyttar värde genom systemet och hur mycket felet kostar oss.

Och nu - det mycket viktiga "gör inte det". Konvertera inte dessa mätvärden till individuella nyckeltal! För då börjar folk att optimera inte produkten, utan antalet. KPI på "deploys", och plötsligt har man utrullningar för utplaceringarnas skull. KPI på "cykeltid", och uppgifter bryts ner till absurditet bara för att "stänga dem snabbt", medan hårda delar tyst försvinner in i skuggorna. KPI på "incidenter", och incidenter börjar döpas om till "egenheter" eller "oväntade användarscenarier".

Det första som hjälpte oss var förutsägbarhet. Enkel fråga: vad lovade vi i planeringen och vad som faktiskt gavs. Inte för skam. För förståelse. För om du hela tiden lovar 10 och gör 6, då är inte problemet "lata människor". Problemet är uppskattningsvis, prioriteringar, WIP, blockerare, kontextväxling. Med andra ord inom förvaltningen.

Det andra är leveranstid. Hur lång tid tar uppgiften? på väg från "tagen till jobbet" till "faktiskt levererad". Det är väldigt nykter. För det visar sig ofta att vi "skriver kod" snabbt, men "levererar" långsamt. Och sedan kan du se var flaskhalsen är: granskning, testning, frigivning, försoning, beroenden.

Den tredje är WIP. Om teamet är "på jobbet" samtidigt tio problem på en gång, då gör ingen egentligen någonting. Mer exakt, alla gör allt på en gång. Och så undrar vi varför framsteg känns långsam och nervös. När hjärnan sprids i ett tunt lager över tio uppgifter blir det inte mer produktivt. Det blir bara tröttare.

En annan sak som hjälpte oss att tänka tydligare var detta: om du vill att arbetet ska gå snabbare genom systemet är svaret ofta att inte trycka hårdare på människor. Det är för att minska batchstorleken. Mindre ändringar är lättare att granska, testa, släppa och återställa. DORA påpekar samma sak direkt: mindre partier förbättrar vanligtvis både hastighet och stabilitet. Det låter självklart tills ett team faktiskt försöker leva efter det i en månad.

Kvalitet: vi slutade argumentera "det verkar för mig" och började titta på konsekvenserna

Att bedöma "kvalitet" med frågeformulär är en dålig idé. Eftersom "kvalitet" i enkäten handlar det ofta om sympati, stil och smak.

Vi gick vidare till konsekvenserna.

Hur många defekter nådde produktionen. Hur seriösa var de? Hur förändras trenden?

Hur många incidenter har vi haft. Hur lång tid tog det för oss att återhämta oss? Upprepas samma skäl?

Hur många revisioner. Hur många uppgifter som "godkändes" och sedan returnerades. För "klar" visade sig inte vara redo.

Du bråkar inte längre om "vem som är bäst". Du ser vad som verkligen händer med produkten.

En kontraintuitiv slutsats: Varför utvärdera en person överhuvudtaget?

Ju längre vi grävde, desto oftare snubblade vi över en konstig fråga.

Varför utvärderar vi en person? Att vägra en befordran? För att visa vem "stjärnan" är? Att jämföra människor?

Och när vi pratade ärligt om det visade det sig att de flesta av våra verkliga behov inte handlade om rangordning personer. De handlade om lagets prestation: gör vi vad vi lovade, är kvaliteten bra, är arbetet förutsägbart, bränner vi ut och får kunden vad förväntar de sig?

Det vill säga om systemet.

Och i så fall är det första objektet för utvärderingen teamet och processen. Och inte en person som mål.

Teamet underpresterar, så vi ser över helheten kedja: anställning, introduktion, uppgiftsdefinition, planering, granskning, testning, release, kommunikation, beroenden. Detta är ledningsmässigt svårare, ja. Men det är mer ärligt.

Ibland ser det väldigt jordnära ut. Till exempel när "vi hann inte igen", den första frågan är inte "vem saktar ner", och "var försvann tiden". För tiden kan försvinna inte i "arbete", utan i väntan: uppgifter ligger vid granskning, stå i testning, blockerad enligt överenskommelse, eller det är helt enkelt för många av dem parallellt.

När någon kämpar, vad vi kollar först

Vi ser också ibland situationer när någon "inte drar". Men istället för ett frågeformulär gör vi en enkel diagnos.

Har det här problemet alltid funnits? Om så är fallet är problemet troligt vid anställning eller onboarding. I så fall fixar du anställningsprocessen, inte personen med frågeformulär.

Var det normalt innan och sedan blev det illa? Sedan det kan vara sammanhanget: utbrändhet, byte av uppgifter, rollkonflikt, personliga omständigheter. Detta är zonen för normalt chefsarbete: ta reda på vad som hände, minska belastningen, hjälp personen att komma tillbaka kontrollera och skapa en kort 2-4 veckors återhämtningsplan.

Har personen en klar förståelse för vilken framgång ser ut som inom en snar framtid? För ofta är det inte problemet att personen är "svag". Det är att vi placerade dem i dimma och kallade det förväntningar.

Och ytterligare en nyans som vi också hade. Om en person misslyckats flera gånger, kan chefen ibland höja subjektivt bar: "bevisa nu att du inte är ett misslyckande." Det fungerar ofta på en undermedveten nivå, och det fungerar dåligt för laget. Det är vanligtvis bättre att göra tvärtom: minska omfattningen, göra uppgifterna mindre, ta bort bruset, ge en person en chans att konsekvent göra några saker bra och återfå självförtroendet. Detta är en svår uppgift för chefer. Och det är just därför vi tittar väldigt noga hos de chefer vi anställer.

Slutsatser

Självklart kan 360:a fungera. I stora företag, där anonymitet verkligen är möjlig.

När teamet redan har en kultur av direkt feedback, och 360 är en extra signal, inte huvudsignalen "sanning".

Det hade vi inte. Vi hade små team, ett högt tempo och en hög kostnad för misstroende.

360:an såg ut som ett vuxet verktyg på papper. I vår verkligheten har det blivit en mekanism som samlar rädsla på ett ställe, gissningar, konkurrens och "kollektivt omdöme".

Vi klippte ut 360 och gick tillbaka till grunderna: enkla teamstatistik, öppna konversationer och transparenta statusar.

Material och länkar (om du vill gräva djupare)

DORA — software delivery performance metrics. En grundad förklaring av de fem mätvärdena och fällorna som team hamnar i när de missbrukar dem.

DORA — DORA’s software delivery performance metrics. Kort version med historiskt "varför fyra/fem" och en varning om spel med mätvärden.

DORA Research: 2024 — DORA Report. Hela rapporten (ladda ned PDF på olika språk).

Smither, London (2005) — meta-analysis on multisource feedback. Varför du inte ska förvänta dig en magisk effekt från en 360-våg.

CIPD — Performance feedback: an evidence review (PDF). Om hur feedback fungerar/inte fungerar och varför att blanda ihop "bedömning" med "utveckling" ofta är skadligt.

CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Om du ändå gör en 360 så finns det något att tänka på innan starten, inte efter branden.

CCL — SBI feedback model. Ett mycket enkelt ramverk för "inga genvägar"-feedback.

Google SRE — Postmortem Culture: Learning from Failure. Om oklanderliga obduktioner och varför skamkultur dödar lärande.

Amy Edmondson (1999) — Psychological Safety (PDF). Primär källa om psykologisk säkerhet i team.

WEF — Feedforward technique. Om hur man flyttar feedback i riktning mot "vad vi gör härnäst" och inte "vad som hände igår".

Goodhart’s law. En av de mest användbara "antiteorierna" för alla som vill göra KPI-mått.

Frågor till gemenskapen

Vad tycker samhället om 360? Använder du det? Hur har din upplevelse varit?

Hur löser man problemet med "anonymitet" när teamet är litet och alla förstår allt?

Och vilka leverans-/kvalitetsmått hjälper dig faktiskt att hantera processen snarare än att rita snygga rapporter?

Tack för din tid och uppmärksamhet.