Team
Blog
  1. Inicio
  2. Ejemplos
  3. El Columbia en 2003 y el Principio de la seguridad

Ejemplo dePrincipio de equipo #13: Principio de la seguridad

Gobierno y políticaEducación

El Columbia en 2003 y el Principio de la seguridad

Ingenieros de la NASA estaban preocupados por un daño en el ala del transbordador espacial Columbia – pero su petición de imágenes no llegó a su destino, y un correo electrónico de advertencia nunca se envió. El ejemplo muestra el Principio de la seguridad a través del fracaso: un equipo solo aprende cuando nadie tiene que temer reconocer un error o expresar una duda.

Los puntos mantienen su luz oculta hasta que se forma un círculo protector. Entonces las luces suben hacia el centro, y el centro se ilumina.
Principio de equipo #13

Principio de la seguridad: Un equipo solo aprende cuando nadie tiene que temer reconocer un error o expresar una duda.

5 min de lectura5 seccionesSituaciónRelación con el principio
Contenido

Unos 82 segundos después del despegue, un trozo de espuma aislante se desprendió del tanque externo del transbordador espacial Columbia y golpeó el borde de ataque del ala izquierda. Era el 16 de enero de 2003. Dieciséis días después, el transbordador se desintegró durante la reentrada; murieron los siete tripulantes. Entre ambos momentos transcurrieron algo más de dos semanas en las que algunas personas de la NASA intuían que algo no iba bien – y en las que esa duda nunca llegó a donde se tomaban las decisiones. Un ejemplo del Principio de la seguridad.

Bajo una trayectoria de vuelo con una grieta, una advertencia dorada sube y se queda atascada entre los niveles – como la preocupación de los ingenieros por el Columbia.
Bajo una trayectoria de vuelo con una grieta, una advertencia dorada sube y se queda atascada entre los niveles – como la preocupación de los ingenieros por el Columbia.

Un impacto conocido

Situación
El Columbia despegó a las 10:39, hora local, para la misión STS-107. El impacto de la espuma no se detectó hasta el segundo día de vuelo, al revisar las imágenes del lanzamiento. El 21 de enero se reunió un equipo de evaluación de daños con ingenieros de la NASA, Boeing y United Space Alliance. Lo presidían conjuntamente Pam Madera y el ingeniero de la NASA Rodney Rocha. Ya en vuelos anteriores se habían producido desprendimientos de espuma. Se habían convertido en algo habitual.
Relación con el principio
Aquí está la primera trampa. Un fallo que a menudo no tuvo consecuencias acaba considerándose normal. Quien aun así lo señala como un peligro no solo contradice una valoración, sino la experiencia de toda la organización. Así, la duda sale cara antes incluso de que alguien la exprese.

Tres intentos de conseguir una imagen

Situación
Los ingenieros querían imágenes del ala tomadas con medios de reconocimiento militares. Hubo tres intentos: el 17 de enero, el 21 de enero y ese mismo día mediante un correo electrónico de Rocha a su superior. Rocha escribió, en esencia, que sin mejores imágenes ni siquiera se podía acotar el problema. El 22 de enero, Linda Ham, presidenta del Mission Management Team, se enteró de las peticiones. Preguntó quién había presentado una solicitud formal, no encontró ninguna y mandó detener los preparativos del Departamento de Defensa al cabo de unos 90 minutos. Nadie consultó al equipo de evaluación de daños.
Relación con el principio
Nadie prohibió hablar a los ingenieros. Pero su duda no cabía en ningún formulario. No tenía un remitente formal, así que se dio por inexistente. Así puede una organización descartar objeciones sin que nadie las haya rechazado nunca. La comisión investigadora responsabilizó expresamente de ello a la cultura y a la estructura, no a personas concretas.

El correo que nunca se envió

Situación
Rocha redactó otro correo. En él calificaba de rayana en la irresponsabilidad la decisión de prescindir de las imágenes. Mostró el borrador a varios colegas, pero no lo envió – no quería saltarse la cadena de mando.
Relación con el principio
Este mensaje sin enviar es la imagen que resume todo el principio. El conocimiento estaba ahí. La preocupación estaba ahí. Incluso las palabras ya estaban escritas. Lo que faltaba era la seguridad necesaria para hacerlas llegar a los superiores. En 2006, Ingrid M. Nembhard y Amy C. Edmondson demostraron en 23 unidades de cuidados intensivos neonatales que quienes ocupan una posición profesional más alta se sienten más seguros que los demás – y que un liderazgo inclusivo puede compensar esa diferencia. El propio informe de la comisión no emplea el término “seguridad psicológica”; esa lectura llegó después. Pero describe exactamente la brecha entre redactar y enviar.

Tranquilizar en lugar de examinar

Situación
El 23 de enero, el director de vuelo Steve Stich comunicó a la tripulación por correo electrónico que no había motivo de preocupación; ya había habido impactos de espuma antes. El 24 de enero, el Mission Management Team escuchó un resumen: no cabía esperar que el calor perforara el ala; a lo sumo, habría trabajos de mantenimiento. El 31 de enero, en la última reunión, apenas se mencionó el impacto. El 1 de febrero de 2003, a las 8:59, se perdió el contacto por radio. Murieron Rick Husband, William McCool, Michael Anderson, Kalpana Chawla, David Brown, Laurel Clark e Ilan Ramon.
Relación con el principio
Cuanto más subía la información, más tranquila sonaba. “No podemos evaluarlo” se convirtió en “no hay motivo de preocupación”. Donde no se pueden expresar las dudas, estas no se hacen más pequeñas – solo desaparecen de las actas.

¿Quién tiene que demostrar qué?

Situación
La comisión investigadora, presidida por el almirante Harold W. Gehman, presentó el 26 de agosto de 2003 su informe con 29 recomendaciones. Además de la causa técnica, señaló causas organizativas y comparó la cultura de la NASA con la que existía antes del accidente del Challenger en 1986. Contabilizó al menos ocho oportunidades perdidas de detectar el daño. Su conclusión central: los ingenieros tenían que demostrar que la situación no era segura – una inversión de la obligación habitual de demostrar la seguridad.
Relación con el principio
Esta es la lección más contundente. En un equipo seguro, una duda fundada basta para desencadenar una revisión. En uno inseguro, quien duda tiene que aportar primero la prueba – y para ello necesitaría precisamente los medios que se le niegan. Sigue sin saberse si las imágenes habrían salvado a la tripulación; los escenarios de rescate y reparación no pasaron de ser hipótesis. Lo único seguro es que la organización no aprendió hasta que se produjo la catástrofe.
Lo que te llevas

Las lecciones más importantes

  1. Invierte la carga de la prueba. No es quien advierte quien debe demostrar que hay peligro – es quien quiere seguir adelante quien debe demostrar que es seguro.
  2. Pregunta directamente a los expertos antes de frenar una de sus solicitudes. Que no se haya seguido la vía oficial no significa que no haya motivo de preocupación.
  3. Crea un cauce por el que una duda pueda saltarse la jerarquía sin que se considere deslealtad.
  4. Desconfía de la costumbre. Cada vez que oigas “Esto ya nos ha pasado muchas veces”, pregunta: ¿sabemos que es inofensivo o hasta ahora hemos tenido suerte?
  5. En las reuniones, pregunta expresamente por los correos no enviados: ¿qué pensaste y no dijiste?
Resumen

En la misión del Columbia, el equipo sabía del peligro. Pero el rango, la cadena de mando y la costumbre dificultaron que la duda llegara más arriba: la petición de imágenes fracasó y un correo de advertencia se quedó en borrador. La comisión responsabilizó de ello a la cultura y a la estructura, no a individuos. La catástrofe muestra el Principio de la seguridad desde el lado opuesto: un equipo solo aprende cuando nadie tiene que temer reconocer un error o expresar una duda.

Volver a lo esencial

Descubre lo que hay detrás del Principio de la seguridad – con explicación, animación y una invitación a hacer el Diagnóstico de equipo con tu equipo.

Fuente: investigación sobre equipos · Más sobre el origen

Sigue leyendo

Más ejemplos del Principio de la seguridad

De los distintos ámbitos de la sociedad.

Tu siguiente paso

Desarrollo de equipos con WEGVISOR: haz que tu equipo sea eficaz

Leer cambia la forma de pensar. Aplicar cambia los resultados. Elige cómo quieres seguir.

Solicitar Coaching de equipos

Cuéntanos brevemente de qué se trata. Te contactaremos para concertar una cita.

Vienes de: El Columbia en 2003 y el Principio de la seguridad.