Excelencia Operacional, la palanca del Tech Lead
Cómo usar KPIs, SLIs y SLOs para convertir métricas en decisiones
Me gusta tu artículo, pero no hablas de KPIs, SLOs…
Este fue parte del feedback de Fabián sobre el primer artículo de la serie de Tech Leads (TL). Y tenía razón. Faltaba la pregunta incómoda: ¿cómo sabemos si vamos bien?
Si eres Tech Lead, en algún momento te van a pedir “más velocidad”. Más features, más proyectos, más impacto. Y tú vas a ver, en paralelo, más incidencias, más ruido de alertas, más incertidumbre, más tiempo perdido en investigar cosas que “no deberían pasar”.
Puedes tener buen criterio e impulsar estándares de calidad. Pero si no puedes medir el estado del sistema ni el coste real de operarlo, operas a ciegas. Y cuando operas a ciegas, todo acaba en discusiones eternas: “yo creo que está bien”, “yo creo que no”, “esto siempre ha sido así”. Para mí, eso es exactamente lo que evita la excelencia operacional.
La excelencia operacional es la capacidad del equipo para entregar valor de forma sostenida, sin degradar la confianza del usuario, sin quemar al equipo y sin que cada incidente reinicie el contador. Es una disciplina, no un proyecto.
Tres tipos de métricas, tres intenciones distintas
Lo primero es separar por intención. Si mezclas intenciones, acabarás con dashboards bonitos y cero decisiones.
1) KPIs
Empecemos separando conceptos. Los Key Performance Indicators (KPIs) no son solo métricas de negocio. Hay KPIs de negocio — conversión, retención, ingresos, adopción — y KPIs internos de equipo (lead time, frecuencia de despliegue, volumen de incidentes, coste por petición, ruido de la guardia). Ambos importan, pero responden a preguntas distintas.
Los KPIs de negocio indican si la organización está obteniendo valor.
Los KPIs internos indican a qué costes operativos y humanos se asocia ese valor.
Un Tech Lead opera principalmente en este segundo plano. No porque ignore el negocio, sino porque su palanca es hacer que el sistema técnico sea sostenible mientras el negocio crece.
2) SLIs: “¿cómo se comporta el sistema?”
Un SLI (Service Level Indicator) es una medida observable del comportamiento de tu servicio. Ejemplos típicos:
Disponibilidad (peticiones correctas vs. total).
Latencia (p50, p95, p99).
Tasa de errores (por tipo, por endpoint, por causa).
Frescura de datos (si hay colas, procesos en batch, replicación).
Saturación (CPU, memoria, pool de conexiones, cola, límites de peticiones).
Los SLIs describen la realidad. No te dicen si esa realidad es aceptable.
3) SLOs: “¿qué significa ‘suficientemente bueno’ para el usuario?”
Un SLO (Service Level Objective) es un objetivo explícito sobre un SLI en una ventana de tiempo. Ejemplo:
En 30 días, el 99,9 % de las peticiones del flujo de checkout deben completarse correctamente en menos de 300 milissegundos.
Los SLOs son una forma de contrato. No legal. Operativo. Un “esto es lo que garantizamos como equipo”. Una parte importante: los SLOs no son binarios. No se trata de “cumples o fallas”. Aquí entra el concepto clave: el “presupuesto de errores” (error budget).
Si tu SLO es del 99,9 %, estás aceptando explícitamente que el 0,1 % de las peticiones puede fallar o tardar dentro de esa ventana. Es un fallo permitido por el diseño, no un accidente. Mientras el consumo de ese “presupuesto” esté bajo control, el sistema está “dentro de SLO”, aunque haya incidentes. Un incidente no significa automáticamente que estés fuera de budget.
Una buena herramienta de negociación
En mi experiencia, la mayoría de las fricciones entre TL, Engineering Manager (EM) y Product Manager (PM) nacen de lo mismo: no hay una definición compartida de “bueno”:
Las tres son legítimas. El problema es que si no hay un mecanismo, la discusión se convierte en política. Los SLO y los error budgets forman parte de ese mecanismo. Si el consumo es bajo, el equipo tiene margen para asumir riesgos, implementar cambios y impulsar nuevas funcionalidades. Si el error budget se quema rápido, es una señal clara de que hay que parar, estabilizar y pagar deuda.
Desde la perspectiva del Tech Lead, los SLOs y el presupuesto de errores son una de las palancas más potentes para negociar velocidad, alcance y calidad sin recurrir a opiniones ni a la jerarquía.
Esto no elimina las conversaciones difíciles, pero sí les da un poco de orden.
No es hacer más ops, es reducir incertidumbre
Aquí viene la parte importante para un Tech Lead: la excelencia operacional no es “ser SRE” ni “vivir en Grafana”. Es diseñar un sistema operativo para el equipo que minimice la incertidumbre.
Un TL lidera excelencia operacional cuando consigue que:
Detectar problemas sea rápido.
Diagnosticar sea menos artesanal.
Mitigar sea repetible.
Aprender sea real (no un incident review que nadie ejecuta).
La carga de on-call sea sostenible.
Los trade-offs se deciden con datos.
👋 Hola, soy João. Este es el segundo artículo de una serie pensada para Tech Leads y Engineering Managers que quieren liderar con más claridad e intención:
“Excelencia Operacional, la palanca del Tech Lead”. ← Este artículo
“Antipatrones de un Tech Lead” ← enero de 2026. Suscríbete para no perderlo.
Continuará…
Estoy escribiendo “El Manual del Tech Lead”, cuyo lanzamiento está previsto para la primera mitad de 2026. Las ideas de esta serie serán su base.
Si quieres unirte a la lista de espera, recibirás un 25 % de descuento en el lanzamiento.
¿Qué debe liderar? ¿Qué debe influir?
Aquí conviene ser nítido, porque si no, el TL intenta abarcarlo todo y se convierte en un cuello de botella.
El TL debería liderar
Definición de SLIs y SLOs que representen la experiencia de usuario, no de métricas de vanidad.
Filosofía de alertas: alertar por síntomas visibles para el usuario, no por causas internas del sistema.
Instrumentación mínima: logs, trazas, métricas y estándares de diagnóstico.
Higiene en la gestión de incidentes: runbooks claros, alertas con contexto e incident reviews estructuradas.
Cadencias: revisión periódica de los SLOs y de las acciones.
El TL debería influir
Política de error budget y cómo afecta al roadmap (con PM/EM).
Priorización: cuánto tiempo se dedica a la fiabilidad vs. a las nuevas funcionalidades (con EM/PM).
Definición de KPIs técnicamente medibles y no “deseos” (con PM).
Inversión en herramientas (con EM y el equipo de plataforma correspondiente, si corresponde).
El TL no debería cargar solo
Gestión de rotaciones y límites de guardias (EM).
Comunicación externa, decisiones sobre el roadmap y la narrativa de producto (PM).
Acuerdos transversales a toda la organización, negociación política con stakeholders de otros equipos (EM/PM, según contexto).
El TL participa en todo. Pero no “posee” todo.
Diferentes tipos de equipo, el mismo rol
Hasta ahora he hablado de KPIs, SLIs y SLOs de forma relativamente abstracta. En la práctica, su diseño depende en gran medida del tipo de equipo en el que estés. Más concretamente: ¿dónde está el centro de gravedad del equipo?
No suele haber equipos “puros”. La mayoría opera en un punto intermedio. De hecho, si usas el marco de Team Topologies, lo que suele cambiar no es tanto el tipo de equipo, sino su centro de gravedad: algunos equipos están más orientados a construir y operar plataformas y otros a entregar valor directo al producto. El marco es el mismo. Lo que cambia es el foco.
Equipos de Plataforma
En equipos de Plataforma — infraestructura en la nube, componentes compartidos, servicios multi-tenant — , tu usuario principal suele ser otro equipo. Eso cambia cómo defines “bueno”.
Empezando por SLIs y SLOs. Un SLI agregado a nivel global suele ocultar problemas reales. Necesitas visibilidad por tenant, por clúster o por una partición lógica del sistema.
Además, el soporte forma parte explícitamente del servicio. El tiempo de primera respuesta o de resolución puede ser SLO perfectamente legítimo. Lo mismo ocurre con la documentación y el self-serve: reducen los tickets, las interrupciones y la incertidumbre. También forman parte de la fiabilidad.
En este contexto, los KPIs que más palanca le dan a un TL suelen ser internos y operativos:
Número de equipos o integraciones activas.
Volumen de tickets y capacidad de deflexión (cuánto se resuelve sin intervención humana).
Coste unitario: por petición, por tenant o por operación clave.
Ruido operativo: incidencias recurrentes, alertas, carga de guardias.
Estos KPIs no miden directamente el éxito de negocio. Miden si la plataforma es escalable y sostenible a medida que la organización crece.
Antipatrón habitual
Optimizar la estabilidad y el coste sin una señal clara de adopción ni de valor real para los equipos usuarios. El sistema funciona, pero nadie lo usa. La excelencia operacional sin impacto también es deuda.
Equipos de Producto
En equipos de Producto — que lanzan y mantienen funcionalidades orientadas al usuario final —, el foco se desplaza hacia la experiencia de ese usuario.
Aquí, los SLOs (p.ej., disponibilidad) no deberían definirse por servicios o endpoints, sino por flujos críticos: buscar, pagar, publicar, reservar. La latencia media importa poco si el paso clave del funnel es lento o falla. La corrección también se define a nivel de negocio. Un HTTP 200 no sirve de mucho si el resultado es incorrecto.
Esto no significa que en los equipos de Producto no existan KPIs internos. Los hay, y son igual de importantes. Desde la perspectiva del TL, conviven aquí dos planos.
Por un lado, KPIs internos operativos:
Número y severidad de incidencias.
Ruido de alertas y de carga de guardias.
Lead time, frecuencia de despliegue y fallos en producción. (ej. métricas DORA )
Coste operativo por petición o por usuario.
Por otro, señales técnicas muy cercanas al producto:
Sesiones sin crashes.
Rendimiento por dispositivo, versión o segmento.
Errores funcionales que no generan fallos técnicos evidentes.
Estos KPIs internos no sustituyen a los KPIs de negocio, pero los condicionan. Si el sistema es lento, inestable o caro de operar, la conversión, la retención y los experimentos acaban degradándose, aunque al principio no lo sea.
Aquí conviene ser explícito sobre los límites del rol: el PM persigue el resultado. El TL garantiza que el sistema puede perseguirlo sin que se rompa.
Antipatrón habitual
Optimizar la conversión y la experimentación mientras los KPIs internos se degradan. Al principio todo parece ir bien. Luego la velocidad cae en picado y cada cambio cuesta el doble.
El punto común
Independientemente del centro de gravedad, el trabajo del Tech Lead es el mismo: definir qué significa “bueno”, medirlo con honestidad y convertir esas señales en decisiones.
Lo que cambia no es el rol del TL, sino el lugar donde la excelencia operacional genera un mayor impacto.
Un sistema simple que funciona
La mayoría de los equipos no falla por falta de métricas. Falla porque esas métricas no cambian ninguna decisión. No porque no tenga métricas, sino porque no consigue que influyan en el trabajo real del equipo. La clave no es la herramienta ni el nivel de sofisticación, sino cerrar el ciclo: medir, decidir y actuar.
En la práctica, los equipos que lo hacen bien comparten un patrón común: pocos indicadores bien elegidos, objetivos explícitos y una cadencia regular para convertir señales en decisiones. Normalmente esto implica:
Un conjunto reducido de SLIs que representen el comportamiento real del sistema.
Uno o dos SLOs por flujo crítico.
Alertas que indiquen cuándo el sistema de verdad se está degradando.
Una regla clara sobre qué hacer cuando eso ocurre.
Revisiones periódicas que se traduzcan en acciones concretas.
🎁 ¿Quieres aterrizar esto en tu equipo?
A lo largo del artículo he hablado de KPIs, SLIs y SLOs, y de cómo usarlos para tomar mejores decisiones. Pero la diferencia no está en entender los conceptos, sino en ponerlos a trabajar en el día a día del equipo. Para eso he preparado dos plantillas prácticas que uso con los equipos:
Definir KPIs, SLIs y SLOs y dejar claro qué significa “bueno” en tu contexto.
Revisión mensual para convertir esas métricas en decisiones reales, no en dashboards.
No son frameworks teóricos ni recetas universales. Son artefactos simples para cerrar el ciclo: medir, decidir y actuar.
Suscríbete y rellena este formulario para que te los envíe. Gratis.
Nota: si ya has pedido acceso al toolkit de alineación EM/TL, no es algo nuevo que tengas que descargar. Los templates de KPIs, SLIs y SLOs, y la revisión mensual forman parte del mismo documento que ya tienes: el toolkit con el semáforo de autoevaluación, que acompaña al plan de 90 días para Tech Leads.
La excelencia operacional es cómo compras velocidad
Volviendo a lo que contaba en mytaxi, aprendí algo bastante simple: tener razón no sirve de mucho si no puedes mover al equipo. Y mover al equipo no consiste en explicar mejor las cosas, sino en cambiar el marco en el que se toman las decisiones.
Cuando trabajas con SLIs, SLOs y KPIs bien definidos, dejas de pedir fe y de discutir sensaciones. Empiezas a operar con un sistema que hace visibles los trade-offs y facilita la toma de decisiones.
Ese es, para mí, uno de los mayores aportes de un Tech Lead: convertir conversaciones difusas en decisiones repetibles y decisiones repetibles en una velocidad que se puede sostener.
Porque el objetivo nunca fue tener menos incidentes por orgullo técnico. El objetivo es entregar valor de forma constante, sin quemar al equipo y sin vivir con la sensación de que cualquier lunes a las nueve de la mañana puede estallar todo.
— João