Killing 360 Reviews: Kuinka lopetimme ihmisten arvioinnin ja aloimme johtaa työtä

Hei! Nimeni on Vitalina ja olen tilivastaava osoitteessa SToFU Systems.

Olemme sellainen yritys, jossa prosessit syntyvät liikkeessä ja vasta myöhemmin saamme nimet, säännöt ja aikuisten valvonnan. Alussa meillä ei ollut omaa johtamiskoulua, joten kopioimme mitä "kaikki kopioivat". Yksi lainatuista johtamistavoista oli 360 palaute.

Paperilla 360 näyttää reilulta ja kypsältä. Monet lähteet. Vähemmän puolueellisuutta. "Objektiivisuus". Mmmm!

Käytännössä se muuttui joksikin muuksi. Meille 360 ​​ei ollut työkalu, joka vahvisti joukkuetta. Se oli työkalu, joka erotti joukkueen hiljaa. Muodollisesti se näytti oikealta, mutta todellisessa työssä se työnsi väärään suuntaan. Joten leikkasimme sen pois. Mennään askel askeleelta.

Mikä on 360?

360 on, kun keräät palautetta henkilöstä "kaikilta puolilta": johtajalta, kollegoilta, viereisiltä joukkuetovereilta ja joskus asiakkailta. Yleensä se on kyselylomake, jossa on arvioita ja kysymyksiä, kuten "mikä menee hyvin", "mikä haittaa", "mitä pitäisi muuttaa".

Teimme sen myös. Lähetimme kyselylomakkeen, keräsimme vastaukset, kokosimme ne ja kirjoitimme suosituksia. Muodollisesti kaikki näytti siistiltä. Datapisteitä oli. Tuli johtopäätökset. Siellä oli "kehityssuunnitelma".

Selvittääkseni, millaisesta "kyselylomakkeesta" puhumme, annan hyvin yksinkertaistetun esimerkin siitä, mitä yleensä kysytään 360:ssa. Tämä ei ole sana sanaan lainaus lomakkeestamme, vaan tyypillinen logiikka.

Esimerkiksi: "Mitä henkilön pitäisi jatkaa?". Sitten: "Mitä ihmisen pitäisi alkaa tehdä?". Sitten: "Mitä ihmisen pitäisi lopettaa tekemästä?". Ja toinen kysymys, joka näyttää aina viattomalta: "Kuvaile tilannetta, jolloin vuorovaikutus oli vaikeaa ja miksi."

Ja yhteenveto näyttää usein pieneltä raportilta kollektiivisesta kaiken näkevästä silmästä. Suunnilleen näin:

Vahvuudet: poimii tehtävät nopeasti, auttaa muita, ei katoa tutkasta. Riskit: "valmis" joskus tarkoittaa "melkein valmis", keskustelu kokouksissa voi olla terävää, chatissa hän vastaa sirpaleina. Mitä tehdä seuraavaksi: sovi valmiin määritelmästä, synkronoi odotukset, sovi eskalaatiomuodosta.

Paperilla kaikki on hyvin. Kaunis, tasainen. Mutta on yksi yksityiskohta. Sen kirjoittavat ihmiset, jotka työskentelevät yhdessä joka päivä. Ja kun lisäät anonymiteetin tai viivästyvät palautetta "myöhemmin", se lakkaa olemasta kehitystyökalu ja alkaa elää omaa elämäänsä. Kuvittele projektiryhmä viidestä ihmisestä. Sitten joku sanoo: "Tässä on nimetöntä palautetta." Nimetön. Viiden hengen joukkueessa. Ja tässä todellisuudessa 360 alkaa näyttää todellisia kasvojaan.

Miksi 360:sta tuli työkalu joukkueen erottamiseen

1. Kohta yksi. Ylistys - yksi rivi, kritiikki - kolmiosainen romaani

Kun asiat ovat hyvin, ihmiset kirjoittavat lyhyesti. "Kaikki on ok." "Mukava työ." "Hyvin tehty". Tämä on palautetta kouluvihkoon tarran tasolla. Kun jotain on vialla, kirjallisuus alkaa. Yksityiskohtien kera, esimerkeillä, tunteilla. Ja teknisesti tämä on normaalia: negatiivinen on helpompi määritellä kuin positiivinen. Mutta 360:ssa on ongelma: tämä koko "romaani" palaa sitten yhdelle henkilölle yleistettynä joukkueen tuomio.

Vaikka ilmaisit sen mahdollisimman lempeästi, ihmisaivot lukee sen näin: "Me kaikki kokoontuimme yhteen ja kirjoitimme ylös mikä sinua vaivaa." Ja siinä se. Sen jälkeen mikä tahansa yritys "rakentava palaute" tuntuu oikeudenkäynniltä. Sinä halusit kehitystyökalu, ja sai kollektiivisen tuomioistuimen.

Kysyimme rehellisesti itseltämme: mitä me todella yritämme tehdä tämä käytäntö? Se kurittaa muotoa, kyllä, mutta se tuhoaa luottamuksen.

Elämästä se näyttää tältä. Henkilölle tulee ilmoitus, jossa on kolme lauseita "kaikki on ok" ja kaksi kangasta "siksi se ei ole ok". Ja aivot eivät tietenkään muista kolmea "ok", vaan kaksi "ei ok". Koska huomio on järjestetty näin: se sattuu, joten se on tärkeää! Ja siitä lähtien, henkilö ei liiku kehitystä, vaan itsepuolustusta kohti. Ne alkaa todistaa, että "se ei ole totta", tai että "se oli konteksti" tai että "et sinäkään ole pyhiä". Ja tällä hetkellä 360 muuttuu rituaaliksi, jossa kaikki ikään kuin he olisivat halunneet hyvää, mutta siitä tuli kuten tavallisesti.

2. Kohta kaksi. Nimettömyys pienessä tiimissä on itsepetosta

On tuttu johtamisen satu: "Anonyymi palaute poistaa pelon." Nimettömyys? Todella? Pienissä projektiryhmissä? Todellisuudessa se tarkoittaa melkein aina "Arvaan kuka tämän kirjoitti!".

Henkilö saa useita epämiellyttäviä huomautuksia ja sitten tulee seuraavaan projektikokoukseen, jossa samat 3-5 henkilöä istuvat. He eivät ajattele "organisaation kehittämistä". He ajattelevat: "Mikä yksi teistä oli se?" Ja se käynnistää erittäin myrkyllisen prosessin: kaikki pysyy ulkoisesti kohtelias, mutta sen alla on piilotettu epäluottamuskerros.

Se ei aina räjähdy avoimeen konfliktiin. Se yksinkertaisesti tekee joukkueesta kylmemmän. Vähemmän yhtenäistä. Vähemmän halukas auttamaan. Ja sitten ihmetellään, miksi ihmiset eivät jaa ongelmiaan "alkuvaiheessa". Mutta koska ne ovat jo kerran jaettu - ja se palasi heille nimettömänä luettelo vaatimuksista.

3. Pelit alkavat heti, kun 360 vaikuttaa myynninedistämispäätöksiin

Tässä oli mielenkiintoisin asia. Ja surullisin asia.

Yhdessä koordinointikeskustelussamme huomasimme jotain outoa. Henkilö voi olla kohtelias, kannustava ja hänen kanssaan on helppo työskennellä puheluissa. Joukkueen sisällä he voivat näyttää täydelliseltä kultaseni. Ja sitten annat heille "anonyymin" kyselylomakkeen, jossa he voivat "arvostella muita", ja yhtäkkiä pisteet putoavat tai kritiikki muuttuu liialliseksi. Näimme sen vaikutuksen itsekin. Se toimi suoraan rehellisyyttä vastaan.

Kuvittele tilanne. Kerrot tiimille: "360 arviot otetaan huomioon edistäminen." Ja samalla sekunnilla käännät osan tiimistä pelaajia, ei kollegoita. Koska jos "vaikuta"-painike ilmestyy järjestelmään, joku painaa sitä. Ei aina pahasta. Joskus vain tunteella epäoikeudenmukaisuus ("ja miksi häntä ylennetään, hän on..."). Joskus kilpailusta. Joskus siksi, että "maailma toimii näin". Ja sillä hetkellä saat mitä halusit välttää: politiikkaa, pelaamista, "varmuuden vuoksi alempia" arvosanoja.

Tämä on muuten yksi syy siihen, miksi monet tutkijat ja harjoittajia kehotetaan jakamaan palautetta kehitystä varten ja hallinnolliset päätökset (rahat, arvosanat, promo). CIPD ilmaisee asian melko suoraan: puhua on parempi erottaa arvioinnit/hallinnolliset päätökset keskusteluista, jossa palautetta annetaan kehittämistä varten. Tässä on PDF heidän todisteiden tarkastelusta (käytännön yhteenveto): www.cipd.org/...​e-review_tcm18-111378.pdf

4. Kohta neljä (tuskallinen näkemyksemme). 360 korvaa usein esimiehen työn

Useiden syklien jälkeen päädyimme lauseeseen, joka kuulosti ensin loukkaukselta ja sitten totuudelta.

Jos johtaja tarvitsee 360 ​​ymmärtääkseen kuinka ihmiset työskentelevät ja missä ongelmat ovat, se johtaja sillä ei ole havaittavien signaalien järjestelmää. Mittareita ei ole. Niitä ei ole säännöllisiä keskusteluja. Ei ole rytmiä. Tai kaikki tämä on olemassa "jossain", mutta sitä ei todellisuudessa käytetä.

Ja 360:sta tulee kainalosauva: "keräämme nyt kyselylomakkeen ja lopuksi opimme totuuden." Ja sitten et ymmärrä "totuutta" ja tunnekuva, kerrottuna nimettömyydellä, arvailulla ja poliittisia pelejä.

Joten tämä ei kuulosta "se meni huonosti meille, siksi 360 on paha", lisään viittauksen.

Monen lähteen palautteesta on tehty tutkimus. Sen johtopäätös on pohjimmiltaan: "älä odota taikuutta". Smither, Lontoo ja Riley kirjoittavat 24 pitkittäistutkimuksen meta-analyysissä, että parannus sen jälkeen 360-palaute on yleensä vaatimatonta, eikä sitä kannata odottaa suurta "massapäivitys" yhden palauteaallon jälkeen. Parantumisen mahdollisuus kasvaa, kun ihminen näkee todellisen tarpeen muuttua, ottaa vastaan ​​palautteen, uskoo voivansa muuttua, asettaa konkreettisia tavoitteita, ja todella tekee jotain sen sijaan, että vain "luettaisiin PDF-tiedostoa ja eteenpäin." Tässä on itse teksti (PDF): www.bauer.uh.edu/...​ngs/SmitherLondon2005.pdf

Okei, poistimme 360:n. Mikä korvasi sen?

Lopetimme ihmisten mittaamisen lippujen määrän perusteella

Yhdelle lipulle mahtuu viikko tutkimusta, vaikea päätös, kymmenen puhelua ja vain 20 riviä koodia. Toisessa - 50 ominaisuutta, jotka todella tulivat yhdestä AI-agentin ajosta 20 minuutissa.

Jos mittaat vain lippuja, mittaat itse asiassa ei työ, vaan kuinka prosessisi leikkaa työtä paloiksi

Siksi muutimme kysymyksen. Ei "kuinka monta tehtävää suljin?" mutta: Mitä toimitettiin, mitä arvoa se loi, mikä oli laatu, oliko se ennustettavissa ja olivatko tilat rehellisiä?

Kuinka määrittelimme "tuloksen" ilman johtamisteatteria

Lähestyimme yksinkertaista kehystä.

Tulos on, kun arvo on toimitettu, laatu on hyväksyttävää, tiimi on ennakoitavissa ja edistyminen läpinäkyvää.

Arvo ei ole "koodi on kirjoitettu". Se on "käyttäjä tai asiakas sai paremman tuloksen" tai "se oli helpompaa tiimille". tukemaan järjestelmää".

Laatu ei ole "Pidän koodistasi". Nämä ovat seurauksia: tuotteen virheet, tapaukset, päivitykset.

Ennustettavuus ei ole "me aina onnistumme". Se on: "Ymmärrämme rehellisesti, mihin meillä on aikaa ja mihin ei, emmekä valehtele itsellemme siitä."

Avoimuus on sitä, kun "melkein valmis" ei muutu elämänfilosofiaksi.

Mittarit

Kun ihmiset kuulevat sanan "mittarit", monet heti muista hieman traumatisoitunut työntekijä aikaisemmasta kokemuksesta: se, jota hakattiin päähän numeroilla.

Mittarit eivät saa olla piiskaa. Niiden pitäisi olla lasit. Ilman niitä johtaja on usein sokea. Ja kun johtaja on sokea, hän alkaa etsiä "objektiivisuutta" kyselylomakkeista. No, sait sen.

Jätimme mittarit tiimitasolle, koska suurin osa ongelmista on systeemisiä! Ja jos emme halua etsiä syyllisiä, vaan korjata prosessia, meidän on mitattava prosessi!

Emme rehellisesti sanoen keksineet täällä mitään. DORA (DevOps Tutkimus ja arviointi) edistää jo hyvin käytännöllistä toimitusmittarit: kuinka nopeasti toimitat muutoksen ja kuinka tuskallisia epäonnistumiset ovat, kun muutokset menevät pieleen. Tässä on heidän pikaopas: dora.dev/guides/dora-metrics.

On myös tärkeä huomautus, jonka haluan naulata seinälle kaikille, jotka ovat koskaan halunneet tehdä KPI-mittareita: "älä tee metriikasta tavoitetta"! Koska heti kun sanot "meidän täytyy ottaa käyttöön N kertaa päivässä", osa tiimi alkaa ottaa käyttöön arvoa, vaan numeroa. Tämä on vanha tarina siitä, että kun mittarista tulee tavoite, se lakkaa olemasta indikaattori. DORA viittaa nimenomaisesti Goodhartin lakiin ja kuvaa tyypillisiä sudenkuoppia. Tässä on sivu "neljästä/viidestä avaimesta" yksinkertaisin sanoin: dora.dev/...​s/dora-metrics-four-keys

Ja vielä yksi tärkeä asia, jota DORA yleensä korostaa: konteksti on tärkeä. Nämä mittarit näkyvät parhaiten yhdessä tiimin tai palvelun ja ajan myötä, ei vertaamalla mobiilisovellus keskuskoneella tai pieni tiimi jossa on alusta 200 hengelle.

Jos et ole tekninen tiimi, logiikka on sama. Sijasta "käyttöön" saatat olla "asiakas hyväksynyt tuloksen"; sijasta "tapaus" sinulla voi olla "eskalaatio"; "palautuksen" sijaan "rework". linjauksen jälkeen". Asia on edelleen sama: kuinka nopeasti siirrämme arvoa järjestelmän kautta ja kuinka paljon virhe meille maksaa.

Ja nyt - erittäin tärkeä "älä tee sitä". Älä muunna näitä mittareita yksittäisiksi KPI:iksi! Koska silloin ihmiset eivät ala optimoida tuotetta, vaan numeroa. KPI on "käyttöönotto", ja yhtäkkiä sinulla on käyttöönottoja käyttöönottojen vuoksi. KPI on "sykliaika" ja tehtävät hajoavat järjettömyyteen vain "sulkeakseen ne nopeasti", kun taas kovat osat katoavat hiljaa varjoihin. "Tapahtumien" KPI:t ja tapaukset alkavat nimetä uudelleen nimellä "erikoisuudet" tai "odottamattomat käyttäjäskenaariot".

Ensimmäinen asia, joka auttoi meitä, oli ennustettavuus. Yksinkertainen kysymys: mitä lupasimme suunnittelussa ja mitä todellisuudessa annettiin. Ei häpeästä. Ymmärryksen vuoksi. Koska jos lupaat jatkuvasti 10 ja teet 6, niin ongelma ei ole "laiskoissa". Ongelma on arviossa, prioriteetit, WIP, esto, kontekstin vaihto. Toisin sanoen johtamisessa.

Toinen on toimitusaika. Kuinka kauan tehtävä vie aikaa? matkalla "työhön viety" - "todella toimitettu". Se on hyvin raikastavaa. Koska se usein käy ilmi että "kirjoitamme koodia" nopeasti, mutta "toimitamme" hitaasti. Ja sitten näet, missä pullonkaula on: tarkastelu, testaus, vapautuminen, sovinto, riippuvuudet.

Kolmas on WIP. Jos tiimi on "työssä" samaan aikaan kymmenen ongelmaa kerralla, niin kukaan ei tee mitään. Tarkemmin sanottuna kaikki tekevät kaiken kerralla. Ja sitten ihmetellään, miksi edistyminen tuntuu hidas ja hermostunut. Kun aivot leviävät ohueksi kerrokseksi kymmenen tehtävän aikana se ei muutu tuottavammaksi. Siitä vain tulee väsyneempi.

Toinen asia, joka auttoi meitä ajattelemaan selkeämmin, oli tämä: jos haluat, että työ etenee nopeammin järjestelmän läpi, vastaus on usein olla painostamatta ihmisiä kovemmin. Tarkoituksena on pienentää eräkokoa. Pienemmät muutokset on helpompi tarkistaa, testata, vapauttaa ja peruuttaa. DORA esittää saman asian suoraan: pienemmät erät yleensä parantavat sekä nopeutta että vakautta. Se kuulostaa itsestään selvältä, kunnes joukkue todella yrittää elää sen mukaan kuukauden ajan.

Laatu: lopetimme väittelyn "minusta näyttää" ja aloimme tarkastella seurauksia

"Laadun" arvioiminen kyselylomakkeilla on huono idea. Koska "laatu" Kyselylomakkeessa on usein kyse sympatiasta, tyylistä ja mausta.

Siirryimme seurauksiin.

Kuinka monta vikaa on saavutettu tuotantoon. Kuinka vakavia he olivat? Miten trendi muuttuu?

Kuinka monta tapausta meillä on ollut. Kuinka kauan meillä kesti toipua? Toistuvatko samat syyt?

Kuinka monta versiota. Kuinka monta tehtävää "läpäistiin" ja sitten palautettiin. Koska "valmis" ei ollut valmis.

Et enää kiistellä "kuka on paras". Näet mitä tuotteelle todella tapahtuu.

Intuitiivinen johtopäätös: Miksi ylipäätään arvioida henkilöä?

Mitä kauemmin kaivoimme, sitä useammin törmäsimme oudoon kysymykseen.

Miksi arvioimme ihmistä? Kieltäytyä ylennyksestä? Näytä, kuka "tähti" on? vertailla ihmisiä?

Ja kun puhuimme siitä rehellisesti, se paljastui että suurin osa todellisista tarpeistamme ei liittynyt sijoitukseen ihmiset. Ne kertoivat joukkueen suorituskyvystä: teemmekö mitä lupasimme, onko laatu hyvä, onko työ ennakoitavissa, olemmeko loppuun palamassa ja saako asiakas mitä he odottavat?

Eli systeemistä.

Ja jos on, niin ensimmäinen arviointikohde on tiimi ja prosessi. Eikä ihminen kohteena.

Joukkue on alijäämäinen, joten käymme läpi kokonaisuuden ketju: palkkaaminen, perehdyttäminen, tehtävän määrittely, suunnittelu, tarkistus, testaus, julkaisu, viestintä, riippuvuudet. Tämä on hallinnollista vaikeampaa, kyllä. Mutta se on rehellisempää.

Joskus se näyttää hyvin maanläheiseltä. Esimerkiksi milloin "meillä ei ollut enää aikaa", ensimmäinen kysymys ei ole "kuka hidastaa", ja "minne aika katosi". Koska aika voi kadota ei "työssä", vaan odottamisessa: tehtävät valehtelevat tarkastelussa, testauksessa, sopimuksen mukaan estetty tai niitä on yksinkertaisesti liian monta rinnakkain.

Kun joku kamppailee, tarkistamme ensin

Näemme myös joskus tilanteita, joissa joku "ei vedä". Mutta kyselylomakkeen sijasta teemme yksinkertaisen diagnoosin.

Onko tämä ongelma ollut aina olemassa? Jos näin on, ongelma on todennäköinen palkkaamisessa tai perehdyttämisessä. Siinä tapauksessa korjaat rekrytointiprosessin, ei henkilö, jolla on kyselylomakkeet.

Oliko se ennen normaalia ja sitten huononi? Sitten se voi olla konteksti: burnout, tehtävien muutos, roolien ristiriita, henkilökohtaiset olosuhteet. Tämä on normaalin esimiestyön vyöhyke: Ota selvää mitä tapahtui, vähennä kuormaa, auta henkilöä palautumaan hallitse ja rakenna lyhyt 2–4 viikon palautumissuunnitelma.

Onko henkilöllä selkeä käsitys siitä, mikä menestys miltä lähitulevaisuudessa näyttää? Koska usein ongelma ei ole että henkilö on "heikko". Se on, että laitoimme ne sumuun ja kutsui sitä odotuksiksi.

Ja vielä yksi vivahde, joka meillä oli myös. Jos henkilö epäonnistui useita kertoja, johtaja voi joskus korottaa subjektiivisesti bar: "todista nyt, että et ole epäonnistunut." Se toimii usein alitajunnan tasolla, ja se toimii huonosti tiimille. Yleensä on parempi tehdä päinvastoin: pienennä laajuutta, pienennä tehtäviä, poista melu, anna henkilölle mahdollisuus tehdä jatkuvasti muutamia asioita hyvin ja saada itseluottamus takaisin. Tämä on vaikea tehtävä johtajat. Ja juuri siksi katsomme hyvin tarkasti palkkaamiemme esimiesten luona.

Johtopäätökset

Tietysti 360 voi toimia. Suurissa yrityksissä, joissa nimettömyys on todella mahdollista.

Kun tiimillä on jo suoran palautteen kulttuuri, ja 360 on lisäsignaali, ei pääsignaali "totuus".

Meillä ei ollut sitä. Meillä oli pieniä tiimejä, nopea tahti ja korkeat epäluottamuskustannukset.

360 näytti aikuiselta työkalulta paperilla. Meidän todellisuus, siitä on tullut mekanismi, joka kerää pelon yhteen paikkaan, arvailua, kilpailua ja "kollektiivista arvostelua".

Katkaisimme 360 ​​ja palasimme perusasioihin: yksinkertaiset tiimimittarit, avoimet keskustelut ja läpinäkyvät tilat.

Materiaalit ja linkit (jos haluat kaivaa syvemmälle)

DORA — software delivery performance metrics. Perusteltu selitys viidestä mittarista ja ansoista, joihin tiimit joutuvat, kun he käyttävät niitä väärin.

DORA — DORA’s software delivery performance metrics. Lyhyt versio, jossa on historiallinen "miksi neljä/viisi" ja varoitus peleistä mittareilla.

DORA Research: 2024 — DORA Report. Koko raportti (lataa PDF eri kielillä).

Smither, London (2005) — meta-analysis on multisource feedback. Miksi sinun ei pitäisi odottaa maagista vaikutusta yhdeltä 360 asteen aallolta.

CIPD — Performance feedback: an evidence review (PDF). Siitä, miten palaute toimii/ei toimi ja miksi "arvioinnin" sekoittaminen "kehitykseen" on usein haitallista.

CCL — 360 Degree Assessment & Feedback: Best Practices Guidelines. Jos teet silti 360:n, on jotain mietittävää ennen lähtöä, ei tulipalon jälkeen.

CCL — SBI feedback model. Hyvin yksinkertainen kehys "ei pikanäppäimiä" -palautteelle.

Google SRE — Postmortem Culture: Learning from Failure. Syyttömistä kuolemanjälkeisistä tapahtumista ja siitä, miksi kulttuurin häpeäminen tappaa oppimisen.

Amy Edmondson (1999) — Psychological Safety (PDF). Ensisijainen lähde psykologisesta turvallisuudesta joukkueissa.

WEF — Feedforward technique. Siitä, kuinka palautetta siirretään suuntaan "mitä teemme seuraavaksi" eikä "mitä tapahtui eilen".

Goodhart’s law. Yksi hyödyllisimmistä "anti-teorioista" kaikille, jotka haluavat tehdä KPI-mittareita.

Kysymyksiä yhteisölle

Mitä yhteisö ajattelee 360:sta? Käytätkö sitä? Millainen kokemuksesi on ollut?

Kuinka ratkaiset "anonymiteetin" ongelman, kun joukkue on pieni ja kaikki ymmärtävät kaiken?

Ja mitkä toimitus-/laatumittarit todella auttavat sinua hallitsemaan prosessia kauniiden raporttien laatimisen sijaan?

Kiitos ajastasi ja huomiostasi.