A $1.7 billion satellite had just launched.
Then, as it began the journey to operational orbit, the engine failed.
I was a first lieutenant and the youngest person on the launch team.
The satellite had been years in the making. More than 400 people were spread across contractors, government teams, facilities, software, and ground infrastructure around the world. We had coordinated the launch exercises, prepared the teams, moved the spacecraft more than 3,000 miles to Cape Canaveral, and gotten it into space.
Then the plan changed.
This wasn't just a technical problem.
For the government, a critical national security mission was suddenly in trouble.
For the contractors, millions of dollars and years of work were tied up in what happened next.
For everyone involved, there was incomplete information and no easy answer.
We couldn't send AAA up to space, and I wasn't the person who could fix a spacecraft.
But I needed to understand what had happened, what it meant, and what we could do next.
So I started talking to people.
What did the failure mean for your part of the mission?
What were you watching?
What worried you?
What did you think mattered?
I had to get close to the facts, understand what they meant, and communicate them clearly enough to be understood, and equally as important not to be misunderstood.
The launch was over.
The real work had just started.
The more I talked to people, the more I realized how many different pieces of the problem were moving at once.
There were technical questions. Operational questions. Contractual questions. Decisions that couldn't wait for perfect information.
My job was to stay close enough to what was happening to keep the picture current.
So I went to the people closest to each piece.
I asked questions. Listened. Went back when something didn't make sense.
Then I did it again.
I wasn't an engineer.
But I needed to understand the engineering well enough to know what mattered vs. what mattered a lot.
Why did this system matter?
What did this reading tell us?
What changed if that component wasn't working?
What could we still do?
What were the trade offs?
That meant learning fast.
Rocket science. Spacecraft operations. Ground systems. Software. Procedures.
And then turning what I learned into something clear enough for people to use.
Sometimes that meant asking the question nobody wanted to ask.
Sometimes it meant going back because I still didn't understand.
Sometimes it meant saying:
Here's what we know.
Here's what we don't.
Here's what it means.
Here's what matters right now.
The anomaly changed what the role required of me.
I had to move closer to the technical details, closer to the operators, and closer to the decisions being made at the top.
I was translating what I was learning, helping frame what mattered, and making sure that senior leaders around the mission had a clear picture of what was happening.
The work became much more strategic—and much more consequential.
The mission recovered.
But the experience stayed with us.
We had learned things the hard way.
What operators needed.
What ground teams needed.
Where the seams were.
What had been assumed instead of understood.
Less than a year later, that firsthand experience became part of the work negotiating the next Operations and Support contract.
The requirements changed.
The way some of the work was structured changed.
And because we had lived through the problem, we had a much better sense of what actually mattered.
That knowledge contributed to changes worth millions of dollars.
I was a first lieutenant when this started.
I left with a lesson I've carried ever since:
You don't always have to be the person with the answer.
Sometimes you need to get close enough to understand what is really happening, ask the right questions, communicate clearly, and help turn what you learn into action.
