Vejo muitos OKRs (objetivos e resultados-chave) ruins. Normalmente, eles são apenas KPIs (Key Performance Indicators) com o nome de OKR. Você os conhece porque eles tendem a ser algo como

Objetivo: entregar produto x

Resultado chave: o produto x está em produção

Objetivo: impulsionar a adoção do produto y

Resultado-chave: 5 equipes integradas ao produto y

Neste post, decidi escrever minha definição de como é um bom OKR. Meu pensamento evoluiu a partir do que aprendi há muito tempo em palestras, postagens de blog e livros mal lembrados, e agora se baseia em minha experiência de usá-los para definir metas de equipe nos últimos dez anos.

Objetivos

O objetivo é de natureza narrativa e expressa o foco estratégico e a opinião sobre como alcançar esse resultado, não apenas o resultado geral que você está buscando.

Por exemplo, muitas vezes me encontrei na função de administrar equipes que fazem parte de um esforço de migração para a nuvem pública. Para uma empresa de qualquer tamanho/complexidade, uma migração para a nuvem pública é uma iniciativa de vários anos. Portanto, embora eu possa ter um objetivo permanente: “mover a empresa para a nuvem” ou “acelerar a adoção da nuvem” ou o que quer que seja, geralmente não defino um objetivo tão amplo.

Em vez disso, analiso esse trabalho potencial que achamos que precisamos fazer, os problemas que estamos vendo ao chegar à nuvem e tento identificar a próxima peça-chave da estratégia na qual precisamos nos concentrar. Por exemplo, um ano o objetivo era algo como:

Tornar (nome da empresa) pronto para a nuvem

Esse objetivo era amplo e abrangia o trabalho que tratava diretamente da habilitação e do uso da nuvem pública, mas também abrangia o trabalho que impulsionava nossos aplicativos a serem mais nativos da nuvem por meio da conteinerização e outras melhorias subjacentes, quer estivessem migrando para a nuvem naquele momento ou não. Este objetivo expressava a opinião de que, se iríamos mover tudo para a nuvem pública ou não, as práticas subjacentes necessárias se você deseja ter uma arquitetura e operações “nativas da nuvem” são importantes para impulsionar.

Tenho uma exceção para escrever objetivos que expressam uma opinião, e é quando tenho um objetivo que expressa um valor perene e uma área de foco. Para mim, isso é sempre “excelência operacional”. Todos os anos, defino um OKR de excelência operacional que marca projetos críticos necessários para abordar questões como, digamos, migração do Python 3, redução de trabalho em sistemas críticos ou outras áreas importantes de operabilidade e confiabilidade. Faço isso porque quero destacar que esse trabalho é tão importante para mim quanto outras iniciativas importantes e, além disso, espero que todas as minhas equipes tenham algum foco nisso, não importa o que mais estejam fazendo.

Principais resultados

Os objetivos expressam uma estratégia de alto nível com algum tipo de opinião ou declaração de valores. Os principais resultados fornecem sinais e medidas agregadas de como você espera ver o impacto ou o progresso para atingir esse objetivo.

A tentação com os principais resultados é torná-los mais relacionados ao trabalho executado do que ao impacto. Se seus principais resultados são sobre sistemas de envio, finalização de projetos ou cumprimento de marcos de entrega, você está apenas medindo se está ou não fazendo o que estima que poderia fazer. E isso não é exatamente ruim, mas tem duas desvantagens.

A primeira desvantagem é que não permite muita flexibilidade na forma como você atinge seu objetivo, e isso é bastante limitante! Uma das frustrações que os engenheiros têm com o planejamento é que ele pode ser muito rígido. Quando você está falando sobre um processo anual de elaboração de OKRs amplos, está tentando não apenas prever o que será feito no ano, mas quais projetos são os mais importantes a serem concluídos. Se as circunstâncias mudarem e você não precisar mover todos para o EKS, mas, em vez disso, precisar mover um grupo de pessoas para o ECS, por exemplo, seu KR de “migrar 100 aplicativos para o EKS” ficará imediatamente vermelho e você tem que reescrevê-lo em favor de “mover 50 aplicativos para EKS e 50 aplicativos para ECS” igualmente rígidos. Sempre que possível, acredito que seja melhor escrever KRs que permitam flexibilidade em comoeles são alcançados ao longo do ano.

Isso nos leva à segunda desvantagem dos KRs de resultados de trabalho: eles não levam em conta o impacto. Este é um ponto cego particular das equipes de engenharia do tipo plataforma, que se concentram em construir e entregar algo que acham que devem construir e entregar sem parar para perguntar se é a coisa mais útil para ajudar seus usuários a atingir seus objetivos. Quando você escreve KRs sobre impacto (reduz o tempo de integração de um novo aplicativo de nuvem de 2 semanas para 2 dias (ou, em 50%, ou…)), você força as pessoas a enfrentar a pergunta: como meu trabalho será entregue impacto?

Na verdade, há uma terceira desvantagem nos KRs de saída de trabalho, que aparece mais quando você administra organizações maiores. Minha regra pessoal de OKRs é: não mais que 5 objetivos, cada um com não mais que 4–5 KRs. Seja qual for a unidade de supervisão mais coerente que você tiver, tente se ater a isso, seja sua equipe de 50 ou 500. Quando você está tentando representar um grande portfólio de trabalho em muitas equipes diversas, não há espaço a perder um KR em qualquer coisa menos do que uma grande iniciativa, e os KRs de saída de trabalho podem ser um desperdício de um valioso ponto KR.

Você vai ter alguns KRs de saída de trabalho, é inevitável. Há coisas que simplesmente precisam ser feitas, e o trabalho de fazê-las é difícil o suficiente para que você queira medir isso como um progresso a ser relatado. Mas não seja preguiçoso! Examine cada KR de saída de trabalho e realmente pergunte a si mesmo se existe uma maneira melhor de medir isso com base mais no impacto do que na entrega pura.

tudo isso é difícil

Isso volta ao meu ponto inicial: OKRs são difíceis. Você precisa ter uma opinião estratégica para escrever bons objetivos e algumas boas ideias sobre o que seus clientes desejam, o que sua equipe pode oferecer e o que você pode medir para criar bons KRs. Você tem que entender potencialmente uma coleção muito grande de equipes e projetos para criar OKRs que sejam inspiradores e agressivos, mas não impossíveis.

E então, é claro, existem todos os casos de exceção que o tentam. Eu tenho uma divisão pela excelência operacional e, uma vez que você começa lá, é tentador adicionar mais e mais divisões. Devemos sempre ter um OKR para cultura/contratação/desenvolvimento de talentos da equipe. Não podemos deixar de reconhecer a função X, então precisamos criar algo especial para aquele grupo. Não posso dizer que meu modelo de 4–5 Os, cada um com 4–5 KRs, realmente ultrapasse algumas centenas ou com todos os tipos de negócios. E provavelmente existem equipes que realmente não precisam de OKRs, devido à natureza de seu trabalho, ao controle sobre como são medidos, seu tamanho ou qualquer outra coisa.

Esta é a queda dos OKRs. Eles são difíceis, mas vendidos como algo que todos deveriam fazer, então todos os fazem mal e a maioria das pessoas não vê nenhum valor como resultado. Você não precisa fazer OKRs (a menos que trabalhe para mim, caso em que você pode). Se você não vai pelo menos tentar se esforçar para escrever bons, não deveria fazê-los! Mas se você fizer o trabalho, eles irão forçá-lo a pensar mais estrategicamente sobre seus objetivos e fazer perguntas difíceis sobre qual é o impacto que você espera alcançar com eles e como você medirá isso. Bons OKRs contam uma história sobre o que é importante, eles ajudam você a inspirar as pessoas a pensar sobre por que estão trabalhando no que estão trabalhando e acho que carregam um pouco da energia que vem de ver como tudo se encaixa em um forma sucinta.