El incident terminó hace dieciocho horas. El sistema está estable, el Slack ya no tiene alertas rojas, y ahora toca la reunión que decide si esto vuelve a pasar: el post-mortem. Media hora antes tenías el inglés que necesitabas para apagar el incendio. Ahora necesitas un inglés distinto — el de reconstruir qué pasó sin que nadie se ponga a la defensiva.
Por qué el inglés de un post-mortem es distinto al de un incident call
En el incident call, el inglés que funciona es corto y urgente — decisiones rápidas, dueño claro, siguiente paso. En el post-mortem, ese mismo tono suena a que ya decidiste de quién es la culpa antes de escuchar el timeline completo.
El post-mortem necesita un inglés de precisión y de seguridad psicológica al mismo tiempo: preguntas que reconstruyen los hechos sin acusar, y una estructura que convierte lo que se aprendió en compromisos concretos, no en una lista de buenas intenciones.
Las frases
1. "Let's reconstruct the timeline first."
Antes de discutir causas o soluciones, establece qué pasó y en qué orden. Sin timeline, la conversación salta directo a conclusiones sin evidencia.
Cuándo usarla: En el primer minuto del post-mortem, antes de abrir cualquier otra discusión.
En contexto: "Let's reconstruct the timeline first — I want everyone working from the same sequence of events before we talk about why."
2. "This is blameless — we're looking for gaps in the system, not in people."
La frase que define el tono de toda la reunión. Dicha temprano, cambia lo que la gente está dispuesta a compartir.
Cuándo usarla: Justo después de abrir la reunión, antes de que alguien empiece a explicar su parte.
En contexto: "This is blameless — we're looking for gaps in the system, not in people. If you made a call that made sense with the information you had, that's exactly what we need to hear."
3. "What was the time to detect?"
Mide cuánto tardó el equipo en darse cuenta de que algo estaba mal — una de las métricas más accionables de cualquier post-mortem.
Cuándo usarla: Al reconstruir el timeline, justo después del primer evento que causó el problema.
En contexto: "What was the time to detect here? If it was twenty minutes, that's a monitoring gap worth its own action item."
4. "What was the time to mitigate?"
Distinta de "resolver" — mitigar es detener el sangrado, no necesariamente arreglar la causa completa.
Cuándo usarla: Después de establecer cuándo se detectó el problema, para separar detección de respuesta.
En contexto: "Detection was fast, but what was the time to mitigate? That's the gap between knowing and acting."
5. "What contributing factors do we see?"
Reemplaza la pregunta de "root cause" — la mayoría de los incidentes serios no tienen una sola causa, tienen varias que se alinearon.
Cuándo usarla: Cuando el equipo empieza a converger en una sola explicación demasiado rápido.
En contexto: "The deploy triggered it, sure, but what contributing factors do we see? Why didn't the staging environment catch this?"
6. "What almost went wrong but didn't?"
Identifica los near-misses — las decisiones que salvaron la situación por suerte, no por diseño.
Cuándo usarla: Después de cubrir lo que sí falló, para no dejar pasar lo que casi falla también.
En contexto: "What almost went wrong but didn't? The retry logic held, but it was close — that's worth understanding too."
7. "What would have caught this earlier?"
Orienta la conversación hacia prevención concreta, no hacia arrepentimiento genérico.
Cuándo usarla: Una vez que el timeline y los factores contribuyentes están claros.
En contexto: "What would have caught this earlier — an alert, a test, a review step? Let's name the specific gap."
8. "Is this a process gap or a tooling gap?"
Clasifica el problema para que el action item vaya al lugar correcto — no todo se arregla con más automatización.
Cuándo usarla: Antes de definir action items, para evitar soluciones genéricas tipo "hay que tener más cuidado".
En contexto: "Is this a process gap or a tooling gap? If it's process, no amount of tooling fixes it on its own."
9. "Let's separate what we did from what we wish we'd done."
Evita que el post-mortem se convierta en una reescritura idealizada de la historia.
Cuándo usarla: Cuando alguien empieza a describir la respuesta al incidente con más orden del que realmente tuvo.
En contexto: "Let's separate what we did from what we wish we'd done — the honest version is more useful here than the clean one."
10. "Who owns this action item, and by when?"
La frase que convierte una observación en un compromiso real. Sin nombre y fecha, el 80% de los action items de un post-mortem no se ejecutan.
Cuándo usarla: Cada vez que el equipo identifica algo que hay que cambiar.
En contexto: "We need better alerting on this queue. Who owns this action item, and by when?"
11. "What's the follow-up if this doesn't land?"
Anticipa que los action items a veces no se cumplen, y define qué pasa en ese caso — en vez de descubrirlo en el próximo incidente.
Cuándo usarla: Al cerrar la lista de action items, especialmente los que dependen de otro equipo.
En contexto: "What's the follow-up if this doesn't land by next sprint? I want a checkpoint, not just a deadline."
12. "What surprised us?"
La pregunta de cierre que captura aprendizaje genuino — a diferencia de "what went wrong", que ya se cubrió en el timeline.
Cuándo usarla: Al final de la reunión, antes de cerrar.
En contexto: "Last question — what surprised us here? Sometimes the biggest lesson isn't the bug itself, it's what it revealed about how the system actually behaves."
Cómo practicarlas
Estas doce frases no sirven si las reconoces al leerlas pero las buscas cuando el post-mortem ya empezó. El Commit Method entrena producción oral activa para este tipo de reunión — facilitar en inglés, en tiempo real, con el equipo mirándote — hasta que las frases salen sin pensarlas, no solo cuando las repasas en un artículo.