The Space Shuttle Challenger

January 28, 1986. The Space Shuttle Challenger exploded 73 seconds after launch, killing all seven crew members.

The cause? An O-ring seal failed due to cold temperatures. Engineers had warned about this. They had data. They had concerns.

But they didn't push hard enough. Management overruled the engineers. The launch proceeded.

The lesson everyone draws: "Speak up more."

But that's not the real lesson. The real lesson is about team dynamics, authority gradients, and the systems that enable catastrophic decisions.

The Real Lessons

1. Authority gradients kill.

In aerospace, there's a clear hierarchy. The commander has authority. The pilot has authority. Engineers are "below" them in the decision chain.

This creates an environment where lower-ranked people hesitate to challenge higher-ranked ones. When the engineer says "this might be dangerous" and the manager says "we're launching," the engineer learns not to push.

This happens in every organization. When the senior engineer says "we should do it my way" and the junior engineer has concerns, the junior learns to stay quiet.

The gradient is real. The damage is real.

2. No bad weather, no bad clothes.

That's aerospace terminology for: don't dress for conditions, dress for the job you need to do.

In team dynamics terms: create the environment where speaking up is the right thing to do, regardless of conditions.

If someone needs to be the designated "question-asker," that's their job. Not as an extra task—as a core responsibility.

3. Normalization of deviance.

The Challenger O-rings had experienced "anomalies" before—blow-by, erosion. These had been accepted as normal. No one raised alarms.

This is how technical debt accumulates. Not as dramatic failures, but as slow drifts from standards. Each small deviation seems acceptable. The aggregate is catastrophic.

4. The whole is greater than the sum.

In aerospace, you don't just need smart people. You need smart people who work together. The most important system isn't the engine or the avionics—it's the human system that operates them.

Teams that don't communicate, don't trust each other, don't share information—these teams fail, regardless of individual capability.

Crew Resource Management

After studying crash after crash, aerospace developed Crew Resource Management (CRM)—a system for training teams to work together effectively.

CRM teaches:

Speaking up appropriately. Not just "speak up" (which doesn't work)—specific techniques for raising concerns in ways that are heard.

Leadership that invites input. The pilot who actively asks for concerns, acknowledges them, and responds to them.

Mutual performance monitoring. Team members watching each other's work, catching errors before they compound.

Decision-making processes. Structured approaches to making high-stakes decisions with input from all relevant parties.

This training has dramatically reduced accidents. The same principles apply directly to engineering teams.

The Engineering Parallel

Every software failure has a team dynamics component:

The database migration that wasn't tested. Someone knew it should be tested. Didn't push hard enough. Production failed. Blame was assigned, not root causes addressed.

The security vulnerability everyone missed. Someone raised concerns. They were dismissed as "too paranoid." The breach happened.

The delayed project that everyone knew was delayed. Status reports said "on track." Reality said "failing." No one wanted to be the bearer of bad news.

These aren't technical failures. They're team failures dressed up as technical failures.

What This Means for Engineering Leaders

Create explicit safety nets for raising concerns.

Don't just say "my door is always open." That doesn't work. People don't want to bother the leader.

Instead: schedule explicit reviews where concerns are solicited. Ask specific questions. Follow up on answers.

Make the authority gradient explicit and then flatten it.

Acknowledge that seniority exists. Then explicitly invite challenge from everyone. "I want to hear concerns from everyone, regardless of level. I'll ask for them explicitly."

Watch for normalization of deviance.

Track small deviations. Ask: "Is this drift from standards acceptable, or is it accumulating risk?"

Build mutual monitoring.

Code reviews aren't just about code quality—they're about team members watching each other's work. Make them meaningful.

Practice decision-making.

The way a team makes decisions is learnable. Practice it explicitly. Review decisions after. Learn.

The Hexaco Angle

Personality factors that predict team failure in high-stakes environments:

Low Altruism. Team members who don't naturally help others, who don't feel responsible for collective outcomes.

Low Trust. Team members who assume others are incompetent or malicious.

Low Straightforwardness. Team members who communicate indirectly, who don't say what they mean.

High Anxiety (Emotionality). Team members so stressed they can't think clearly, can't communicate, can't help.

These traits map directly to the HEXACO dimensions. Understanding them helps predict and prevent team failures.

The Human Factor

In aerospace, they call it "the human factor"—the contribution of human error to accidents.

Here's the uncomfortable truth: most "human error" isn't about individual mistakes. It's about team dynamics that enable or prevent those mistakes.

A brilliant engineer can work in a dysfunctional team and produce garbage. An average engineer can work in a high-functioning team and produce excellence.

The team is the system. The system is the product of how people interact.

Invest in team dynamics. Build teams that communicate, that challenge each other, that catch errors before they compound, that speak up when something is wrong.

Because in the end, the difference between a successful launch and a catastrophic failure isn't the technology.

It's the team.

This article is part of the Leadership Unfiltered series on engineering team dynamics. For more insights on building high-performing teams in the AI era, explore LU Teams.