El Problema del Rendimiento
Optimizar el trabajo para la visibilidad en lugar del valor está en todas partes, y está destruyendo las organizaciones de ingeniería desde adentro.
¿Qué es el Teatro de Productividad?
El teatro de productividad es la actuación del trabajo optimizado para la visibilidad en lugar del valor. Es el desarrollador que mantiene su IDE abierto toda la noche para que su estado permanezca en verde.
Es el commit dividido en doce fragmentos para que el gráfico de actividad se vea impresionante.
Es el PR apresurado en revisión para que cuente hacia la velocidad de este sprint.
Es la reunión programada para demostrar "colaboración" en lugar de lograr algo.
Es el standup que dura 30 minutos para que todos puedan demostrar que están ocupados.
Cada organización de ingeniería tiene teatro de productividad. La mayoría no se da cuenta de cuánto les está costando.
¿Cuánto Cuesta el Teatro de Productividad?
El teatro de productividad les cuesta a las organizaciones de ingeniería de cuatro maneras: capacidad cognitiva desviada a la gestión de apariencias, confianza erosionada, acumulación más rápida de deuda técnica y la pérdida de los desarrolladores que más quieres retener. La investigación publicada pone números a varios de estos.
Costo #1: Fatiga de Decisión
El teatro de productividad requiere micro-decisiones constantes: ¿Cómo debería parecer productivo ahora mismo?
¿Debería dividir este commit? ¿Se vería mejor un PR más pequeño? ¿Debería quedarme en línea más tarde? ¿Asistir a esta reunión demostraría compromiso? Estas decisiones drenan los mismos recursos cognitivos que el trabajo real1.
Un desarrollador que gasta energía mental en visibilidad tiene menos energía mental para resolver problemas. La mejor ingeniería ocurre en estados de concentración profunda, que el teatro de productividad destruye sistemáticamente.
El costo: capacidad cognitiva desviada de la resolución de problemas a la gestión de apariencias, cada hora de cada día.
Costo #2: Erosión de Confianza
Los equipos que manipulan métricas juntos desarrollan una disfunción peculiar: dejan de confiar entre sí.
Cuando sabes que tus compañeros de equipo están inflando sus números, cuestionas si algo de lo que reportan es real. Cuando estás inflando tus propios números, proyectas ese comportamiento en otros.
El resultado es un equipo donde nadie confía en los datos, nadie confía en sus compañeros y nadie confía en que su trabajo real será reconocido. La colaboración se deteriora porque la coordinación requiere confianza.
El costo: el Proyecto Aristotle de Google encontró que la seguridad psicológica, que la manipulación de métricas corroe, es el predictor más fuerte de efectividad del equipo2.
Costo #3: Acumulación de Deuda Técnica
El código enviado por métricas de velocidad se ve diferente del código enviado por calidad.
Cuando los desarrolladores están optimizando para "commits este sprint" o "historias cerradas", toman decisiones diferentes:
- Omiten la refactorización que facilitaría el siguiente cambio
- Codifican de forma rígida en lugar de abstraer
- Copian y pegan en lugar de generalizar
- Envían sin pruebas cuando el tiempo se acaba
Cada una de estas decisiones crea deuda técnica. El sprint se ve bien. La base de código se pudre.
El costo: el estudio Developer Coefficient de Stripe encontró que los desarrolladores ya pasan alrededor del 42% de su semana en trabajo de mantenimiento: depuración, refactorización y lidiar con código malo3. La presión de velocidad aumenta esa proporción, y la deuda se acumula.
Costo #4: Éxodo de Talento
Los mejores desarrolladores, los que más quieres retener, tienen opciones. Pueden trabajar casi en cualquier lugar.
Y no tolerarán el teatro de productividad. Quieren hacer trabajo significativo, ser evaluados por resultados y gastar su energía en problemas, no en apariencias. Cuando encuentran una cultura de teatro, se van.
Te quedas con desarrolladores que toleran la disfunción, ya sea porque no tienen opciones o porque han aprendido a jugar el juego. Ninguno es lo que quieres.
El costo: reemplazar a un desarrollador senior cuesta de 6 a 9 meses de su salario en reclutamiento, incorporación y productividad perdida4. Los mejores desarrolladores se van primero.
Cómo Se Ve la Transición
Cuando un equipo abandona explícitamente las métricas de productividad y se mueve a la medición basada en resultados, el arco es predecible:
La Caída Inicial
En los primeros 2-4 sprints, el "resultado medible" cae. La velocidad baja. Los commits disminuyen. Los PRs se ralentizan.
Esto asusta a los líderes que esperan mejora inmediata. Pero es esperado: el equipo ya no está realizando trabajo para las métricas. Los números inflados se desinflan a la realidad.
La Recuperación de Calidad
Para los sprints 4-8, los indicadores de calidad mejoran. Las tasas de escape de bugs caen. El retrabajo disminuye. El tiempo de ciclo (entrega real, no entrega de métricas) se estabiliza.
El equipo ahora está haciendo trabajo que permanece. No están enviando rápido y arreglando después, están enviando bien.
La Realidad de la Velocidad
Para los sprints 8-12, emerge una nueva línea base. A menudo, la entrega real es similar o mejor que el antiguo período "productivo", pero ahora es real. Las funcionalidades permanecen enviadas. Los bugs no se acumulan. El ritmo del equipo es sostenible.
El Cambio Cultural
Este es el cambio duradero. El equipo deja de hablar sobre métricas y comienza a hablar sobre resultados. El standup se convierte en "¿Qué enviamos?" no "¿En qué trabajamos?" Las retrospectivas se enfocan en mejora, no en apariencias.
El Desafío del Liderazgo
La caída inicial requiere coraje de liderazgo. Cuando tus tableros se ven peor antes de verse mejor, necesitas convicción de que estás midiendo las cosas equivocadas. Por eso la transición a menudo falla: los líderes entran en pánico ante la caída y vuelven a las métricas de productividad.
La Psicología del Teatro
Entender por qué persiste el teatro de productividad nos ayuda a desmantelarlo.
Sesgo de Visibilidad
Los humanos están programados para notar la actividad visible. Un desarrollador que parece ocupado parece más valioso que uno que parece inactivo, incluso si el desarrollador inactivo está pensando en un problema difícil.
Los líderes caen en este sesgo: promueven, elogian y recompensan el trabajo visible. El trabajo invisible (pensar, aprender, prevenir problemas) pasa desapercibido.
Comportamiento de Protección
En entornos inciertos, la visibilidad es autoprotección. Si vienen despidos, ¿a quién despiden? ¿A la persona que "no hizo mucho el sprint pasado" o a la persona con un gráfico de actividad impresionante?
El teatro de productividad es a menudo comportamiento de supervivencia. Los desarrolladores actúan no porque sean deshonestos, sino porque están protegiendo racionalmente sus carreras.
Gestión por Números
Gestionar humanos es difícil. Los números hacen que se sienta manejable. "La velocidad del equipo aumentó 15%" es concreto, defendible, presentable ante la junta.
Los líderes bajo presión para demostrar resultados se aferran a los números, incluso números que miden las cosas equivocadas.
La Espiral de Goodhart
Una vez que existen las métricas de productividad, son difíciles de eliminar. La gente ha construido procesos alrededor de ellas. Se han creado tableros. Las evaluaciones de desempeño las referencian.
Eliminarlas se siente como eliminar la responsabilidad, aunque nunca estuvieron midiendo nada significativo.
Un Manual para la Eliminación
Si estás listo para eliminar el teatro de productividad, aquí te explicamos cómo:
Paso 1: Nómbralo
El primer paso es reconocer lo que está sucediendo. En una retrospectiva o reunión de equipo, nombra el comportamiento:
"Hemos notado que algunas de nuestras métricas podrían estar fomentando el desempeño por encima de los resultados. Cosas como dividir commits, apresurar PRs o permanecer en línea por apariencia en lugar de productividad. Hablemos de ello."
Esto es psicológicamente difícil pero necesario. Estás dando permiso para discutir lo que todos saben pero nadie dice.
Paso 2: Audita Tus Incentivos
Mapea qué comportamientos fomentan tus métricas actuales:
| Métrica Actual | Comportamiento Deseado | Comportamiento Real |
|---|---|---|
| Puntos de historia completados | Entregar funcionalidades | Inflar estimaciones, apresurar trabajo |
| Commits por sprint | Mantenerse activo | Dividir cambios, commits ruidosos |
| Cantidad de PRs | Entregar incrementalmente | PRs diminutos que fragmentan el trabajo |
| Horas registradas | Trabajar duro | Permanecer en línea, parecer ocupado |
Para cada métrica, pregunta: "¿El comportamiento real es lo que queremos?" Si no, la métrica está causando teatro. La mayoría de estos modos de falla tienen nombres; los catalogamos en Los Siete Pecados Capitales de las Métricas de Ingeniería.
Paso 3: Retira las Métricas Tóxicas
No necesitas un reemplazo antes de retirar una mala métrica. Simplemente deja de medirla.
El miedo es: "Si no medimos commits, ¿cómo sabremos si la gente está trabajando?" La respuesta es: lo sabrás por si el trabajo se entrega y permanece. Esa siempre ha sido la medida real—las métricas de actividad nunca te dijeron nada que realmente necesitaras.
Paso 4: Introduce Métricas de Resultados
Reemplaza las métricas de actividad con métricas de resultados:
| Retira Esto | Introduce Esto |
|---|---|
| Puntos de historia completados | Funcionalidades llegando a usuarios |
| Commits por sprint | Tiempo de ciclo (idea a producción) |
| Cantidad de PRs | Tasa de fallas de cambios |
| Horas registradas | Encuesta de experiencia del desarrollador |
Las métricas de resultados son más difíciles de manipular porque miden lo que realmente importa. Dos de ellas (tiempo de ciclo y tasa de fallas de cambios) son métricas DORA que puedes obtener de integraciones que ya ejecutas en lugar de construir nueva instrumentación.
Paso 5: Comunica el Cambio
Tus stakeholders (ejecutivos, gerentes de producto, otros equipos) esperan "tableros de productividad". Necesitarás explicar el cambio:
"Estamos cambiando de métricas de actividad a métricas de resultados. En lugar de medir cuánto hicimos, estamos midiendo qué entregamos. He aquí por qué: nuestras métricas antiguas eran manipulables, no se correlacionaban con el valor de negocio y estaban fomentando comportamientos contraproducentes."
Algunos stakeholders se resistirán. Prepárate para: "¿Pero cómo sabremos si el equipo es productivo?" Tu respuesta: "Por si entregamos software valioso. Así es como lo estamos midiendo ahora."
Paso 6: Sobrevive la Caída
La parte más difícil son los primeros sprints cuando los números se ven peor. Prepárate a ti mismo y a tus stakeholders:
"Esperamos que el output medible caiga inicialmente mientras dejamos de actuar para las métricas. Esto no es una caída de productividad—es el fin de la inflación. Observa las métricas de resultados; ellas contarán la historia real."
Si entras en pánico y reviertes, has validado que el teatro era necesario. Mantén el rumbo.
Cómo Se Ve el Éxito
Los equipos que eliminan exitosamente el teatro de productividad comparten características comunes:
Enfoque en Resultados
Las conversaciones cambian de "¿Qué hiciste?" a "¿Qué entregamos?" Las actualizaciones de estado se convierten en: "La funcionalidad de búsqueda está en producción y los usuarios la están adoptando" en lugar de "Cerré 12 tickets."
Pronósticos Honestos
Las estimaciones se vuelven realistas cuando no hay incentivo para inflar la velocidad. Los equipos se comprometen a lo que realmente pueden entregar, no a lo que hace que el plan se vea bien.
Ritmo Sostenible
Sin presión para parecer productivos, los desarrolladores trabajan cuando son productivos y descansan cuando no lo son. El resultado es un ritmo sostenible que mantiene la calidad a lo largo del tiempo.
Recuperación de la Confianza
Cuando las métricas no se manipulan, la confianza se reconstruye. Los equipos comienzan a creer en sus propios datos. La colaboración mejora porque la coordinación funciona cuando la información es honesta.
Mejora en la Retención
Los desarrolladores fuertes que se fueron o estaban considerando irse notan el cambio. El equipo se convierte en un lugar donde se valora el buen trabajo—lo que atrae y retiene talento.
El Imperativo del Liderazgo
Eliminar el teatro de productividad requiere coraje de liderazgo.
Necesitarás:
- Admitir que tus métricas actuales podrían estar causando daño
- Resistir la caída inicial sin revertir
- Explicar el cambio a stakeholders escépticos
- Confiar en que tu equipo entregará sin vigilancia
Pero la recompensa es sustancial: un equipo que realmente mejora en lugar de parecer que mejora. Productividad real en lugar de teatro de productividad. Trabajo que importa en lugar de trabajo que cuenta.
Cada sprint que gastas en teatro es un sprint que podrías haber gastado en resultados. El costo se acumula. El talento se va. El código base se pudre.
El mejor momento para detenerse fue cuando comenzaste. El segundo mejor momento es ahora.
Mide la efectividad del desarrollador, no solo la productividad
Seis dimensiones de efectividad. Tendencias a lo largo del tiempo. Perspectivas que ayudan a tu equipo a ver qué está funcionando.
Fuentes
Footnotes
-
Baumeister, R. (2011). Willpower: Rediscovering the Greatest Human Strength — Investigación sobre fatiga de decisión. ↩
-
Google (2015). Project Aristotle — Investigación sobre efectividad de equipos que muestra la confianza como predictor principal. ↩
-
Stripe/Harris Poll (2018). The Developer Coefficient — Estudio de impacto de deuda técnica. ↩
-
SHRM (2022). Human Capital Benchmarking Report — Análisis de costo de reemplazo de desarrolladores. ↩
Continuar leyendo
- Las 6 Dimensiones de la Efectividad del Desarrollador: Un Marco para Medir lo que Realmente ImportaPor qué elegimos estas dimensiones específicas, qué revela cada una sobre el desempeño real de ingeniería y cómo medir resultados transforma a los equipos. · 12 min de lectura
- Tu método ya tiene retrospectivas. Las llama informes de lecciones aprendidas.Te dijeron que Simyl Flow es para equipos ágiles. Es para equipos con fechas y tickets. Si ejecutas fases e hitos, tu método ya contiene cada ceremonia del producto — solo las ejecutas manualmente, en documentos que nadie vuelve a abrir. · 10 min de lectura
- Coaching a Desarrolladores Sin Convertirse en el Gran HermanoLos gerentes de ingeniería necesitan ayudar a sus equipos a crecer. Pero el seguimiento individual crea una cultura de vigilancia. Aquí está la tercera vía. · 12 min de lectura