Vedo molti OKR (obiettivi e risultati chiave) negativi. Di solito sono solo KPI (Key Performance Indicators) a cui viene dato il nome OKR. Li conosci perché tendono ad essere qualcosa di simile

Obiettivo: consegnare il prodotto x

Risultato chiave: il prodotto x è in produzione

Obiettivo: incentivare l'adozione del prodotto y

Risultato chiave: 5 team inseriti nel prodotto y

In questo post, ho deciso di scrivere la mia definizione di come deve essere un buon OKR. Il mio pensiero si è evoluto da quello che ho imparato per la prima volta molto tempo fa in discorsi, post di blog e libri che ricordavo a metà, e ora si basa sulla mia esperienza nell'usarli per fissare obiettivi di squadra negli ultimi dieci anni circa.

Obiettivi

L' obiettivo è di natura narrativa ed esprime il focus strategico e l'opinione sul raggiungimento di quel risultato, non solo il risultato generale che stai cercando.

Ad esempio, mi sono spesso trovato nel ruolo di dirigere team che fanno parte di uno sforzo di migrazione al cloud pubblico. Per un'azienda di qualsiasi dimensione/complessità, una migrazione al cloud pubblico è un'iniziativa pluriennale. Quindi, mentre potrei avere un obiettivo sempreverde: "spostare l'azienda nel cloud" o "accelerare l'adozione del cloud" o altro, di solito non mi pongo un obiettivo così ampio.

Invece, guardo a questi potenziali lavori che pensiamo di dover fare, ai problemi che stiamo riscontrando con l'accesso al cloud e cerco di identificare il prossimo pezzo chiave della strategia su cui dobbiamo concentrarci. Ad esempio, un anno l'obiettivo era qualcosa del tipo:

Rendi (nome dell'azienda) pronto per il cloud

Questo obiettivo era ampio e comprendeva il lavoro che riguardava direttamente l'abilitazione e l'utilizzo del cloud pubblico, ma copriva anche il lavoro che ha spinto le nostre applicazioni a essere più native del cloud tramite la containerizzazione e altri miglioramenti sottostanti, indipendentemente dal fatto che stessero migrando al cloud in quel momento o no. Questo obiettivo ha espresso l'opinione che, indipendentemente dal fatto che avremmo spostato tutto nel cloud pubblico o meno, le pratiche sottostanti necessarie se si desidera avere un'architettura e operazioni "cloud native" sono importanti da portare avanti.

Ho un'eccezione alla scrittura di obiettivi che esprimono un'opinione, e cioè quando ho un obiettivo che esprime un valore sempreverde e un'area di interesse. Per me, questa è sempre "eccellenza operativa". Ogni anno stabilisco un OKR di eccellenza operativa che contrassegna i progetti critici necessari per affrontare problemi come, ad esempio, la migrazione di Python 3, la riduzione della fatica nei sistemi critici o altre importanti aree incentrate sull'operabilità e sull'affidabilità. Lo faccio perché voglio sottolineare che questo lavoro è importante per me quanto altre iniziative chiave, e inoltre mi aspetto che tutti i miei team si concentrino su questo, indipendentemente da cos'altro stanno facendo.

Risultati chiave

Gli obiettivi esprimono una strategia di alto livello con una sorta di opinione o dichiarazione di valori. I risultati chiave forniscono segnali aggregati e misure di come prevedi di vedere l'impatto o il progresso verso il raggiungimento di tale obiettivo.

La tentazione con i risultati chiave è di farli più sul lavoro svolto che sull'impatto. Se i tuoi risultati chiave riguardano tutti i sistemi di spedizione, la conclusione di progetti o il raggiungimento di traguardi di consegna, in realtà stai solo misurando se stai facendo o meno ciò che avevi stimato di poter fare. E non è male, esattamente, ma ha due lati negativi.

Il primo aspetto negativo è che non consente molta flessibilità nel modo in cui raggiungi il tuo obiettivo, e questo è piuttosto limitante! Una delle frustrazioni che gli ingegneri hanno con la pianificazione è che può essere molto rigida. Quando parli di un processo annuale di creazione di ampi OKR, stai cercando non solo di prevedere cosa farai durante l'anno, ma quali sono i progetti importanti da portare a termine. Se le circostanze cambiano e si scopre che non è necessario trasferire tutti a EKS, ma è invece necessario trasferire un gruppo di persone a ECS, ad esempio, il tuo KR di "migrazione di 100 app a EKS" diventa immediatamente rosso e devi riscriverlo a favore di altrettanto rigido "sposta 50 app su EKS e 50 app su ECS". Ove possibile, credo che sia meglio scrivere KR che consentano flessibilità nel modo in cuivengono raggiunti durante tutto l'anno.

Questo ci porta al secondo aspetto negativo dei KR dell'output di lavoro: non tengono conto dell'impatto. Questo è un particolare punto cieco dei team di ingegneri di tipo piattaforma, che si concentrano sulla costruzione e la consegna di una cosa che pensano di dover costruire e consegnare senza fermarsi a chiedere se è la cosa più utile per aiutare i propri utenti a raggiungere i loro obiettivi. Quando scrivi KR che riguardano l'impatto (riduci il tempo per l'onboarding di una nuova applicazione cloud da 2 settimane a 2 giorni (o, del 50%, o...)), costringi le persone a confrontarsi con la domanda: come funzionerà il mio lavoro impatto?

In realtà c'è un terzo svantaggio nel lavorare con i KR di output, uno che emerge di più quando gestisci organizzazioni più grandi. La mia regola personale sugli OKR è: non più di 5 obiettivi, ciascuno con non più di 4-5 KR. Per qualunque sia l'unità di supervisione più coerente che hai, cerca di attenerti a questo, indipendentemente dal fatto che il tuo team sia composto da 50 o 500 persone. Quando stai cercando di rappresentare un ampio portafoglio di lavoro in molti team diversi, non hai spazio da sprecare un KR su qualcosa di meno di un'iniziativa importante e il risultato del lavoro KR può essere uno spreco di un prezioso posto KR.

Avrai dei KR di output di lavoro, è inevitabile. Ci sono cose che devono essere fatte e il lavoro per farle è abbastanza difficile da volerlo misurare come un progresso di cui riferire. Ma non essere pigro! Esamina ogni singolo output di lavoro KR e chiediti davvero se esiste un modo migliore per misurarlo basato più sull'impatto che sulla pura consegna.

Tutto questo è difficile

Questo torna al mio punto iniziale: gli OKR sono difficili. Devi avere un'opinione strategica per scrivere buoni obiettivi e devi avere alcune buone idee su ciò che vogliono i tuoi clienti, cosa potrebbe offrire il tuo team e cosa potresti essere in grado di misurare per creare buoni KR. Devi comprendere potenzialmente una vasta gamma di team e progetti per creare OKR che siano sia stimolanti che aggressivi ma non impossibili.

E poi, ovviamente, ci sono tutti i casi eccezionali che ti tentano. Ho un taglio per l'eccellenza operativa e, una volta che inizi da lì, si è tentati di aggiungere sempre più tagli. Dovremmo sempre avere un OKR per la cultura del team / le assunzioni / lo sviluppo dei talenti. Non possiamo tralasciare di riconoscere la funzione X, quindi dobbiamo creare qualcosa di speciale per quel gruppo. Non posso dire che il mio modello di 4-5 Os ciascuno con 4-5 KR superi davvero le centinaia o con ogni tipo di attività. E probabilmente ci sono team che in realtà non hanno bisogno di OKR, a causa della natura del loro lavoro, del controllo su come vengono misurati, delle loro dimensioni o altro.

Questa è la caduta degli OKR. Sono difficili, ma venduti come qualcosa che tutti dovrebbero fare, quindi tutti li fanno male e la maggior parte delle persone non vede alcun valore come risultato. Non devi fare OKR (a meno che tu non lavori per me, nel qual caso potresti). Se non hai almeno intenzione di impegnarti per scriverne di buoni, non dovresti farli! Ma se fai il lavoro, ti costringeranno a pensare in modo più strategico ai tuoi obiettivi e a porre domande difficili su quale sia l'impatto che speri di ottenere con loro e su come lo misurerai. I buoni OKR raccontano una storia su ciò che è importante, ti aiutano a ispirare le persone a pensare al motivo per cui stanno lavorando su ciò su cui stanno lavorando, e penso che portino un po' di energia che deriva dal vedere come tutto combacia in un forma succinta.