The Mission Control Interconnected Mindset & Katherine Johnson's Example

On July 20, 1969, the world watched as Neil Armstrong stepped onto the surface of the moon. But behind that singular, iconic moment stood a room full of significant people in Houston, Texas, wearing headsets, staring at consoles covered in indicator lights, and managing a web of information so complex and so fast-moving that a single missed signal could have meant tragedy.

They were the team that most people don't think of, the Mission Controllers of NASA's Apollo era. One major key to their insane success was the fact that they operated at a level of interconnectedness that remains staggering to consider even today.

Literally Reaching for the Stars

The Apollo program was unlike anything humanity had attempted before. I know all the "good people" know this, but just to recap because it can't be understated. The stakes were existential. Three human beings strapped to the top of a rocket, launched into the vacuum of space, aimed at a body 240,000 miles away — and the expectation was not just that they would survive, but that they would succeed. The pressure to achieve the goal and do it safely was higher than it had ever been in any endeavor, anywhere, by anyone.

Mission Control, the room, the huge computer that at the time took up a large section of the building, and the team, were built to meet that pressure. Every system on the spacecraft had a light indicator on the ground, in the mission control room. Every critical function on the spacecraft had a backup. Controllers listened to multiple channels at once through their headsets — telemetry, astronaut communications, engineering loops — so they could stay in the loop on anything and everything that happened, the moment it happened. They weren't just monitoring; they were immersed. They were saturated in real-time information because the cost of not knowing at any point in the mission was unacceptable.

And it worked, despite the multiple alarms that went off during the decent to the Moon, the Mission Controllers collaboratively made the right decision to "go" and still land on the Moon. Their close-knit teamwork resulted in every Apollo mission being a success. Every single one. Including the one that nearly wasn't...

Apollo 13: The Ultimate Test of Interconnectedness

When the oxygen tank exploded on Apollo 13, nobody on the ground knew exactly what had happened. The crew reported a "bang." The telemetry told a story of failing systems. But the actual cause — the root issue — was not known during the mission and no one knew how bad it was until the mission was over. They were troubleshooting blind, working from symptoms that changes constantly, not from a diagnosis.

And yet, calmly and decisively, Mission Control worked through hundreds of issues. Power management. Carbon dioxide scrubbing. Trajectory corrections. Reentry procedures. One problem after another, one calculation after another, one solution after another — without ever fully understanding the root cause, they brought those three brave Americans home.

When you stop and think about that, it truly is astounding.

For Apollo 13, everyone was on deck. But the truth is, even when there wasn't a crisis, Mission Control operated as a culture of interconnectedness. It was natural for anyone to talk to anyone if needed. Their communication wasn't governed by strict rules, procedures, or managerial permissions. You didn't need to file a request to speak to someone in another group in order to work on something together. You didn't need approval to walk across the room and ask a question. You just did it, because the mission mattered more than the org chart.

They strategized. They calculated. They worked together. And the interconnectedness wasn't a byproduct of the work — it was the foundation that made the work possible.

"There's No Protocol for a Man Circling the Earth Either"

In Hidden Figures, Katherine Goble Johnson makes a case that she needs to attend the high-level briefings on the Mercury program. The capsule's data, she argues, changes constantly, and if she's doing the calculations that determine whether John Glenn comes home alive, she needs to be in the room where those changes are discussed — not informed after the fact.

A colleague tells her there's "no protocol" for women attending those meetings.

Her response is one of the great lines in the film: "There's no protocol for a man circling the Earth either, sir."

But beneath the memorable delivery is a deeper point. Katherine isn't asking to attend the meetings for status. She isn't asking for a seat at the table for the sake of the seat. She's arguing that she needs to be more interconnected in order to do her job well. She needs the real-time flow of information. She needs to hear the changes as they happen, ask questions in the moment, and understand the context behind the numbers — because the numbers she produces are only as good as the information she receives.

Many argued at the time that she was already interconnected enough — that being briefed after the meetings, receiving summaries, getting the updates secondhand, was sufficient. She disagreed. She recognized a fundamental truth: there is a difference between being informed and being interconnected. Being informed is passive. You receive what someone decides to give you. Being interconnected is active. You're in the flow. You see the information as it moves, you hear the reasoning behind the decisions, and you can contribute, question, and adjust before the course is set.

Katherine knew that the distance between "informed after the fact" and "interconnected in real time" could be the distance between a capsule landing safely and one that doesn't come home at all.

The More Interconnected, the More Productive

Here's the broader principle, and it applies far beyond NASA: the more a company is interconnected, the more productive it is.

When information flows freely across teams, people make better decisions. When the person building the product understands how the customer uses it, the product gets better. When the person answering customer questions knows what's changing in the codebase before it changes, the answers get faster and more accurate. When the person writing the documentation sees the bugs being fixed in real time, the documentation stays relevant.

Interconnectedness eliminates the gaps — the gaps between what one team knows and another team needs, between when a change is made and when the people affected by that change find out, between when a problem starts and when the right people are brought in to solve it.

But here's the critical part: higher levels of interconnectedness should not come because the product broke. They shouldn't come because there's a massive bug in the software, or because a new feature was released and triggered a backlash, or because something went wrong and now everyone is suddenly on deck, sharing information in a war room, communicating across teams at a pace and openness they never exhibited before.

Those times will always require more. Crises will always force interconnectedness. But companies and teams should not wait for the crisis. They should always find ways to be more interconnected — especially when individuals are asking for it in order to do their jobs better.

Because if someone is asking to be more connected, it means they've already identified a gap between what they know and what they need to know. And that gap is already costing the company something — slower responses, outdated information, missed opportunities, avoidable mistakes.

Asking to Be in the Room

I've lived this. In my role as an integration specialist, I found myself in a position not unlike Katherine's. I was the person customers came to with questions about our integrations. I was the person who trained them. I was the person who troubleshooted when things broke. And yet, I was finding out about changes, fixes, and enhancements to those integrations after the fact — sometimes days after, sometimes when a customer asked me about something I hadn't even heard of yet.

I was informed. But I wasn't truly interconnected.

So I asked to be a part of QA testing for integrations. Not to test for testing sake, not to take away from the QA process, but to be in the room — to see the changes as they were being made, to learn about fixes and enhancements earlier in the process, to understand what was coming before it landed.

The impact was immediate and tangible.

When I'm involved in QA testing, I know what's changed ahead of time. I know what's been fixed and have time to process. I know what's been enhanced and have space to figure out how this will impact the customer before it hits the customer. That means when a customer asks me a question, I'm not scrambling to catch up — I already know. I can answer with confidence and accuracy because I watched the integration behave in testing. I saw the edge cases. I know what it does well and where it still struggles.

When I'm involved in QA testing, I can train customers better because I understand the integrations on a deeper level. I'm not training them on last month's version of the integration or a superficial level of understanding — I'm training them on what the integration actually does now, because I've seen it with my own eyes in detail.

A deeper knowledge of how something works, allows you to be more effective at helping your team win at what they want to win at.

When I'm involved in QA testing, I can troubleshoot faster. When an integration breaks for a customer, I've often already seen similar behavior in testing and know the details of what makes that happen. I know what the logs look like when a specific failure occurs. I know which questions to ask and where to look first.

And — critically — when I'm involved in QA testing, I know which knowledge base articles need to be updated, and what those updates need to be. I can plan time to make those changes before the release goes out, not after a customer finds the outdated article and gets confused. I'm not reacting to documentation rot. I'm preventing it.

But the benefits go beyond my own role. Being involved in QA testing gives me a voice in the process itself. I can ask questions during testing — why does it behave this way here? I can make suggestions for changes that will benefit the customers who use the integrations. I can advocate for better logs, better error messages, better diagnostic tools — the things that will make troubleshooting faster and less painful when the integration does break, because it will break. Everything breaks eventually. The question is whether you've built the tools to fix it quickly.

Companies and teams benefit from allowing individuals who want to help more, know more, and be involved more like Katherine.

Instead of being fire-hosed on release day — flooded with urgent messages, scrambling to understand a change I was never told about, trying to reconstruct what happened from fragments after the fact — I have time to evaluate the changes. I have time to grasp what's happening and how we'll need to adjust our troubleshooting methods when issues arise. I'm not reacting in real time to something I've never seen before. I've been watching it. I've been asking questions about it. I've been testing it. I've been preparing for it.

Because I'm involved in the process — not just a receiver of the output.

That's the difference. Being a receiver of the output means you're always one step behind. You find out what changed after it's already changed. You find out what broke after it's already broken. You find out what the customer is confused about after they're already confused. You're always catching up, always reconstructing, always translating someone else's work into your own understanding after the fact.

Being involved in the process means you're already there. You saw the change being made. You watched the integration behave in testing. You asked the developer why it works a certain way. You suggested a better log format and they implemented it. You identified the knowledge base article that needs updating and you planned time to update it — before the release, not after the support tickets start rolling in.

You're not fire-hosed. You're prepared, and you feel a greater sense of value.

The Lesson Mission Control Still Teaches

Mission Control didn't wait for a crisis like Apollo 13 to start talking to each other. They were already talking. The headset was always on. The channels were always open. The person across the room was always accessible. When the crisis came, they didn't have to build interconnectedness — they had to use it.

That's the model. Not a war room that forms when something breaks. Not a Slack channel that lights up when a feature fails. Not an all-hands meeting called after the backlash. Those are reactions. Interconnectedness is an offensive practice.

It's the practice of letting people into the rooms where decisions are made. It's the action of sharing information before someone has to ask for it. It's the practice of saying yes when someone says, I need to be more connected to do my job well — and meaning it.

Katherine Johnson needed to be in the briefing because the data changed constantly and her calculations depended on the latest data. She didn't need permission to care about the mission. She needed access to the information that made her work accurate.

The people in your company who are asking for more interconnectedness are not asking for a favor or special treatment or permission to veer out of their lane of responsibilities. They're telling you they've found the edge of what they can do with the information they currently have — and they want to do more to help the company succeed more. They want to be more accurate, more prepared, more useful. They don't want to be fire-hosed on release day. They want to be in the room where it happens, so that when the release comes, they're already ready ahead of time to be the most effective at their job.

Mission Control brought Apollo 13 home because they were already connected before the explosion. The time to build interconnectedness is not when something goes wrong. It's now. It's always now, on going. Because the mission — whatever your mission is — depends on it.