Todo lo que he visto funcionar mal en OKRs
OKRs es una metodología excelente para fijar objetivos, en teoría. En la práctica, no funciona por sí sola.
Hoy leerás lo siguiente:
Una búsqueda laboral que me pasó un amigo.
Un repaso de la metodología.
Experiencias e historias de mala implementación de OKRs.
Cosas buenas que he aprendido de trabajar con OKRs.
Búsquedas laborales
Un amigo está buscando un Product Manager senior perfil startup con ganas de arrancar una app de cero para lanzar un producto de lifestyle en Estados Unidos. Tiene que estar en Latam y tener experiencia lanzando algún producto digital desde cero.
Si te interesa y crees que tu perfil encaja, o tienes algún conocido que pueda encajar, déjame el perfil en este link.
No soy el único
Un alumno levanta la mano y me pregunta: “¿Los empleados deberían tener atado su bonus a si cumplen o no con sus OKRs?”
¡Qué buena pregunta! ¿No? Mi intuición me dice que sí. Después de todo, los OKRs son objetivos ambiciosos pero logrables. Si la persona o el equipo da una milla extra, debería poder alcanzarlos y cobrar su bono por performance. Todos felices.
Sin embargo, mi respuesta es “No”. Porque en 10 años de product management, consultor y coach jamás, pero jamás, he visto OKRs funcionar. Es más, considero que he tirado horas valiosas de mi tiempo hablando estupideces.
Y no solo yo. Esto mismo lo he verificado con pares y otros trabajadores de empresas de tecnología. La frase que más resuena es: “Muy lindo, ¿cuándo vamos a dejar de hablar de las cosas maravillosas que supuestamente vamos a hacer y nos van a dejar en paz para poder trabajar?”.
Hoy te voy a contar todo lo malo que he visto de OKRs. Pero para ser justo, también te voy a contar cosas que sí he visto funcionar.
Repasemos OKRs un segundo
La metodología de OKRs es muy fácil de entender, pero llevarlo a la práctica es extremadamente complejo. No me he cruzado con demasiadas personas que no la entiendan o no coincidan en que hace sentido escribir objetivos de esa manera. Sin embargo, cuando realmente lo tienes que hacer, puede ser muy desafiante. Veamos:
OKRs - Objectives and Key Results - es una metodología para establecer objetivos medibles basados en outcomes. Es decir, en identificar qué es lo que para la organización realmente genera valor.
OKRs busca eliminar el desperdicio, evitar pensar en output y dar dirección hacia lo que realmente importa.
Se componen de tres partes:
Objetivos: Cualitativo - Debe ser aspiracional, y no establecer una métrica o hito relevante para cumplirse.
Ejemplo: Ser la APP de delivery número 1 para restaurantes premium en Bogotá.Key Results: Cuantitativo - Debe ser ambicioso pero alcanzable. Tiene que tener una métrica o hito vinculado, y esa métrica debe tener que ver con la generación de valor. Lanzar una funcionalidad no aplica, porque no genera valor por sí misma. Explican qué significa que el objetivo ha sido alcanzado. En general son 3 - 5 KRs por objetivo.
Ejemplo: Alcanzar una valoración de 4,5 en stores de aplicaciones móviles por parte de clientes de alto poder adquisitivo.Iniciativas: Tareas o hitos a alcanzar. Es todo lo que se planea hacer para alcanzar los KRs. Puro Output.
Ejemplo: Hacer 20 entrevistas con usuarios. Lanzar X funcionalidad antes de Y fecha.
En general las compañías suelen establecer un set de OKRs anuales o semestrales, y luego hacer lo mismo trimestre tras trimestre (Q a Q). Esto último se suele delegar en los equipos.
Fácil. ¿No? Bueno. El tiempo me ha demostrado que cada empresa lo maneja como quiere / puede. Pero eso no es lo malo. Lo malo es que, en general, la aplicación de la metodología suele estar muy atravesada por opiniones o decisiones que no se condicen con la realidad de los equipos o la organización. Y que en general terminan confundiendo o frustrando más de lo que ayudan.
Veamos algunos casos que he vivido.
Nota: OKRs está explicado en el libro Measure what matters.Las peores cosas que he visto en OKRs
45 días escribiendo OKRs
Como dije, en general los OKR se renuevan de Q a Q. Hay empresas que lo hacen de semestre a semestre. Pocas lo hacen a nivel anual, a menos a nivel equipos. También hay empresas en las que los equipos setean sus propios OKRs, hay otras en que es el management quien lo hace.
He trabajado en organizaciones donde las sesiones para setear OKRs empezaban 15 días antes de finalizar el Q. Supuestamente debían estar listos para final de mes, para tener listos los objetivos para cuando empezara el Q.
Mi opinión es que eso ya es tarde, porque direccionar a los equipos toma tiempo, y hay que ordenar y planificar en función de los objetivos. Pero terminar un mes después de empezar el Q es una catástrofe asegurada.
Supongamos que estamos terminando Q2 y empieza Q3. La compañía se toma un mes de Q3 para terminar de definir hacia dónde ir. Cuando finaliza, a finales de abril, debes armar el roadmap en función de las iniciativas, ordenar los sprints, correr para tener algo de product discovery que permita justificar tus decisiones y diseminar el mensaje por todos los equipos para que entiendan por qué están haciendo las iniciativas que propones.
Todo esto te toma algunas semanas, por lo que tienes solo un mes neto de trabajo.
El día que sabes que debes hacer, ya es demasiado tarde. El Q está terminando, y tienes pocas semanas para alcanzar unas métricas que desde el inicio fueron creadas con el espíritu de ser muy ambiciosas.
OKR como output
Digamos que esta es la contracara del problema anterior.
Tener un deadline para setear los OKRs es algo bueno, en especial por todo lo que acabo de describir. Es necesario establecer límites para que las personas realmente se ocupen del tema.
Sin embargo, esto en ocasiones se pasa para el otro lado. “Tengo que escribir algo en el excel de OKRs para la reunión de mañana” he escuchado decir a un founder. Parece ser que era más importante tener terminado los OKRs que darle la dirección correcta a la compañía.
Si no se tiene claridad sobre la dirección de la compañía, es muy difícil que se puedan escribir OKRs que realmente den dirección y claridad a los equipos. Además, si se hacen a las apuradas para “tener algo”, seguramente van a demandar retrabajo y pedidos para modificarlos en medio del Q/semestre.
Cambios de dirección Q a Q
Un Q la organización está obsesionada con el revenue. Al siguiente, por adquirir más usuarios. Al siguiente, empuja para que una nueva funcionalidad estratégica tenga tracción.
No está mal si es previsible, pero los cambios radicales Q a Q demuestran una clara falta de visión y estrategía. Los OKRs de cada Q deberían ser más o menos predecibles por todas las partes involucradas.
De hecho, si la visión y la estrategia están claras, escribir los OKRs debería ser relativamente fácil y rápido. Es la falta de dirección lo que demora el proceso.
Culpar en vez de colaborar
He visto como el management de una startup estaba molesto con un PM cuya métrica de OKR estaba cayendo. Realmente era una situación extraña, puesto que la métrica había tenido una gran caída a mediados del Q y era muy difícil atribuirle una causa clara, a pesar de las investigaciones.
Los líderes de otros equipos y el management preguntaban en tono acusativo y le decían que no estaba haciendo lo suficiente, pero la realidad es que nadie en la mesa tenía idea que estaba pasando y por qué.
La única aproximación era que el número de usuarios era relativamente bajo, por lo que unas pocas bajas tiraban mucho el porcentaje. Sin embargo, la causa no estaba a la vista.
No sé cómo arreglar esto. Supongo que es una cuestión cultural. Lo que sí sé es que en empresas poco colaborativas es muy díficil que se logre. OKRs está ahí para dar dirección y que entre todos podamos entender cuáles son las variables que mueven las métricas y aportan valor, no para encontrar fácilmente un chivo expiatorio cuando no se logran.
La ambición
Otro ejemplo de qué no hacer es setear objetivos imposibles de alcanzar. O extremadamente difíciles.
Conocí una persona que decía que los OKRs debían ser muy ambiciosos, porque eso no solo mostraba lo que la compañía quería alcanzar, sino que además motivaba a la gente a intentar alcanzarlo. Para él, si un KR se cumplía, es porque estaba mal elaborado.
Yo creo exactamente lo contrario. Sí, los OKRs deben ser ambiciosos, pero realistas en su posibilidad de compleción. De lo contrario, de Q a Q los equipos se frustrarán porque saben el primer día que no podrán alcanzarlo. Entonces, ¿para qué esforzarse?
¿Existe alguna sensación más linda que la de cumplir con los objetivos? Sobre todo si te ha tomado mucho esfuerzo y dedicación.
Silos
Definir un set de OKRs para la compañía y luego dándole libertad a cada área (como operaciones, ventas, producto, tech, etc.) para elegir los suyos es un error. La desconección total está garantizada, y se pierde cualquier tipo de incentivo a trabajar en equipo, a menos que de casualidad justo haya dos equipos con KRs similares.
Las áreas tienden a mirar su propia operación, por lo que escribirán sus KRs en función a ello. Para las áreas de producto esto es muy doloroso, porque en general deben colaborar con distintos equipos para poder alinear las iniciativas del equipo de tecnología. Sin embargo, es común que se encuentre que los demás equipos no tienen incentivo a colaborar porque están ocupados con sus propios KRs.
Los OKRs deben ser, primero, cross equipo. Luego, cada área puede tener sus objetivos específicos. Pero los prioritarios tienen que ser los multidisciplinarios.
Inflexibilidad ante el modo proyecto
Una vez tuve que implementar un producto que tomó meses. Durante ese tiempo, estábamos intentando volvernos más metódicos en el seteo de OKRs. Casi me vuelvo loco.
Era casi imposible poder trabajar en OKRs que hablarán de outcome, cuando todos mis objetivos durante el Q tenían que ver con lanzar cosas.
Sí, había algunos KRs que se podían escribir como “Testear X solución con 10 usuarios internos”. Pero no era aplicable a todas las iniciativas.
Siempre digo que las herramientas se adaptan a los equipos y no viceversa. Es importante ser flexible en estos casos para no caer en el sobretrabajo. Si el KR tiene que se output y no outcome por una situación particular, que lo sea. No lo sobrecompliques.
La amenaza
Esta es una de las situaciones más extremas y ridículas que llegue a vivir. Fue hace ya muchos años, pero siempre la recuerdo como el fracaso total de la metodología cuando está mal aplicada.
Resulta que cada equipo debía escribir sus OKRs, y tenía KRs cuyo ownership era compartido por dos áreas, con el objetivo de garantizar la colaboración.
Como a la empresa le costaba llegar a la fecha establecida para tener definidos los OKRs, era normal que aún se estén debatiendo detalles finales una vez empezado el Q. En ese momento, estaba discutiendo un tema de prioridades con un área de negocio.
Mi postura era categórica: no podía poner en el backlog del Q lo que me pedían. Tenía otras prioridades que estaban demostradas que eran más importantes. Sin embargo, mi evidencia no lo satisfizo.
“Ok, está bien. Entonces voy a escribir esto como un KR compartido y lo vas a tener que hacer.”
Según las reglas de cómo estábamos trabajando, lo podía hacer. Los OKRs se convirtieron en una herramienta para obligar a producto a priorizar iniciativas. Una maravilla.
Cosas buenas que he visto en OKRs
Para ser justo, dentro de ese caos también he visto cosas buenas. A pesar de todos estos errores o problemas, he visto que hay beneficios que, a priori, no son tan visibles.
Las personas suelen enfrascarse mucho en la pérdida de tiempo o la falta de foco en su trabajo, pero el solo proceso de generación de OKRs trae algunos beneficios:
Dirección
A pesar de que los OKRs sean estúpidamente ambiciosos y desmotivantes, o que se entreguen tarde, sirven para poder dar dirección. A veces los equipos no saben realmente qué es lo que deben hacer, qué tareas priorizar o qué se espera de ellos.
OKRs resuelve parcialmente ese problema, estableciendo un marco general para la toma de decisiones. Permite descartar fácilmente los requerimientos o iniciativas que no ayudan al objetivo general.
Aprendizaje
El proceso de creación de OKRs puede ser largo y doloroso, como ya he hablado. Hay organizaciones que siguen atrapadas en ese dolor durante años, incluso nunca superándolo.
Sin embargo, hay otras que realmente generan aprendizajes a partir de allí.
Si cada nuevo trimestre, la empresa logra hacer OKRs de manera más rápida y en línea con la estrategia a largo plazo de la compañía, entonces se está avanzando en la dirección correcta.
Obviamente esto depende mucho de factores culturales y de la capacidad de iteración de los procesos del management y los equipos.
Taskforces
Una metodología que me ha gustado últimamente es la de task forces. Esta metodología consiste en definir objetivos con un “Task Force Leader”, una persona encargada de velar por ese objetivo.
Luego, ese líder elige su “Task Force”, un grupo de personas de diferentes equipos que se harán responsables de velar por el cumplimiento del objetivo, escribiendo los KRs y empujando al resto de la organización a cumplir con esas metas.
Me gusta esta idea por varios motivos:
Arma equipos multidisciplinarios, evitando los silos.
Los miembros del TaskForce están altamente motivados.
Se acelera el proceso de armado de KRs, porque es un equipo relativamente pequeño dedicado a esto. Y encima suelen ser personas directamente relacionadas con la ejecución.
Lo he visto implementado en un contexto con objetivos demasiado ambiciosos, por lo que con los días la motivación se fue diluyendo: era completamente irreal, todos sabían que no se podía llegar al objetivo. Sin embargo, sirvió para trabajar en equipo sobre iniciativas que tiempo después fueron implementadas y requerían la colaboración de todos.
¿Y tú? ¿Qué experiencia tienes trabajando con OKRs?
¿Te gustó el resumen? ¿Entendiste algo nuevo? Dale like y compártelo. Me haces un favor ENORME para seguir creciendo el newsletter y seguir publicando este tipo de contenido.
¡Nos vemos la semana que viene!
Mentorias: Si quieres empezar en producto, pasar las entrevistas, aprender de forma personalizada, crecer en tu carrera o aprender a liderar un equipo de producto
¡Agéndame una reunión! (costos asociados)
Muy útil tu NL. Siempre se aprende algo nuevo y el contenido va de frente a la vena