«No quiero los detalles»: la pregunta que cambia equipos técnicos

La pregunta que cambió la forma en que diriges equipos técnicos

Michael Heap, Senior Director of Product en Kong y autor de Building GitHub Actions, estaba en una llamada con su homólogo de ingeniería y el SVP de ingeniería de su organización. Algo había salido mal. Empezó a explicar la cronología de los hechos y fue interrumpido en seco: «Michael, no quiero los detalles».

Lo que parecía desprecio era, en realidad, una declaración de confianza. El ejecutivo asumía que el equipo había sido competente y no necesitaba reconstruir la cadena de decisiones para creerles. Lo que quería era otra cosa: qué iban a cambiar para que esa clase de fallo no se repitiera.

La pregunta «¿por qué pasó esto?» es la más natural después de un incidente. Es también la menos útil si lo que buscas es un sistema que aprenda.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Por qué «entender» el incidente no es lo mismo que arreglarlo

Heap lo formula con una precisión incómoda: cuando un incidente es una secuencia desafortunada pero comprensible, en la que nadie tiene la culpa, nada cambia. Todos asienten, dicen «tiene sentido» y siguen con su día. Seis meses después, el mismo fallo se repite y la organización vuelve a preguntarse cómo llegó hasta ahí.

Una buena explicación, bien hilada, puede ser contraproducente: cuanto más razonable resulta el comportamiento de las personas involucradas, menos urgencia hay para modificar cualquier cosa. La empatía se convierte, sin querer, en el mecanismo con el que la organización se absuelve de tener que cambiar.

El movimiento que apunta a corregir esto se conoce en la industria como postmortem sin culpa (blameless postmortem). La guía clásica, recogida por TechTarget, insiste en que el objetivo declarado de cualquier postmortem es la mejora: «un postmortem adecuado busca aprender y mejorar — no adjudicar culpas». Esto aplica tanto a fallos de proyecto como a incidentes de producción.

Cambia la pregunta y cambia el resultado

La alternativa que propone Heap es directa: en lugar de «¿por qué pasó esto?», pregunta «¿qué estamos cambiando para que esta clase de fallo sea menos probable la próxima vez?».

El razonamiento es simple. Si personas razonables, con buena información y las restricciones correctas, producen un mal resultado, el problema casi nunca está en las personas: está en el sistema que las rodeaba. Corregir a la gente es, con frecuencia, la respuesta equivocada.

La técnica consiste en tomar cada explicación razonable y darle la vuelta:

«No lo detectamos porque Alice estaba de vacaciones y Bob pensaba que el equipo de Widgets era el dueño». Vale. ¿Cómo hacemos que la propiedad sea inequívoca cuando alguien no está disponible?
«Los requisitos cambiaron tres días antes del lanzamiento». Por supuesto que cambiaron. ¿Qué pasa cuando los requisitos cambian dentro de la ventana de lanzamiento?
«La alerta saltó, pero el ingeniero de guardia ya había atendido veinte alertas de bajo valor esa tarde». Lógico. ¿Cómo mejoramos la relación señal-ruido de nuestras alertas?

En cada caso, el foco pasa de la persona al sistema que la puso en esa posición.

Cuando el postmortem es un conjunto de deseos disfrazados de progreso

Heap señala un patrón que cualquier líder técnico reconoce: postmortems llenos de frases como «deberíamos involucrar a soporte antes», «necesitamos comunicarnos mejor» o su favorita, «tendremos más cuidado la próxima vez».

El problema no es que esas frases sean falsas. El problema es que no son acciones: son intenciones. Si tu medida correctiva depende de que alguien recuerde una conversación de hace seis meses, no tienes una medida correctiva, tienes folclore organizacional.

La prueba de fuego que propone Heap es demoledora: «Si todas las personas involucradas en el incidente se fueran mañana de la empresa, ¿la corrección seguiría funcionando?». Si la respuesta es no, el sistema está destinado a fallar aunque el equipo actual haya aprendido la lección.

TechTarget documenta exactamente este tipo de error en su análisis de postmortems: la falta de respuestas concretas es uno de los errores más comunes, y la consecuencia siempre es la misma — «los problemas probablemente se repetirán».

No todos los fallos merecen un proceso nuevo

Hay un punto donde la obsesión por el sistema se vuelve tóxica. No cada incidente justifica una política nueva, un check de compliance o un runbook adicional. Así se construyen entornos en los que nadie quiere trabajar, donde la fricción administrativa supera con creces el coste del fallo que se quería prevenir.

Heap lo admite sin rodeos: a veces, el coste de prevenir la recurrencia es más alto que el coste de aceptar el fallo de vez en cuando. Y eso está bien. Pero hay que hacerlo con los ojos abiertos. La diferencia entre «aceptamos conscientemente este riesgo» y «dijimos que íbamos a esforzarnos más y todos nos sentimos mejor» es la diferencia entre una decisión y un placebo.

Qué significa esto para tu startup

En una startup temprana, donde el equipo es pequeño y los fundadores suelen ser los primeros respondedores, la tentación de entender cada detalle del incidente es enorme — sobre todo cuando el responsable del fallo eres tú. Pero la trampa es doble:

El tiempo de fundador es el recurso más escaso. Reconstruir una cronología perfecta cuando ya entendiste qué pasó te cuesta horas que deberías estar invirtiendo en el próximo experimento.
Una cultura de «vamos a esforzarnos más» no escala. Cuando llegues a 20 ingenieros y los fundadores ya no estén en cada llamada, las buenas intenciones no sobrevivirán al onboarding de nuevas personas. Lo que sobrevive son los procesos, los defaults del sistema y las herramientas.

Tres acciones concretas que puedes implementar esta semana

Cambia la pregunta en tu próxima retrospectiva. Sustituye «¿por qué pasó esto?» por «¿qué estamos cambiando para que esta clase de fallo sea menos probable?». Obliga a que cada item de acción tenga un dueño, una fecha y una verificación posterior.
Audita tu último postmortem con la prueba del «equipo nuevo». Lee el documento de acciones y pregúntate: si todos los involucrados se fueran mañana, ¿el próximo equipo habría prevenido el fallo? Lo que no sobreviva a esa lectura hay que convertirlo en sistema: un guardrail en CI, una alerta mejor afinada, un ownership explícito en el código.
Escribe conscientemente qué riesgo aceptas. Crea una sección corta en tu retrospectiva llamada «Riesgos aceptados». Forzar a escribir «aceptamos este riesgo» en lugar de «intentaremos tener más cuidado» cambia las conversaciones y, con el tiempo, la cultura.