Houston, We Have a Process Problem

I have been watching the Artemis program with a lot of interest lately. There is something inherently captivating about the sheer scale of returning to the moon—the physics, the hardware, and the high-stakes coordination of thousands of people—quiet voices, crisp callouts, zero drama.

It felt oddly familiar, and not just because I’ve spent way too many evenings geeking out over rocket launches.It reminded me of the exact same feeling I get when I watch an F1 pit crew swap tires in under three seconds. I wrote about that a while back—how a bunch of people in matching fire suits somehow move like a single organism with zero wasted motion. Same vibe here in Houston. Everyone is calm, everyone is clear, and everything just… works.

Here’s what stood out to me, and why I think software teams (mine included) could steal a few pages from the playbook without turning into a full-blown space program.

Everyone communicates factually

In mission control you don’t hear “I feel like the trajectory looks okay.” You hear “Telemetry confirms velocity is ..."

In software, we are often plagued by "vague-speak." In a typical standup we hear "I'm making progress on that ticket." "It's mostly done." "I ran into some stuff but I should have it by end of week." We tell stakeholders a feature is "almost done" or "in progress."

When everyone communicates factually, you eliminate the mental overhead of trying to decode what someone actually means. It’s not about being a robot; it’s about providing the team with a clear, unvarnished state of reality so the right decisions can be made.  Which leads right into my next point...

Decisions are made with data

Go/no-go polls aren’t a democracy—they’re a data check. The flight director doesn’t guess; they aggregate the facts and move.

In software we love to debate architecture in endless meetings or ship features because “the stakeholder really wants it.” I’ve sat in too many of those rooms. We choose frameworks because they’re trendy or pivot architectures because a VP read a blog post over the weekend.

If you do not have the data to make a good decision, that is useful information too — it means you need to go get it before proceeding, not proceed anyway and hope for the best.

There’s a plan, everyone knows their part, and they know exactly what

The flight plan isn’t a suggestion—it’s the shared truth. Every controller knows the timeline, their responsibilities, and what the team upstream and downstream needs from them at any given moment. When the call comes, they’re ready. No “wait, whose job was that again?”

Sound familiar? It should. I’ve seen the exact same coordination in those F1 pit stops I mentioned earlier. One mechanic doesn’t wait to be told to grab the wheel gun; they already know the sequence.

Software projects rarely get that level of choreography. We have roadmaps and Jira boards, sure, but too often the “plan” is a living document that changes hourly and nobody is quite sure who owns what until something breaks. The result? Context switching, surprises at demo time, and that special kind of exhaustion that comes from constantly re-aligning. 

Software development does not need to be as meticulous as running a crewed lunar mission. Nobody is going to die if a microservice runs a little hot or a deploy takes an extra ten minutes. We’re not in that league.

But the ad-hoc approach we’ve normalized—winging requirements, making architectural calls on the fly, treating “we’ll figure it out in the sprint” as a valid strategy—costs us more than we admit. Slower delivery. More bugs. More rework.