Los OKRs que escribimos en enero
En enero de cada año pasa lo mismo en muchos equipos de diseño. El manager llega al kick-off con energía, propone arrancar con OKRs, el equipo lo ve bien, pasan dos horas escribiendo Objectives y Key Results en un Notion o en una hoja de cálculo y se van con la sensación de haber hecho algo importante.
A finales de marzo, nadie sabe decir cuál es el estado de los OKRs del trimestre. No porque el equipo sea descuidado. Sino porque los OKRs que escribieron en enero no eran OKRs. Eran tareas con nombre más largo.
He visto esto repetirse en equipos de 4 y en equipos de 40. El problema no es la metodología. El problema es que muy pocas personas enseñan cómo escribir OKRs que realmente funcionen en un equipo de diseño.
Por qué los OKRs de diseño fallan casi siempre
Hay tres errores que se repiten de forma casi universal:
Demasiados Objectives. Un equipo que tiene siete Objectives en un trimestre no tiene Objectives: tiene una lista de cosas que quiere hacer. El foco es la condición necesaria para que un OKR funcione. Más de tres Objectives y el sistema colapsa.
Key Results que son tareas, no resultados. "Crear el design system" no es un Key Result. "Conseguir que el 80% de los componentes nuevos usen tokens del design system" sí lo es. La diferencia es que lo segundo se puede medir y lo primero no. Un Key Result que no tiene un número no es un Key Result.
Nadie tiene ownership. Cuando un KR no tiene responsable, es responsabilidad de todos, que es exactamente lo mismo que no tener responsable. Cada Key Result necesita una persona que sepa que ese número es su problema.
Cómo escribir OKRs que sobrevivan a febrero
La receta no es complicada pero requiere disciplina.
Máximo tres Objectives por trimestre. Si tienes más de tres cosas que son igual de importantes, tienes un problema de priorización, no de OKRs. Resuélvelo antes.
Cada Objective necesita entre dos y tres Key Results. No más. Un KR que no puedes medir cada dos semanas no es un buen KR. Si no tienes datos para medirlo, necesitas crear el sistema de medición antes de comprometerte con el resultado.
El score es lo que mantiene el sistema vivo. Un score de 0.0 a 1.0 por cada KR, actualizado cada dos semanas. Por encima de 0.7 es buen camino. Entre 0.3 y 0.7, en progreso. Por debajo de 0.3, necesita atención. No es un examen. Es un sistema de alerta temprana.
¿Sabes lo que pasa cuando actualizas los scores cada dos semanas? Que los problemas salen a la superficie antes de que sea demasiado tarde para hacer algo al respecto.
El OKR Builder
Para resolver el problema de la herramienta construí el OKR Builder, una app donde defines los Objectives del trimestre, añades los Key Results con responsable y score, y el sistema te muestra el estado de salud de cada Objective con un indicador visual.
Sin base de datos, sin cuenta. Todo se guarda en tu navegador. Cuando lo tienes completo, exportas a Markdown para compartirlo en el canal del equipo o pegarlo en Notion.
El límite de tres Objectives está en la app por diseño. No por capricho: porque si la herramienta no te pone freno, la tendencia es siempre añadir más.
La revisión que cambia el sistema
Los OKRs no son un documento de enero. Son una conversación que ocurre cada dos semanas.
El equipo que los hace funcionar no es el que los escribe mejor en el kick-off. Es el que tiene una cita en el calendario cada dos semanas para revisar el score, hablar de lo que está bloqueando el avance y tomar decisiones.
La mayoría de equipos se saltan esa revisión porque no hay tiempo. Y después se preguntan por qué los OKRs no funcionaron.
Pues eso.