Una encuesta reciente de OKR International mostró que el 78 % de los equipos no lograba implementar bien los OKR cuando los introducían. Es un número alto. Y lo más sorprendente es que el framework de OKR en sí es bastante minimalista comparado con algo como EoS o Scaling Up. Entonces, ¿cómo es posible que haya tan poco éxito inicial en la adopción de una metodología de definición de objetivos que solo tiene 2 componentes (los objetivos y los resultados clave)?
En Tability tenemos una comprensión bastante particular de este problema, porque el 95 % de nuestros clientes usan nuestra plataforma para hacer seguimiento de sus OKR. A lo largo de los años hemos hablado con más de 500 equipos sobre sus objetivos, y hay varias buenas razones por las que es tan difícil acertar con los OKR en el primer intento.
Por qué los OKR fallan la primera vez
Aunque las empresas pueden ser muy diferentes entre sí, suelen ser los mismos patrones los que determinan los éxitos y los fracasos. Podrías tener cientos de conversaciones distintas y verías surgir los mismos 3 temas al hablar de los fracasos con los OKR:
- Es difícil cambiar una cultura centrada en los entregables
- Conseguir compromiso lleva tiempo
- Demasiado reporting, pocas conversaciones
Problema 1: es difícil cambiar una cultura centrada en los entregables
Si le preguntas «¿cuáles son tus resultados clave?» a alguien que no conoce el framework de OKR, probablemente te responderá con una lista de proyectos que necesita entregar.
Interpretó la pregunta de forma literal y te dio la lista de cosas que debe construir/lanzar/completar.
Pero en el mundo de los OKR, un resultado clave debe capturar el impacto esperado de tu trabajo, en lugar del trabajo en sí. Por ejemplo, en vez de tener «Lanzar una campaña de anuncios en LinkedIn» como resultado clave, deberías medir «Conseguir XX clientes usando LinkedIn como canal».
Problema 2: conseguir compromiso lleva tiempo
La primera vez que me presentaron los OKR, me pareció una hoja de cálculo más para rellenar para la dirección (en ese momento era Product Manager). Si avanzamos hasta hoy, realmente creo que los OKR son una de las mejores herramientas disponibles para las empresas que quieren escalar la alineación sin añadir muchas capas de mandos intermedios.
La razón por la que me llevó aproximadamente 3 ciclos «entender» el valor de los OKR es que muchos de los beneficios se experimentan de forma colectiva más que individual. Déjame explicarlo viendo cómo se adoptan los Design Systems.
Un Design System es un conjunto de estándares y componentes reutilizables que se pueden usar para crear aplicaciones. Es especialmente útil para organizaciones que tienen varios productos construidos por diferentes equipos. Pero, igual que con los OKR, puedes encontrarte cierta resistencia inicial cuando lo implementas. ¿Por qué? Porque obligas a los equipos a adoptar un estándar que tú sabes que dará resultado globalmente, pero que a ellos les parece un retroceso localmente.
Esto es exactamente lo que viví cuando Atlassian lanzó su design system. Desde la perspectiva de un equipo, sentías que tenías que renunciar a algunos componentes personalizados geniales que funcionaban de maravilla en tu producto específico. Pero, si te alejabas para considerar la experiencia de un usuario con varios productos de Atlassian, eso significaba que tenía una experiencia mucho mejor, porque todo se sentía siempre familiar y coherente. Al final lo logramos, pero costó tiempo y esfuerzo conseguir el compromiso total.
Volvamos a los OKR. Podrías dejar que cada equipo diseñara su propia metodología de definición de objetivos, con sus propios términos y reglas. Pero eso llevaría rápidamente al caos a gran escala. El framework de OKR es, en esencia, un Design System para la definición de objetivos, y aporta una experiencia coherente y familiar en toda la organización.
Pero llevará tiempo que la gente lo vea así.
Problema 3: demasiado reporting, pocas conversaciones
La inmensa mayoría de las personas con las que hablamos empezaron «haciendo seguimiento» de sus OKR en hojas de cálculo. Pongo seguimiento entre comillas aquí, porque muchas veces las cosas se ven así:
- Día 1: añade tus OKR a la hoja de cálculo.
- Día 1…30: *cri-cri*
- Día 30: rápido, rápido, actualicemos esa hoja de cálculo antes de la reunión de revisión
- Día 30-60: *cri-cri*
- Día 60: rápido, rápido, actualicemos esa hoja de cálculo antes de la reunión de revisión
- Etc…
No hay mucho seguimiento durante el mes, y pasan semanas antes de que la gente vuelva a mirar sus objetivos.
Los OKR no serán útiles si se reducen a un ejercicio de reporting al final de cada mes. Primero, será muy difícil para tu equipo mantenerse enfocado en lo correcto. No porque no les importe, sino porque resolver problemas difíciles requiere el 100 % de tu atención. O estás pensando en el problema, o estás pensando en por qué estás trabajando en ese problema. Es difícil hacer ambas cosas a la vez.
Entonces, si un equipo empieza a trabajar en un problema de generación de leads, podría toparse con otros problemas relacionados con la optimización del sitio web, o trabajar en mejorar el drip feed, pero ¿es eso lo que importa ahora?
Tus OKR deberían ser un faro constante que ayude a los equipos a notar rápidamente cuándo se están alejando de sus objetivos. Y esto solo puede ocurrir si el progreso de los objetivos se convierte en una conversación continua en lugar de una presentación que se envía para su revisión.
Soluciones sencillas para los problemas más comunes de los OKR
Vale, acabo de escribir 650 palabras hablando de problemas. Quizá sea hora de ofrecer algunas soluciones.
Antes de entrar en materia, debo decir que no hay atajos para los cambios culturales. Atlassian resolvió el compromiso con el Design System mediante conversaciones y presentaciones repetidas sobre la decisión de tener componentes estándar. Lo más probable es que tengas que hacer lo mismo para conseguir el compromiso con los OKR. Los beneficios pueden parecerte obvios, pero es muy probable que otros no lo vean de esa manera.
.jpeg)
Espera.
Puede que tenga un pequeño consejo aquí.
Una cosa que ayudó a que todos se subieran al carro del Design System fue mostrar lo chocante que resultaba la experiencia al pasar de un producto a otro (¡o incluso de una pantalla a otra!). Las pestañas eran diferentes, los botones tenían patrones distintos, y a los usuarios les costaba completar flujos de trabajo simples entre productos. Quizá podrías hacer lo mismo pidiendo a cada equipo que envíe su documento de estrategia tal cual (sin hacer trampa creando una página nueva), y ver qué tan fácil es para el equipo A entender en qué se está enfocando el equipo B.
Vale, ahora echemos un vistazo a algunas soluciones sencillas.
Impón límites
Lo primero que debes hacer es limitar el número de OKR. Es tentador que todos tengan objetivos, pero es mejor empezar en pequeño mientras haces la transición de estar centrado en proyectos a estar orientado a resultados.
Aquí tienes un conjunto sencillo de reglas:
- Solo OKR de nivel superior y de equipo (sin OKR individuales)
- No más de 3 objetivos por plan
- No más de 4 resultados clave por objetivo
Establecer límites reducirá el riesgo de reproducir tu roadmap en tus OKR. La escasez genera foco y claridad. Si solo tienes entre 8 y 12 resultados clave para capturar tu intención, tendrás que elegir muy bien las cosas que mejor representan el éxito al final del trimestre.
Otro límite: nadie debería tener a su cargo más de 5 resultados clave en el trimestre. ¿Por qué? El trabajo del responsable es compartir actualizaciones de progreso con el resto de la organización mediante check-ins regulares. Es una tarea importante que solo se puede hacer bien si tienes suficiente tiempo para reflexionar. 5 minutos por KR x 5 KR = 25 minutos. Suena divertido y factible. Pero la calidad de los check-ins caerá rápidamente si empiezas a darle más resultados clave a la gente.
Una forma rápida de encontrar planes y usuarios con demasiados OKR

Puedes usar la función de auditoría de Tability para detectar rápidamente planes y usuarios que tienen demasiados resultados clave asociados. Una vez que tu equipo añade sus OKR a Tability, la plataforma analizará todos los objetivos para identificar problemas comunes que deberían corregirse. Esto puede incluir:
- Un usuario con demasiados objetivos
- KR sin responsable o no medibles
- Planes sin check-ins
- Etc
Esto ayudará a los OKR champions que quieran dar asistencia rápida a sus equipos.
Haz de los OKR parte de tu rutina semanal
Hay una gran cita del libro «Continuous Delivery».
Si duele, hazlo más a menudo, y adelanta el dolor” - Jez Humble
Esta frase se dio en el contexto de despliegues de software difíciles de automatizar. Podrías seguir reuniendo a tu equipo una vez al mes para pasar por un tedioso proceso de lanzamiento. O puedes adelantar el dolor y hacer lo necesario para desplegar tu código cada semana. Esto te obligará a mirar de frente tu problema y a descubrir cómo eliminar la fricción para que las cosas sean lo menos dolorosas posible.
Lo mismo puede decirse de los OKR.
En primer lugar, tu equipo debería revisar el progreso de los objetivos al principio de cada semana.

Esta es la mejor forma de mantener a todos alineados y de volver a poner los objetivos en el centro (recuerda, el 95 % de la semana gira en torno a los entregables).
En segundo lugar, si el seguimiento semanal de los OKR resulta doloroso, la respuesta no debería ser mirar los OKR con menos frecuencia. Debería ser averiguar dónde están los puntos de fricción y hacer lo necesario para lograr un ritmo semanal sin estrés.
Una forma sencilla de reducir el dolor de los OKR
Igual que los equipos de software usan herramientas de CI/CD para automatizar los despliegues, puedes usar Tability para automatizar las partes tediosas de los OKR:
- Obtén un dashboard en vivo para cada plan
- Recordatorios automáticos de check-ins por email/Slack/notificaciones push
- Notificaciones de alerta, gráficos de progreso, insights y métricas
- Resumen por email, modo presentación, etc… Todos los dashboards que necesitas para tus stakeholders están a un clic de distancia
- Puedes conectar Tability con tus herramientas para extraer datos automáticamente
Échale un vistazo a la demo de Wyl más abajo si quieres verlo en acción 👇
Conecta los OKR con proyectos estratégicos
Estar orientado a resultados no significa que los proyectos dejen de importar. Tus proyectos siguen importando, pero ahora se tratan como apuestas que pueden ayudarte a lograr tus OKR clave, en lugar de compromisos críticos que deben entregarse pase lo que pase.
.png)
Esta es también la razón por la que deberías tener un bucle de retroalimentación saludable entre tus resultados (OKR) y tus entregables (proyectos/iniciativas estratégicas). Cada semana, tu equipo entregará ciertos entregables. Y cada semana, deberías poder medir su impacto. Si algo funciona bien, apuesta más fuerte por ello. Pero también debería estar bien abandonar las apuestas que no están dando resultado.
.png)
En la práctica, esto significa que necesitas encontrar la forma de conectar tus iniciativas de alto nivel con los OKR existentes (no hagas esto con tareas de bajo nivel). Por supuesto, tendrás proyectos del día a día que no estarán vinculados a resultados clave u objetivos específicos. Pero debería ser muy fácil hacer el camino inverso para responder a la pregunta «¿qué estamos haciendo ahora mismo para lograr este OKR?».
Una forma rápida de conectar resultados con entregables
En Tability, puedes simplemente listar iniciativas bajo cada resultado clave, incluyendo la vinculación de elementos de tu herramienta de gestión de proyectos. Una vez vinculadas, Tability ofrecerá muchas formas diferentes de relacionar los proyectos estratégicos con los objetivos en curso.
Qué viene ahora
Me costó un poco encontrar el título adecuado para este artículo. Pensé que trataría sobre analogías de Diseño o de Software, pero fue la cita de Jez Humble la que lo puso todo en perspectiva.
Conseguir que decenas de personas repartidas en decenas de equipos estén sincronizadas es doloroso. Pero lo contraintuitivo es que deberíamos enfrentar ese dolor e invertir en sincronizarnos más a menudo. Es poco probable que la alternativa nos ayude. Peor aún, podría dañar nuestra cultura a largo plazo.
Si buscas más consejos, tenemos una lista de 15 reglas pensadas para simplificar los OKR. Llamamos a ese modelo Flowing OKRs, y debería al menos generar debates útiles.



.jpg)

