Errores más comunes en la implementación de OKRs


Hola! Para cerrar esta mini-serie, estos son los errores más comunes que vengo encontrando en la utilización de OKRs:

  • set and forget: definir OKRs al comienzo del trimestre y solo volver a mirarlos al final del trimestre. Solución: al definir los OKRs, establece la cadencia y las ceremonias de seguimiento (semanalmente o como máximo cada 2 semanas).
  • colocar proyectos como objetivos: entregar un proyecto, funcionalidad o módulo del sistema no es un objetivo. Un proyecto se realiza para alcanzar algo. ¿Qué es ese "algo"? Pregúntate: si este proyecto mágicamente estuviera listo hoy, ¿qué cambiaría? ¿Para qué sirvió? ¿Dónde veo su impacto? Ese es tu objetivo y este proyecto es solo una de las formas de alcanzarlo.
  • solo el equipo de Producto sigue los OKRs: crea ceremonias e involucra a todo el equipo (sí, los desarrolladores también), idealmente rotando quién presenta al resto del equipo la evolución de los OKRs (sí, los desarrolladores también deben presentar).
  • tener OKRs de Producto y OKRs de Ingeniería como cosas separadas: Producto difícilmente alcanza resultados por sí solo, en general los Product Managers alcanzan resultados a través del equipo de ingeniería. De esta forma, al tener OKRs separados estarás entregando dos conjuntos de objetivos diferentes a un mismo equipo. Los PMs y Engineering Managers deben trabajar juntos, con input de los desarrolladores, para definir solo un conjunto de objetivos para el equipo.
  • colocar muchos objetivos: suele ser una decisión difícil afirmar "no vamos a trabajar en esto este trimestre". Algunas lideranzas no toman esta decisión difícil y colocan muchos Key Results diferentes para un mismo equipo, que claramente no tiene la capacidad suficiente para abordar todos. De dos, una:
    • el equipo acabará eligiendo algunos de los objetivos: ya sean los que más les gustan, los que dominan más o aquellos con algún incentivo, como un bono o la resolución de un problema de un área con la que tienen más estrés.
    • el equipo intentará abordar todos al mismo tiempo, dispersando sus esfuerzos y no siendo capaz de mostrar resultados significativos en ninguno de ellos. Es mejor hacer una cosa bien hecha que un poco de muchas cosas.

¡Evita estos problemas y ya estarás en un buen camino!

Saludos,

Leo

Leo Andreucci - CTO Mentor

About me: I have been working in startups since 2004. I spent 10 years at Apontador/MapLink and was part of Creditas (fintech last valued at $4.8bi) from its early days. Initially, as an Advisor, I hired the first software engineers for Creditas. As the business developed, I joined the project full-time as VP. I scaled the technology team to 150 people and later led international expansion and new product initiatives. I left in 2022 and, after a sabbatical, started working as an independent consultant in 2023.

Read more from Leo Andreucci - CTO Mentor

He visto una variación muy grande en el nivel de uso de IA para escribir código en equipos de Tecnología. Por un lado, equipos maduros utilizando múltiples agentes. Por otro, equipos que todavía usan apenas un tímido autocomplete mejorado, cuando mucho. Este texto es un llamado para el segundo grupo. Probablemente estás escéptico en cuanto a la calidad del código generado por IA, si va a entender todo el contexto de tu proyecto y si ese código te va a generar problemas en el futuro. Son...

Boas-vindas às 73 novas assinantes dessa newsletter! Tenho visto uma variação muito grande no nível de utilização de IA para escrever código em times de Tecnologia. Por um lado, times maduros utilizando múltiplos agentes. Por outro, times ainda usando apenas um tímido autocomplete melhorado, quando muito. Esse texto é um chamado para o segundo grupo. Você provavelmente está cético quando à qualidade do código gerado por IA, se ela vai entender todo o contexto do seu projeto e se esse código...

He visto muchas empresas con fricción entre las áreas de Producto y CS, generalmente causada por la distancia y la falta de alineación. Aunque es algo comprensible, esa fricción no debería existir, porque en el fondo ambos equipos tienen la misma misión: asegurar que el producto resuelva un problema real del cliente con una excelente experiencia. Aquí van algunas sugerencias para mejorar esa dinámica: En la Definition of Done (DoD) del equipo de desarrollo, hay algún punto que mencione la...