Una diapositiva que cambió la historia de la comunicación técnica
El 1 de febrero de 2003, el transbordador espacial Columbia se desintegró al reingresar a la atmósfera terrestre, a apenas 16 minutos de completar su misión. Los siete astronautas a bordo murieron. Era la misión STS-107 y, con ella, la NASA vivió uno de los accidentes más devastadores de su historia. La causa técnica fue un trozo de espuma aislante que se había desprendido durante el despegue y había dañado el ala izquierda de la nave. Pero la causa humana —la que convirtió un daño evitable en una catástrofe— fue algo mucho más mundano: una presentación de PowerPoint mal diseñada.
Esta historia no es solo un episodio trágico del programa espacial. Es una lección brutal sobre cómo la forma en que comunicamos la información puede ser tan determinante como el contenido que transmitimos. Y en el mundo de las startups, donde las decisiones críticas se toman con frecuencia apoyadas en decks y slides, las implicaciones son directas.
El despegue, el golpe y el silencio de los datos
El 16 de enero de 2003, el Columbia despegó desde el Centro Espacial Kennedy. Apenas 81,7 segundos después del lanzamiento, un fragmento de espuma aislante de aproximadamente 30 × 60 centímetros se desprendió del tanque externo de combustible y golpeó el borde de ataque del ala izquierda a alta velocidad. Las cámaras lo captaron, pero las imágenes tardaron en analizarse.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadEn los días siguientes, ingenieros de Boeing —contratista principal de la NASA— prepararon una evaluación técnica del impacto. Esa evaluación llegó a los gestores de la misión en forma de 28 diapositivas de PowerPoint divididas en tres reportes. Dentro de esas diapositivas estaba toda la información necesaria para tomar una decisión correcta. El problema fue que nadie la pudo leer bien.
La diapositiva que enterró la verdad en bullets
El análisis más crítico del accidente no lo hizo un ingeniero de cohetes, sino un experto en visualización de datos: el profesor de la Universidad de Yale, Edward Tufte. En su ensayo The Cognitive Style of PowerPoint, Tufte diseccionó la diapositiva clave de Boeing y encontró un fallo de comunicación sistémico.
¿Qué decía esa diapositiva? En esencia, contenía datos de pruebas de impacto que sugerían que el sistema de protección térmica del Columbia podía tolerar el daño. Pero había un detalle fundamental —literalmente enterrado al final de la slide, en fuente pequeña, bajo una avalancha de bullets— que lo cambiaba todo: los ensayos de laboratorio se habían realizado con trozos de espuma unas 600 veces más pequeños que el fragmento real que impactó al transbordador. Es decir, los datos que respaldaban la decisión de seguir adelante no eran aplicables a la situación real.
Tufte identificó varios fallos estructurales en esa presentación que son perfectamente replicables en cualquier empresa hoy:
- Fragmentación de información crítica: el formato de bullets rompió la narrativa causal, impidiendo un análisis de riesgo coherente. Se perdió el hilo de causa-efecto.
- Jerarquía visual engañosa: los encabezados de las diapositivas resaltaban lo que los gestores querían escuchar (tolerancia al daño), mientras el dato más importante (extrapolación fuera de rango) quedaba enterrado en el nivel más bajo de la jerarquía visual.
- Formato sobre contenido: el diseño incentivaba presentar apariencia de rigor técnico en lugar de transmitir incertidumbre real. La slide parecía robusta; la situación no lo era.
- Pérdida de contexto al escalar: a medida que la información subía por la cadena de mando de la NASA, las advertencias y dudas del equipo técnico desaparecían. Lo que llegó a los tomadores de decisión fue una versión pulida que omitía lo esencial.
La conclusión de Tufte fue directa: la presentación debía haber dicho tres cosas con claridad: los ensayos usaron fragmentos pequeños de espuma; el fragmento real era entre 10 y 20 veces más grande; y el equipo no sabía qué daño podría haber causado. Nada de eso quedó claro. Y los gestores de la NASA aprobaron la reentrada.
Las ocho advertencias que nadie procesó
El informe de investigación posterior, de más de 400 páginas, documentó que al menos ocho ingenieros de la NASA habían emitido alertas sobre los posibles daños en el ala durante los días que el Columbia estuvo en órbita. Estas advertencias fueron ignoradas o minimizadas. Los investigadores concluyeron que el problema no era solo técnico: los fallos estaban incrustados en el sistema de la NASA desde hacía 20 años.
Desde 1983, los desprendimientos de espuma aislante eran un fenómeno recurrente. Habían ocurrido en 79 de los 113 vuelos previos del programa de transbordadores sin consecuencias catastróficas visibles. Esa historia de impunidad técnica creó un sesgo de normalización: lo que siempre había salido bien, siempre saldría bien. Y ese sesgo se coló en las decisiones, reforzado por presentaciones que lo confirmaban visualmente.
Qué tiene que ver esto con tu startup
Para un founder, esta historia es más que un caso de estudio histórico. Es un espejo.
En el ecosistema startup, las decisiones más importantes —levantar una ronda, lanzar un producto, pivotar, contratar— se toman con frecuencia en reuniones donde alguien presenta un deck. Un deck donde los datos se seleccionan, simplifican y ordenan para contar una historia. A veces esa historia es la verdad. A veces, sin mala intención, es la verdad conveniente.
Estos son los patrones de riesgo más comunes que replican el error de Boeing en el ecosistema emprendedor:
1. Métricas de vanidad que entierran las señales de alerta
Un deck de inversión puede mostrar un MRR creciente en el encabezado mientras el churn real está en letra pequeña en el apéndice. Igual que la diapositiva de Boeing: el titular dice «todo bien», los detalles dicen otra cosa.
2. Extrapolación fuera de rango
Validaste el producto con 50 usuarios beta en tu ciudad. ¿Eso garantiza escala en todo LATAM? Igual que los ingenieros probaron con espuma de 1/600 del tamaño real: los datos son reales, pero el contexto los invalida.
3. La normalización del riesgo
Llevas seis meses con un cofundador con quien tienes fricciones y hasta ahora no ha pasado nada grave. Eso no significa que no pasará. La historia de impunidad crea una percepción de seguridad falsa.
4. Pérdida de información al escalar
Lo que le dices a tu equipo de producto no es lo que llega al board. Lo que el equipo técnico advierte no siempre llega al CEO. Diseña canales donde la información crítica —especialmente la incómoda— suba sin deformarse.
Cómo comunicar mejor en entornos de alta decisión
La lección de Tufte no es que PowerPoint sea el enemigo. Es que el formato de comunicación debe estar al servicio de la toma de decisiones, no de la apariencia de competencia. Algunas prácticas que founders y equipos pueden adoptar:
- Separa los datos de las conclusiones y presenta ambas explícitamente. No dejes que el lector infiera lo que quieres que infiera.
- Señala activamente las incertidumbres. Las dudas del equipo técnico son información valiosa, no debilidades a ocultar.
- Usa narrativa, no solo bullets. Los documentos de texto con contexto completo (como los famosos memos de Amazon) preservan el razonamiento mejor que una slide con tres palabras por punto.
- Pregunta qué dice lo que NO está en la presentación. Qué datos se excluyeron, qué escenarios no se modelaron, qué riesgos no se nombraron.
- Crea protocolos para las malas noticias. Si en tu empresa solo suben las buenas noticias, tienes un problema estructural, no de suerte.
Conclusión
El accidente del Columbia demostró que en entornos de alta complejidad y alta consecuencia, comunicar bien no es un nice-to-have: es una variable crítica de seguridad. Una sola diapositiva mal diseñada no reemplazó la física, pero sí desconectó a los tomadores de decisión de la realidad hasta que fue demasiado tarde.
En una startup, pocas decisiones cuestan vidas humanas. Pero muchas cuestan empresas, equipos y años de trabajo. La pregunta que vale la pena hacerse antes de cada presentación importante no es «¿se ve bien este deck?», sino «¿entiende quien lo lee exactamente lo mismo que yo entiendo, incluyendo lo que me preocupa?».
Si la respuesta es no, tienes trabajo por hacer antes de esa reunión.
Profundiza estos temas con nuestra comunidad de founders y expertos en Ecosistema Startup
Fuentes
- https://www.xataka.com/espacio/ano-2003-nasa-sufrio-grave-accidente-que-mato-a-siete-personas-responsable-powerpoint (fuente original)
- https://www.edwardtufte.com/notebook/columbia-accident-investigation-board-the-boeing-powerpoint-slide/ (fuente adicional)
- https://www.edwardtufte.com/notebook/powerpoint-does-rocket-science-and-better-techniques-for-technical-reports/ (fuente adicional)
- https://mcdreeamiemusings.com/blog/2019/4/13/gsux1h6bnt8lqjd7w2t2mtvfg81uhx (fuente adicional)
- https://procomm.ieee.org/engineering-by-powerpoint/ (fuente adicional)
- https://es.wikipedia.org/wiki/Accidente_del_transbordador_espacial_Columbia (fuente adicional)
- https://www.infobae.com/historias/2023/02/01/a-20-anos-del-desastre-del-columbia-los-ultimos-segundos-de-vida-de-los-tripulantes-y-los-errores-de-la-nasa/ (fuente adicional)
