Martes. 08:47. Llego pronto. Café en mano. Silencio en la oficina. Ese momento raro en el que puedes pensar sin que nadie te interrumpa con una urgencia que lleva tres semanas siendo urgente.
Abro el portátil. Reviso roadmap, le pregunto a BorjIA que me diga que valor entregaron los equipos ayer. Y entonces me doy cuenta de algo que llevo ignorando semanas: el equipo está remando, pero nadie sabe hacia dónde.
No es culpa suya. Es culpa mía. Hay demasiados frentes abiertos, demasiadas prioridades que compiten entre sí, y el contexto estratégico se ha ido diluyendo entre Slacks, dailies y "luego lo hablamos".
Así que hago algo que normalmente evito: voy a buscar a Manolo.
—Manolo, tengo una idea.
Me mira como quien ve a un vegano pidiendo chuletón.
—¿Tú? ¿Una idea de gestión? ¿A mí?
—Sí. OKRs.
—¿OKRs?
—Objectives and Key Results. Es un framework de alineamiento. Lo popularizó John Doerr cuando se lo llevó de Intel a Google. Escribió Measure What Matters. La idea es simple: defines un objetivo ambicioso y cualitativo, y luego defines dos o tres resultados clave que te dicen si vas por buen camino.
Manolo saca el cuaderno. El bolígrafo caro. La mirada de "por fin Jose habla mi idioma".
—Me gusta. Estructura. Medición. Foco.
—Sí, pero escucha bien: el objetivo NO es una tarea. Y el resultado clave NO es un entregable. Es un cambio medible en el mundo real.
—Claro, claro.
No ha entendido nada. Lo sé porque asiente demasiado rápido. Manolo asiente rápido cuando ya está pensando en su versión, no en la tuya.
—Mira, te pongo un ejemplo. Objetivo: "Convertirnos en la referencia de experiencia de usuario en nuestro vertical." Key Result 1: "Reducir el tiempo medio de onboarding de 12 minutos a 4." Key Result 2: "Alcanzar un NPS de 55 en el segmento enterprise."
—Bien, bien. ¿Y las tareas?
—Las tareas las decide el equipo. Esa es la gracia. Tú defines el destino, no el camino.
Pausa. Manolo parpadea. Como si le acabara de decir que la tierra es redonda y él llevara años vendiendo mapas planos.
—Jose, pero si no definimos las tareas… ¿cómo sabemos que trabajan?
—Porque verás si los Key Results se mueven.
—Ya, pero yo necesito ver actividad.
—No, Manolo. Necesitas ver progreso. Y no son lo mismo.
Se va. Contento. Demasiado contento. Ese tipo de contento que precede a un desastre organizativo.
Lunes siguiente. Manolo me manda un documento. Asunto: "OKRs Q2 — Borrador v1 DEFINITIVO".
Lo abro.
Y ahí está. La obra. El crimen.
Objetivo 1: "Mejorar la plataforma."
Key Results:
Cerrar 45 tickets de Jira antes del 30 de abril. Hacer deploy cada jueves. * Reducir bugs abiertos a menos de 20.
Objetivo 2: "Ser más eficientes."
Key Results:
Que todo el mundo registre horas en Harvest. Hacer retrospectivas cada dos semanas. * Reducir reuniones un 15%.
Respiro. Cuento hasta diez. No llego a cinco.
Le llamo.
—Manolo.
—¿Has visto? Los tengo listos. He trabajado el finde.
—Ya lo veo. Y es exactamente lo que te dije que NO hicieras.
—¿Qué?
—Esto no son OKRs. Esto es una lista de tareas disfrazada con un título bonito.
Silencio.
—"Mejorar la plataforma" no es un objetivo, Manolo. Es un deseo. Como "ser feliz" o "comer sano". No tiene dirección, no tiene ambición, no tiene alma.
—Pero es claro.
—Es vacío. Un buen objetivo te tiene que doler un poco. Te tiene que obligar a elegir. Christina Wodtke lo explica muy bien en Radical Focus: si tu objetivo no te da un poco de vértigo, probablemente no es un objetivo, es mantenimiento.
—Vale, ¿y los Key Results?
—Cerrar 45 tickets no es un resultado. Es output. Es movimiento. Un equipo puede cerrar 200 tickets y no haber movido la aguja ni un milímetro. ¿Recuerdas la ley de Goodhart?
—No me hables otra vez de Goodhart.
—Pues deja de invocarle.
Le explico lo que debería saber si hubiera leído más allá del índice del libro de Doerr:
Los Key Results tienen que ser outcomes, no outputs. No mides lo que haces, mides lo que cambia gracias a lo que haces. "Cerrar tickets" es output. "Reducir el tiempo medio de resolución de incidencias críticas de 48 a 12 horas" es outcome. "Hacer deploy cada jueves" es una práctica. "Pasar de un cycle time de 14 días a 5" es un resultado.
—Pero eso es más difícil de medir.
—Exacto, Manolo. Y por eso vale la pena.
Andy Grove, que básicamente inventó los OKRs en Intel antes de que nadie los llamara así, tenía una idea muy clara: el sistema existe para generar foco y alineamiento, no para controlar a la gente. Si tus OKRs se parecen a un parte de trabajo, has fallado antes de empezar.
—Es que el equipo necesita saber qué hacer.
—No, Manolo. El equipo necesita saber qué lograr. El "qué hacer" lo descubren ellos. Eso es autonomía. Eso es lo que diferencia a un equipo senior de una cadena de montaje.
—Eso es muy bonito, Jose, pero aquí la gente necesita que le digas las cosas claras.
—Las cosas claras son: "Queremos que el 80% de los usuarios completen el flujo de compra sin contactar a soporte." Eso es claro. "Cerrar 45 tickets" es ruido con formato.
Manolo se remueve. Mira el documento como quien mira un castillo de arena justo antes de la ola.
—¿Y lo de registrar horas en Harvest como Key Result?
—Manolo, eso no es un resultado clave. Eso es una política interna. Es como poner "llegar puntual" como objetivo estratégico de la empresa.
—Pues hay gente que no llega puntual.
—Y hay empresas que confunden disciplina con estrategia. No seas una de ellas.
Le hablo de Marty Cagan, de Empowered. Cagan distingue entre "feature teams" y "empowered teams". Los primeros reciben listas de lo que tienen que construir. Los segundos reciben problemas que tienen que resolver. Los OKRs, bien hechos, son la herramienta de los segundos. Mal hechos — como los de Manolo — son el disfraz favorito de los primeros.
—Entonces estás diciendo que mis OKRs son de feature team.
—Estoy diciendo que tus OKRs son un Microsoft Project con pretensiones.
Golpe bajo. Lo sé. Pero Manolo solo reacciona con golpes bajos.
Se queda callado un rato.
—Jose… es que cada vez que intento poner orden, me dices que lo estoy haciendo mal.
—No. Te digo que confundes orden con control. Orden es dar claridad sobre lo que importa. Control es decidir cómo tiene que hacerlo cada persona. Lo primero genera alineamiento. Lo segundo genera obediencia. Y la obediencia, en trabajo de conocimiento, es el preludio de la mediocridad.
Lo dijo Peter Drucker hace décadas: "La productividad del trabajador del conocimiento es el mayor desafío del siglo XXI." Y luego añadió algo que Manolo debería tatuarse: la clave no es supervisar más, sino definir mejor qué constituye un resultado.
Manolo cierra el portátil. Despacio. Con esa cara de "me has arruinado el lunes pero no te voy a dar la satisfacción de admitirlo".
—Entonces rehago los OKRs.
—Sí. Pero esta vez hazlos CON el equipo. No PARA el equipo. Los OKRs impuestos desde arriba sin contexto ni participación se convierten en lo que ya tienes: un checklist con ambiciones corporativas.
—¿Y si el equipo propone cosas que no me convencen?
—Entonces negocia. Eso es liderar. No es poner deberes.
Se levanta. Recoge el cuaderno. El bolígrafo caro se queda en la mesa, como una bandera blanca involuntaria.
—Voy a darle una vuelta.
—Manolo.
Se gira.
—Un OKR no es un contrato. Es una brújula. Si al final del trimestre no lo alcanzas pero has aprendido por qué, ha funcionado. Si lo alcanzas pero no ha cambiado nada… ha fracasado.
Se va.
Y yo me quedo pensando que quizás, solo quizás, esta vez Manolo no va a destrozar la idea del todo.
Gracias por leerme.
Seguimos.