Un proyecto que necesita héroes para cumplir tiene un problema de diseño

El viernes por la tarde, cuando el proyecto vuelve a retrasarse, aparece la persona que conoce cada atajo. Llama al proveedor, corrige una integración, convence a otro equipo para que cambie su prioridad y se queda hasta que el servicio funciona. El lunes recibe agradecimientos. Dos semanas después ocurre casi lo mismo. La organización celebra compromiso; el sistema aprende que no necesita corregirse porque alguien siempre absorberá el costo.

La disposición a ayudar es valiosa. El problema comienza cuando la entrega depende de rescates extraordinarios, horas extra recurrentes o conocimiento que solo una persona conserva. En ese punto, el héroe ya no es una excepción afortunada: es una pieza informal del diseño operativo. Si falta, el trabajo se detiene; si permanece, se desgasta y oculta señales que la dirección necesita ver.

La urgencia puede parecer eficiencia

Un rescate produce un resultado visible: se cumplió la fecha, se recuperó el servicio o se evitó una queja. En cambio, sus costos se reparten y casi nunca aparecen juntos. El especialista interrumpe trabajo planificado, otra tarea se posterga, aumenta la probabilidad de error, una decisión queda sin documentar y el equipo confirma que escalar al héroe es más rápido que mejorar el proceso.

The Phoenix Project, de Gene Kim, Kevin Behr y George Spafford, convirtió esta dinámica en una historia reconocible para operaciones tecnológicas. Su personaje Brent concentra un conocimiento tan decisivo que participa en casi todo; cuanto más imprescindible resulta, más trabajo se acumula alrededor de él. La novela se apoya en ideas de flujo, restricciones y mejora continua: optimizar la ocupación de cada persona no garantiza que el sistema entregue mejor.

La lección sirve fuera de tecnología. Puede haber una única administradora que sabe cerrar la nómina, una editora que repara todos los textos a última hora, un vendedor que resuelve cada reclamo importante o una coordinadora que recuerda compromisos que ningún sistema registra. No hace falta que estas personas busquen protagonismo. Muchas veces protegen honestamente al equipo de un diseño incompleto.

Por qué el heroísmo se vuelve rutina

Las urgencias repetidas rara vez tienen una sola causa. Suelen combinar compromisos asumidos sin capacidad disponible, demasiadas tareas simultáneas, dependencias que nadie gobierna, criterios de terminado ambiguos, cambios tardíos y aprendizaje débil después del incidente. El rescate individual funciona como un puente sobre esas grietas, pero no las cierra.

La investigación de Amy Edmondson sobre seguridad psicológica y aprendizaje en equipos ayuda a entender otra pieza. Un equipo aprende cuando sus integrantes pueden señalar errores, pedir ayuda y reconocer incertidumbre sin temer una sanción interpersonal. Esto no significa ausencia de exigencia. Significa que la verdad operativa puede llegar a tiempo. Cuando advertir “no llegamos con esta capacidad” se interpreta como falta de compromiso, la organización recibe silencio hasta que la crisis ya exige una hazaña.

También importa la confiabilidad organizacional. Karl Weick y Kathleen Sutcliffe describen cómo las organizaciones que trabajan con riesgos altos prestan atención a las anomalías pequeñas, evitan explicaciones demasiado simples y mantienen sensibilidad hacia la operación real. Trasladado a un proyecto corriente: una dependencia que falla dos veces, una aprobación que tarda siempre o una persona convocada a todos los incidentes no son anécdotas. Son datos sobre el sistema.

Hay un límite importante: no toda urgencia demuestra mal diseño. Una emergencia genuina, un evento externo improbable o una oportunidad excepcional pueden justificar un esfuerzo extraordinario. La señal preocupante es la recurrencia. Si el calendario solo se cumple mediante excepciones previsibles, ya no estamos ante excepciones.

Cinco señales de que el rescate ya forma parte del modelo

1. La misma persona aparece en incidentes distintos

No importa si su cargo corresponde al problema. Se la convoca porque conoce la historia, tiene relaciones informales o puede decidir sin seguir el circuito habitual. Su presencia resuelve hoy, pero confirma un punto único de dependencia.

2. La planificación supone horas extra sin nombrarlas

Las fechas parecen posibles porque el cálculo excluye retrabajo, coordinación, interrupciones y aprendizaje. El esfuerzo extraordinario deja de ser una decisión consciente y se convierte en capacidad fantasma.

3. Terminar vale más que entender

Después del rescate solo se pregunta quién ayudó o cuánto tardó. No se reconstruye la secuencia, no se distingue síntoma de causa y no se asigna una mejora con responsable y fecha. El incidente se cierra; la vulnerabilidad permanece.

4. Pedir ayuda temprano tiene un costo social

Quien expresa una duda recibe impaciencia; quien avisa un retraso es acusado de no comprometerse; quien propone reducir alcance debe defenderse. El equipo aprende a comunicar optimismo hasta que ya no queda margen.

5. El conocimiento viaja por memoria y favores

Las decisiones críticas no tienen registro, los procedimientos no se han probado con otra persona y las relaciones con terceros dependen de contactos individuales. Documentar no significa crear manuales interminables: significa que otra persona pueda actuar con contexto suficiente.

Dejar de necesitar héroes sin castigar a quienes ayudan

La respuesta equivocada sería censurar la iniciativa o prohibir que alguien intervenga fuera de su función. El objetivo no es producir indiferencia, sino separar dos momentos: primero proteger a las personas y al servicio; después impedir que la excepción se normalice. Cada rescate relevante debería generar una obligación de aprendizaje para el sistema, no una deuda silenciosa para quien lo sostuvo.

Un método práctico puede comenzar con seis movimientos.

Hacer visible el trabajo real

Registre durante algunas semanas tareas planificadas, urgencias, bloqueos, retrabajo y esperas. No use el registro para vigilar minutos individuales, sino para observar flujo. ¿Cuántas tareas están abiertas a la vez? ¿Dónde pasan más tiempo detenidas? ¿Qué porcentaje de capacidad consume lo no planificado?

Limitar el trabajo simultáneo

Comenzar diez iniciativas no equivale a avanzar en diez. Cuanto más trabajo permanece abierto, más cambios de contexto y más dependencias compiten por atención. Limitar el trabajo en curso obliga a terminar, negociar prioridades y revelar cuellos de botella que antes se resolvían con sobreesfuerzo.

Convertir al experto en multiplicador

Si una persona concentra conocimiento, no la convierta además en autora solitaria de toda la documentación. Reserve tiempo para trabajo en pareja, rotación acompañada, simulaciones y revisión por alguien que no conoce el procedimiento. La prueba no es que el documento exista, sino que otra persona pueda usarlo.

Diseñar una ruta de escalamiento

Defina qué situación se escala, a quién, con qué información y qué autoridad tiene cada nivel. Una ruta clara evita tanto el silencio prolongado como la convocatoria automática de la persona más poderosa o experimentada.

Revisar el incidente sin buscar culpables ni absoluciones

Una revisión útil reconstruye condiciones y decisiones: qué se esperaba, qué ocurrió, qué señales existían, por qué las acciones parecían razonables en ese momento y qué barrera faltó. No debe negar la responsabilidad individual cuando existe negligencia, pero tampoco reducir un patrón sistémico a “alguien cometió un error”.

Cambiar una condición verificable

La retrospectiva termina con una modificación concreta: automatizar una comprobación, reducir una dependencia, aclarar el criterio de aceptación, incorporar capacidad, renegociar alcance o practicar la recuperación. Asigne responsable y fecha. Luego compruebe si la frecuencia o el impacto disminuyeron.

Medir sin convertir el aprendizaje en vigilancia

Para saber si el rediseño funciona hacen falta medidas, pero no un ranking de sacrificios individuales. Pueden observarse la cantidad de urgencias por ciclo, el tiempo consumido por trabajo no planificado, la recurrencia de una misma causa, la proporción de procedimientos probados por una segunda persona y el tiempo desde la primera señal hasta el escalamiento. Estas medidas describen el sistema; usadas para castigar a quien informa un problema, perderán rápidamente su valor.

También conviene combinar números con preguntas breves. ¿El equipo puede rechazar trabajo cuando la capacidad está completa? ¿Las personas saben quién decide ante un conflicto de prioridades? ¿Alguien nuevo puede ejecutar una tarea crítica con la documentación disponible? ¿Una alerta temprana cambia realmente el plan? Las respuestas permiten distinguir una mejora visible en el tablero de una mejora vivida en la operación.

El objetivo no es llegar a cero incidentes, una promesa poco realista en sistemas complejos. Es reducir la necesidad de improvisar siempre del mismo modo, acortar la recuperación y convertir cada dificultad importante en conocimiento compartido. Un equipo confiable no es el que nunca tropieza, sino el que necesita cada vez menos sacrificio oculto para recuperar el equilibrio.

Una conversación para el próximo lunes

El equipo puede revisar los últimos tres rescates con una tabla sencilla: resultado protegido, persona imprescindible, condición que falló, señal previa ignorada, costo desplazado y cambio acordado. Si todos los caminos conducen al mismo nombre, no concluya que encontró a su mejor empleado. Tal vez encontró la restricción más peligrosa del sistema.

La dirección también debe revisar sus incentivos. Reconocer públicamente a quien ayuda es justo, pero premiar solo el rescate y no la prevención enseña qué conducta será visible. Conviene reconocer a quien reduce recurrencia, comparte conocimiento, alerta a tiempo y mejora la capacidad colectiva, aunque su aporte no tenga la espectacularidad de una noche sin dormir.

Google expone principios semejantes en su libro abierto sobre ingeniería de confiabilidad: el trabajo operativo repetitivo y manual debe medirse y limitarse para conservar capacidad destinada a mejoras duraderas. No es una receta universal ni sustituye el juicio del contexto, pero ofrece una pregunta útil para cualquier organización: ¿cuánto talento se consume manteniendo hoy un sistema que nadie tiene tiempo de mejorar?

La pregunta no es si el equipo conserva personas capaces de actuar cuando algo falla. Esa capacidad importa. La pregunta más exigente es otra: ¿qué rescate reciente agradecimos sin cambiar la condición que lo hizo necesario?

Lecturas y fuentes para profundizar

• Gene Kim, Kevin Behr y George Spafford, The Phoenix Project, IT Revolution Press, edición del décimo aniversario, 2023.
• Amy Edmondson, “Psychological Safety and Learning Behavior in Work Teams”, Administrative Science Quarterly, 1999.
• Karl E. Weick y Kathleen M. Sutcliffe, Managing the Unexpected, tercera edición, Jossey-Bass, 2015.
• Betsy Beyer et al. (eds.), Site Reliability Engineering: How Google Runs Production Systems, capítulo “Eliminating Toil”, O’Reilly/Google, 2016.
• Anita L. Tucker, Amy C. Edmondson (2003). Why Hospitals Don’t Learn from Failures: Organizational and Psychological Dynamics That Inhibit System Change. California Management Review, 45(2), 55-72. Fuente original.

Elaborado por Ricardo Gaibor

Este artículo fue elaborado por Ricardo Gaibor con ayuda de sistemas de inteligencia artificial en tareas de investigación, organización y edición. La selección, interpretación y responsabilidad editorial del contenido corresponden al autor.