OKRs para equipos técnicos: el framework que finalmente nos funcionó
Intentamos OKRs tres veces antes de que funcionaran. Aquí está la diferencia entre los dos primeros intentos fallidos y el tercero.
Sofía Ramos
Engineering Manager
14 Apr 2025
6 min lectura
El error clásico: métricas de actividad disfrazadas de resultados
Nuestro primer ciclo de OKRs tenía Key Results como "entregar 12 features en Q1" y "reducir deuda técnica en un 20%". Suenan bien. El problema: son outputs, no outcomes. Miden actividad, no impacto.
Un equipo puede entregar 12 features mediocres que nadie usa y marcar el OKR como verde. Eso no es éxito — es teatro de métricas.
El framework que funcionó: North Star + guardianes
En el tercer intento adoptamos un modelo simple: un solo Objective por equipo por quarter, con máximo tres Key Results medibles en negocio (no en código). Además, asignamos "guardianes" — métricas de salud que no pueden empeorar aunque los OKRs vayan bien.
- Objective: Que los usuarios puedan completar su primer flujo sin ayuda
- KR1: Reducir el drop-off en onboarding de 68% a 45%
- KR2: Aumentar el porcentaje de usuarios que activan la feature core en día 1 de 23% a 40%
- Guardián: Tiempo de respuesta del API p95 no debe superar 300ms
Lo que cambia con este enfoque
El equipo deja de preguntar "¿qué construimos este sprint?" y empieza a preguntar "¿qué hipótesis validamos esta semana?". Es un cambio cultural más que un cambio de proceso — y tarda al menos dos quarters en asentarse.
Un buen OKR no le dice al equipo qué hacer. Le dice al equipo cómo saber si lo que hizo importó.