Hace unos meses fui arrastrado a una llamada con mi contraparte de ingeniería y su jefe (que resulta ser nuestro SVP de ingeniería). Algo había salido mal y no debería haber sucedido. No catastrófico, pero lo suficientemente importante como para que ahora estuviera en una llamada con un SVP. Empecé a explicar cómo sucedió cuando me cortaron con “Michael, no quiero los detalles”. Continuaron: Sé que si nos ponemos en los detalles, las razones serán perfectamente razonables. Explicarás qué pasó, yo entenderé por qué todos tomaron las decisiones que tomaron, y yo me compadeceré de ti. Así que no quiero los detalles. Quiero saber qué estamos cambiando. Al principio pensé que “no quiero los detalles” sonaba despectivo. ¿Cómo pueden tomar decisiones informadas sin entender los detalles? Luego me di cuenta de que “no quiero los detalles” no estaba siendo despectivo. El ejecutivo asumió que éramos competentes y estaba diciendo “Ya te creo. Ahora hablemos de qué pasa después”.

Preguntar la pregunta correcta

Después de que algo sale mal, la mayoría de las organizaciones preguntan “¿Por qué sucedió esto?”. Esta es una pregunta con la que todos estamos familiarizados respondiendo. Escribimos cronologías. Reconstruimos decisiones. Explicamos dependencias. Al final, entregamos un documento que contiene la combinación específica de eventos que llevaron al incidente. Todos asienten con la cabeza, dicen “tiene sentido”, y continuamos con nuestro día. Entender un problema no es lo mismo que arreglarlo. Una buena explicación puede empeorar las cosas. Una vez que todos están de acuerdo en que el comportamiento fue razonable, la urgencia para cambiar algo desaparece. Cuando un incidente es una desafortunada pero comprensible secuencia de eventos donde nadie es culpable, nada cambia. Entonces, la misma cosa vuelve a suceder seis meses después, y todos se preguntan cómo volvimos a aterrizar aquí. Para impulsar el cambio en tu organización, no preguntes “¿Por qué sucedió esto?”. En su lugar, pregunta: ¿Qué estamos cambiando para que la misma clase de fallo sea menos probable la próxima vez?

Personas razonables

El SVP no estaba interesado en entender cómo sucedió el problema o quién estaba involucrado. No quería convencerse de que todos los involucrados se comportaron de manera razonable. Eso es una expectativa básica. Su pregunta se convirtió en: “Dado que personas razonables produjeron este resultado, ¿qué necesita cambiar?”

Por favor, considere estos ejemplos: “Lo perdimos porque Alice estaba de vacaciones y Bob pensó que el equipo de Widgets era el dueño”. De acuerdo. ¿Cómo hacemos que la propiedad sea inequívoca cuando alguien está indisponible? “Los requisitos cambiaron tres días antes del lanzamiento”. Por supuesto que lo hicieron. ¿Qué sucede cuando los requisitos cambian dentro de la ventana de lanzamiento? “La alarma sonó, pero el ingeniero de guardia ya había lidiado con veinte alertas de bajo valor esa tarde”. Tiene sentido. ¿Cómo mejoramos la razón señal-ruido de nuestras alertas? Nos enfocamos en cambiar el sistema. Las personas generalmente no son lo que necesita cambiar.

Una buena explicación no es un arreglo

Si tu postmortem está lleno de frases como “deberíamos involucrar a soporte antes” y “necesitamos comunicarnos mejor”, o mi favorito personal, “seremos más cuidadosos la próxima vez”, tienes una colección de esperanzas disfrazadas de progreso. Si tu acción correctiva depende de que la gente recuerde una conversación de hace seis meses, no tienes una acción correctiva. Tienes folklore organizacional. Si todas las personas involucradas en el incidente se fueran del empresa mañana, ¿seguiría funcionando el arreglo? Si la respuesta es no, las personas pueden haber aprendido algo, pero el sistema sigue destinado a fallar. Para que un postmortem impulse un cambio duradero, pregunta: Si la misma situación sucediera mañana, ¿qué causaría un resultado diferente? Un proceso que obliga a una decisión en este punto es una mejora. Un sistema que previene esta clase de error es aún más fuerte.

Proceso por proceso

Puedes llevar “el sistema previene esta clase de error” demasiado lejos. No todo fracaso merece un nuevo proceso. Eso es cómo construyes entornos en los que nadie quiere trabajar. A veces el costo de prevenir la recurrencia es más alto...