Seguridad psicológica en TI: del error como culpa al error como dato

En nuestras áreas de TI hablamos de frameworks, SLAs y metodologías… pero poco de las condiciones que permiten que todo eso funcione. Igual que la estructura y la definición de funciones no son un tema menor, la seguridad psicológica tampoco lo es: determina si el equipo levanta la mano a tiempo o si se guarda información crítica cuando más la necesitamos.

¿De qué hablamos exactamente?

Seguridad psicológica es que cualquier integrante pueda hacer preguntas difíciles, reportar un incidente o reconocer un error sin miedo a represalias. No es permisividad: convive con estándares altos y con una cadena de responsabilidades clara. La investigación de Amy Edmondson definió el concepto y lo vinculó con el aprendizaje real en equipos; sin ese “permiso” social, el error se esconde y la mejora se frena. (1)

Por qué importa en TI Cuando trabajas con sistemas complejos, ocultar señales tempranas sale carísimo: sube el MTTR, se ralentiza el cambio y se acumula deuda técnica. No por nada, en Project Aristotle Google encontró que la seguridad psicológica fue el factor #1 del desempeño de equipo. (2)

¿Cómo aterrizarlo?

Postmortems sin culpa. Se analizan causas sistémicas, se documentan acciones con responsables y fechas. Es un pilar SRE porque aprender del fallo, sin cacería de culpables, hace a los sistemas más confiables. (3)

Mide lo que importa. Las métricas DORA - DevOps Research and Assessment, (frecuencia de despliegue, lead time, tasa de fallas por cambio y MTTR) dan visibilidad al flujo y a la resiliencia; son el tablero mínimo para mejorar. (4)

Escucha activa. Equipos que sienten que su voz es escuchada son 4.6× más propensos a dar su mejor desempeño; no es “soft”, es performance. (5)

Mini-guía

Genera un template de postmortem sin culpa; úsala en el próximo incidente.

Muestra en un dashboard las cuatro DORA y revísalas en el daily/ops review.

Implementa un ritual de 15 minutos: “un hallazgo, una mejora y un reconocimiento” a quien levantó la mano a tiempo. (Pequeño gesto, gran mensaje).

Conclusión

Así como definimos roles, autoridad y responsabilidades para que TI opere con sentido, definamos también la regla del juego cultural: aquí los errores se usan como datos. La cultura no elimina fallos; los vuelve más baratos y acelera la recuperación.

 ¿Qué primer cambio harías para que el próximo incidente deje más aprendizaje que cicatrices en tu equipo?

Fuentes

1. Edmondson, A. (1999) — Psychological Safety and Learning Behavior in Work Teams. JSTOR

2. Google re:Work — Understand team effectiveness / Project Aristotle. Rework

3. Google SRE (Site Reliability Engineering) — Postmortem culture (blameless). sre.google+1

4. DORA — The Four Key Metrics / State of DevOps. dora.dev+1

5. Salesforce Blog — Employees who feel their voice is heard are 4.6× more likely…. Salesforce