Cómo escribir un buen postmortem
Convierte los postmortems en señales de liderazgo con esta guía y plantilla. Muestra impacto, gana visibilidad y acelera tu carrera como ingeniero.
La mayoría trata un postmortem como un ejercicio para encontrar la root cause. Cuando la encuentran, lo dan por terminado.
Lo escriben como si fueran las notas de investigación. Eso sirve para actualizar un ticket, pero es una oportunidad perdida para un documento de alta visibilidad.
Un postmortem no es solo un informe técnico. Es tu oportunidad para demostrar profundidad técnica, pensamiento en sistemas, comunicación de liderazgo, priorización y visión a futuro para tus sistemas.
Por eso las mejores empresas incluso publican sus postmortems externamente. Porque tiene valor y les da visibilidad positiva.
En este post vas a aprender
Cómo convertir incidentes en prueba de liderazgo.
Cómo escribir postmortems que hacen que otros te noten.
Una checklist para tu próximo postmortem para suscriptores premium.
Convierte una crisis en capital profesional
Los incidentes fuerzan visibilidad. Todos observan quién aparece y cómo actúa. Ese es el momento de liderar.
Cuando me ofrecí voluntariamente a escribir un postmortem de un incidente sin dueño claro, tomé control de una situación que podía dañar mi reputación. Entendí la root cause y sabía que podía cerrarlo. Esa acción me convirtió en la cara de la resolución. La percepción importa. Ser voluntario cambió la historia de “quién causó esto” a “quién lo arregló”.
Ya lo había hecho antes. Usé el postmortem como herramienta para moldear cómo liderazgo interpretaba el evento. En mi one-on-one con mi manager no hubo culpa. Tomé acción pronto, di actualizaciones constantes y gestioné la narrativa. Si me hubiera quedado en silencio, el ambiente habría sido de culpa y falta de ownership. Cuando la reputación se daña, demostrar inocencia más tarde ya no importa.
Incluso cuando algunos incidentes solo afectaban a usuarios internos, los traté como problemas de producción. Actualizaciones cada 15 minutos, pasos claros, mentalidad de mitigación primero y un postmortem pequeño para cerrarlos. Esa debería ser la base. Así señalas estándares de senior.
El documento como artefacto de promoción
Muchos ingenieros piensan que el postmortem es papeleo. Yo lo trato como uno de mis artefactos más fuertes. Es visible, duradero y toca todas las señales que liderazgo senior busca.
Estas son las secciones que debe incluir.
Resumen
Va arriba, pero lo escribo al final.
Es un brief de alto nivel para directores y VPs. Lo uso para demostrar entendimiento del contexto de negocio, impacto al cliente y remediación a largo plazo. Lo trato como si fuera un email para mi director.
Gráficos y métricas
Los gráficos deben contar una historia, no solo mostrar números. El primero siempre muestra impacto al cliente, no métricas internas del servicio. Eso marca el tono. Luego anoto deployments, rollbacks y anomalías. También incluyo los gráficos que me habría gustado tener. Eso ayuda a justificar trabajo futuro de observabilidad.
Hice esto en un incidente de alta severidad. Como había debuggeado el mismo servicio días antes, fui rápido leyendo métricas y presentando la señal limpia. Esa habilidad vino de práctica y de tener un proceso repetible.
Impacto al cliente
Muchos ingenieros escriben “2% error rate, 300ms latency increase” y creen que eso es impacto al cliente. Son datos internos. No dicen qué experimentó el usuario.
Siempre pregunto: ¿Vieron flujos rotos? ¿Timeouts? ¿Pagos fallidos? ¿Subieron los tickets de atención al cliente? ¿Bajó el revenue? Si no respondes eso, tu postmortem está incompleto.
Diagnóstico
Aquí demuestras que no estás adivinando. Muestras tu razonamiento. Empiezas con la hipótesis inicial, la evidencia que la confirmó o rechazó y cómo pivotaste.
Una vez seguí un problema de permisos supuestamente parcheado una semana antes, pero nunca entendido, y volvió a ocurrir. Otros pararon en “fix deployed”. Yo fui más profundo. Esta parte demuestra que no solo cierras tickets, sino que resuelves problemas.
Timeline del incidente
El timeline no es una lista de timestamps. Es la historia de cómo reaccionamos bajo presión. Empiezo con qué cambió que llevó al incidente. Incluyo cada retraso y cada fallo. Si esperamos 20 minutos antes de involucrar a alguien, lo dejo claro y explico por qué (“el runbook no era claro, triage retrasado”). No es un fallo. Es una oportunidad de mejora.
Debemos mostrar cuidado por el proceso, no culpa. Señala pensamiento en sistemas, no en individuos.
5-Why
El 5-Why lo creó Toyota para problemas en la fabricación de coches y se popularizó. Empiezas desde el impacto al cliente y sigues preguntando “por qué” hasta llegar a una root cause sistémica. No estás limitado a 5 veces.
- ¿Por qué 1234 clientes perdieron sus pedidos?
Porque el backend devolvió “200 OK” sin persistir en base de datos.
- ¿Por qué devolvió “200 OK sin persistir”?
Porque…Si paras en error humano, pareces inexperto. Ve más lejos y muestra dónde falló el sistema al protegerse.
Cuando reviso un postmortem, busco esto. ¿Por qué ningún test lo detectó? ¿Por qué la alarma era confusa? ¿Por qué no se siguió el runbook?
Otro anti-patrón es meter todo el incidente en un único árbol de 5-Why. Prefiero múltiples cadenas:
Root cause técnica
Prevención
Detección
Diagnóstico
Mitigación
No las necesitas siempre, pero si un incidente dura días, debes analizar los mecanismos de detección.
Follow-ups
Aquí fallan la mayoría. No escribo cosas tipo “mejorar el monitoreo”. Escribo: “Añadir alarma cuando checkout P99 supere 200ms durante 5 minutos. Owner: <persona>. Due: <fecha>”. Claro y con responsables
En un postmortem que presenté a toda la organización, aseguré que los action items fueran precisos y concisos. Sin relleno. Así otros vieron que no nos faltaba nada en esos siguientes pasos.
Los action items no son solo técnicos. Si alguien me ayudó durante el incidente, le doy crédito y etiqueto a su manager. Uso el reconocimiento como herramienta de influencia. Funciona mejor que culpabilizar. También elogio a quienes defienden el valor de escribir postmortems, incluso si otros se resisten.
El proceso del postmortem no es un informe técnico. Es un mecanismo de liderazgo.
Conclusión
Los suscriptores premium tienen la plantilla en los recursos premium. Aquí un adelanto:
Tu manager no ve la mayoría de tu trabajo diario. Pero sí leerá tu postmortem. También el manager de tu manager. También arquitectos y tech leads que influyen en promociones.
La mayoría escribe postmortems para pasar página. Tú deberías escribirlos para subir de nivel.
Un buen postmortem muestra habilidad técnica, pensamiento en sistemas, comunicación, ownership e influencia. No necesitas un proyecto nuevo para demostrar que estás listo para más responsabilidad. Solo necesitas escribir como si ya la tuvieras.
Aquí tienes el enlace a la plantilla, como prometí.
