Estructura correcta de un OKR efectivo
Un OKR tiene dos componentes: el Objective (qué querés lograr, aspiracional pero alcanzable) y los Key Results (cómo medís el progreso, cuantitativos y time-bound). Formato correcto: 'Objetivo: Convertirnos en la plataforma preferida para X' con KRs como 'Aumentar NPS de 35 a 55', 'Reducir churn de 8% a 3%', 'Alcanzar 50k usuarios activos mensuales'. El objetivo inspira, los KRs anclan en realidad.
Los Key Results deben seguir criterios SMART pero el Objective puede ser más amplio. Error común: escribir el objetivo como métrica ('Aumentar revenue en 30%') en vez de dirección estratégica ('Escalar rentablemente nuestro modelo de negocio'). Los KRs son el '30% revenue', '25% CAC reduction', '120% net retention'. Tres KRs por objetivo es el sweet spot: menos de eso no captura complejidad, más de eso diluye foco.
La escala de logro típica: 70% completion se considera éxito. Si lográs 100% consistentemente, tus OKRs no son suficientemente ambiciosos. Google popularizó la regla '0.7 = success': sets aggressive targets que stretch al equipo sin crear burnout. Importante: los OKRs NO son performance reviews; son herramientas de alineación y priorización. Un OKR fallido no significa fracaso personal si se aprendió y ajustó rápido.
Cascada de OKRs: de empresa a equipo a individual
Los OKRs funcionan mejor con cascada bidireccional: top-down (dirección estratégica desde liderazgo) y bottom-up (iniciativas desde equipos que saben qué es posible). Ejemplo: Company OKR 'Dominar mercado enterprise' → Product Team OKR 'Lanzar features compliance-ready' → Engineer OKR 'Implementar SOC2 Type II certification'. Cada nivel contribuye al anterior pero tiene autonomía en el cómo.
Reglas de alineación: el 60% de los OKRs de equipo deben conectar directamente con OKRs de empresa; el 40% puede ser iniciativas locales críticas (pagar tech debt, mejorar herramientas internas). Esto balancea alineación estratégica con necesidades operativas reales. Usá un OKR tree o dependency map visual para mostrar cómo cada objetivo de equipo alimenta metas organizacionales.
Los OKRs individuales (personal OKRs) son opcionales pero poderosos para desarrollo profesional. Deben ser 70% alineados con OKRs del equipo y 30% growth personal. Ejemplo: un developer puede tener 'Liderar implementación de feature X' (alineado) y 'Convertirme en go-to expert en GraphQL' (desarrollo). Los one-on-ones son el espacio para trackear estos, no las reuniones de equipo completo.
Ciclo de vida: planning, tracking, y retrospectiva
El planning de OKRs toma 2-3 semanas al inicio del quarter. Semana 1: liderazgo propone company OKRs basados en estrategia anual. Semana 2: equipos draftan sus OKRs alineados, con sesiones de calibración cross-funcionales para evitar silos. Semana 3: finalization y comunicación all-hands. El objetivo es que todos entiendan no solo sus OKRs sino los del resto: Sales entiende por qué Product prioriza X feature, Engineering sabe por qué Marketing necesita Y capability.
Tracking semanal o bi-semanal es crucial: status updates de 'on track / at risk / off track' con score numérico (0.0 a 1.0). Herramientas como Lattice, Perdoo, o simplemente spreadsheets compartidos. Lo importante no es la herramienta sino la disciplina: cada KR tiene owner, current value, target, y confidence level. En weekly syncs, enfocate en los 'at risk': ¿qué blockers hay? ¿necesitamos re-priorizar? Los OKRs que están on track no necesitan mucha discusión.
La retrospectiva de fin de quarter es donde ocurre el aprendizaje real. Pregunta clave no es 'logramos el número?' sino '¿qué aprendimos que cambia nuestra estrategia?' Un OKR logrado al 40% puede ser más valioso que uno al 90% si descubriste que el objetivo original no era el correcto. Documentá: qué funcionó, qué no, qué assumptions eran incorrectas, y cómo eso informa los próximos OKRs. Este doc se vuelve institutional memory invaluable.
Errores comunes y cómo evitarlos
OKRs disfrazados de todo-list: 'Migrar base de datos', 'Contratar 3 developers', 'Lanzar campaña email'. Estos son tasks, no objectives. El test: ¿el logro de esto cambia significativamente nuestro negocio/producto? Si la respuesta es 'un poco', no es un OKR. Los OKRs son resultados transformadores, no checklist operacional. Las tasks van en roadmaps y sprints, los OKRs guían qué roadmaps priorizar.
Demasiados OKRs: tener 8 objectives de equipo significa que nada es realmente prioritario. El límite razonable: 3-5 company OKRs, 3-4 team OKRs. Menos es más porque fuerza conversaciones difíciles sobre qué NO hacer. Si todo es importante, nada es importante. Practicá el 'no': cada OKR nuevo debe desplazar algo existente o demostrar que es más crítico.
KRs cualitativos o subjetivos: 'Mejorar la experiencia del usuario', '¿Aumentar calidad de código'. ¿Cómo medís 'mejorado'? Los KRs necesitan números: 'Aumentar NPS de X a Y', 'Reducir P95 latency de A a B ms', 'Alcanzar code coverage de C%'. Si no podés medir objetivamente, no es un Key Result válido. Excepción: experimentos exploratorios pueden tener KRs como 'Validar hipótesis X con 50 user interviews', donde el número está en la validación, no en el outcome.