Veo muchos OKR (objetivos y resultados clave) malos. Por lo general, son solo KPI (indicadores clave de rendimiento) con el nombre de OKR. Los conoces porque tienden a ser algo así como

Objetivo: entregar producto x

Resultado clave: el producto x está en producción

Objetivo: impulsar la adopción del producto y

Resultado clave: 5 equipos incorporados al producto y

En esta publicación, decidí escribir mi definición de cómo es un buen OKR. Mi forma de pensar ha evolucionado a partir de lo que aprendí por primera vez hace mucho tiempo en charlas, publicaciones de blog y libros que recordaba a medias, y ahora se basa en mi experiencia usándolos para establecer objetivos de equipo durante los últimos diez años más o menos.

Objetivos

El objetivo es de naturaleza narrativa y expresa el enfoque estratégico y la opinión sobre el logro de ese resultado, no solo el resultado general que está buscando.

Por ejemplo, a menudo me he encontrado en el rol de dirigir equipos que son parte de un esfuerzo de migración a la nube pública. Para una empresa de cualquier tamaño o complejidad, la migración a la nube pública es una iniciativa de varios años. Entonces, aunque podría tener un objetivo perenne: "trasladar la empresa a la nube" o "acelerar la adopción de la nube" o lo que sea, no suelo establecer un objetivo tan amplio.

En cambio, miro este trabajo potencial que creemos que debemos hacer, los problemas que estamos viendo para llegar a la nube, y trato de identificar la siguiente pieza clave de la estrategia en la que debemos centrarnos. Por ejemplo, un año el objetivo era algo como:

Haga que (nombre de la empresa) esté listo para la nube

Este objetivo era amplio y abarcaba el trabajo que se relacionaba directamente con la habilitación y el uso de la nube pública, pero también abarcaba el trabajo que impulsaba a nuestras aplicaciones a ser más nativas de la nube a través de la creación de contenedores y otras mejoras subyacentes, ya sea que estuvieran migrando a la nube en ese momento. O no. Este objetivo expresó la opinión de que, ya sea que vayamos a mover todo a la nube pública o no, las prácticas subyacentes que se necesitan si desea tener una arquitectura y operaciones "nativas de la nube" son importantes para impulsar.

Tengo una excepción a la hora de escribir objetivos que expresan una opinión, y es cuando tengo un objetivo que expresa un valor permanente y un área de enfoque. Para mí, eso siempre es “excelencia operativa”. Todos los años establezco un OKR de excelencia operativa que etiqueta proyectos críticos que se necesitan para abordar problemas como, por ejemplo, la migración de Python 3, la reducción del trabajo en sistemas críticos u otras áreas importantes centradas en la operabilidad y la confiabilidad. Hago esto porque quiero resaltar que este trabajo es tan importante para mí como otras iniciativas clave y, además, espero que todos mis equipos se centren en esto sin importar qué más estén haciendo.

Resultados clave

Los objetivos expresan una estrategia de alto nivel con algún tipo de opinión o declaración de valores. Los resultados clave brindan señales y medidas agregadas de cómo espera ver el impacto o el progreso hacia el logro de ese objetivo.

La tentación con los resultados clave es hacerlos más sobre el trabajo realizado que sobre el impacto. Si sus resultados clave tienen que ver con los sistemas de envío, la terminación de proyectos o el logro de hitos de entrega, en realidad solo está midiendo si está logrando o no lo que estimó que podría lograr. Y eso no está mal, exactamente, pero tiene dos inconvenientes.

El primer inconveniente es que no permite mucha flexibilidad en la forma de lograr su objetivo, ¡y esto es bastante limitante! Una de las frustraciones que tienen los ingenieros con la planificación es que puede ser muy rígida. Cuando se habla de un proceso anual de elaboración de OKR amplios, se intenta no solo predecir lo que se hará en el año, sino también qué proyectos son los más importantes. Si las circunstancias cambian y resulta que no necesita mover a todos a EKS, sino que necesita mover a un grupo de personas a ECS, por ejemplo, su KR de "migrar 100 aplicaciones a EKS" se vuelve inmediatamente rojo y tiene que reescribirlo a favor de "mover 50 aplicaciones a EKS y 50 aplicaciones a ECS" igualmente rígido. Siempre que sea posible, creo que es mejor escribir KR que permitan flexibilidad en cómose consiguen durante todo el año.

Esto nos lleva al segundo inconveniente de los KR de producción de trabajo: no tienen en cuenta el impacto. Este es un punto ciego particular de los equipos de ingeniería de tipo plataforma, que se enfocan en construir y entregar algo que creen que deberían construir y entregar sin detenerse a preguntar si es lo más útil para ayudar a sus usuarios a lograr sus objetivos. Cuando escribe KR que tienen que ver con el impacto (reducir el tiempo para incorporar una nueva aplicación en la nube de 2 semanas a 2 días (o, en un 50 %, o...)), obliga a las personas a lidiar con la pregunta: ¿cómo se entregará mi trabajo? ¿impacto?

En realidad, hay un tercer inconveniente en los KR de producción de trabajo, uno que surge más cuando se ejecutan organizaciones más grandes. Mi regla personal de los OKR es: no más de 5 objetivos, cada uno con no más de 4 o 5 KR. Cualquiera que sea la unidad de supervisión más coherente que tenga, intente ceñirse a ella, ya sea que su equipo sea de 50 o 500. Cuando intenta representar una gran cartera de trabajo en muchos equipos diversos, no tiene espacio para desperdiciar un KR en cualquier cosa que no sea una iniciativa importante, y los KR de resultados de trabajo pueden ser un desperdicio de un valioso lugar de KR.

Vas a tener algunos KR de salida de trabajo, es inevitable. Hay cosas que simplemente se tienen que hacer, y el trabajo de hacerlas es lo suficientemente difícil como para querer medirlo como un progreso sobre el cual informar. ¡Pero no seas perezoso! Examine cada KR de salida de trabajo y realmente pregúntese si hay una mejor manera de medir esto que se base más en el impacto que en la entrega pura.

todo esto es dificil

Esto vuelve a mi punto inicial: los OKR son difíciles. Debe tener una opinión estratégica para escribir buenos objetivos, y debe tener algunas buenas ideas de lo que quieren sus clientes, lo que su equipo podría ofrecer y lo que podría medir para crear buenos KR. Tienes que comprender potencialmente una colección muy grande de equipos y proyectos para crear OKR que sean a la vez inspiradores y agresivos, pero no imposibles.

Y luego, por supuesto, están todos los casos de excepción que te tientan. Tengo una excepción para la excelencia operativa, y una vez que comienzas allí, es tentador agregar más y más excepciones. Siempre debemos tener un OKR para la cultura del equipo, la contratación y el desarrollo de talentos. No podemos dejar de reconocer la función X, por lo que debemos crear algo especial para ese grupo. No puedo decir que mi modelo de 4–5 Os, cada uno con 4–5 KR, realmente supere unos pocos cientos, o con todo tipo de negocio. Y probablemente haya equipos que realmente no necesiten OKR, debido a la naturaleza de su trabajo, el control sobre cómo se miden, su tamaño o lo que sea.

Esta es la caída de los OKR. Son difíciles, pero se venden como algo que todos deberían hacer, por lo que todos los hacen mal y la mayoría de las personas no ven ningún valor como resultado. No tienes que hacer OKR (a menos que trabajes para mí, en cuyo caso, podrías hacerlo). Si al menos no vas a intentar esforzarte para escribir buenos, ¡no deberías hacerlo! Pero si hace el trabajo, lo obligarán a pensar de manera más estratégica sobre sus objetivos y a hacer preguntas difíciles sobre cuál es el impacto que espera lograr con ellos y cómo lo medirá. Los buenos OKR cuentan una historia sobre lo que es importante, te ayudan a inspirar a las personas a pensar por qué están trabajando en lo que están trabajando, y creo que transmiten un poco de energía que proviene de ver cómo encaja todo en un forma sucinta.