Above the Clouds, But Not in the Cloud
Software Engineering Behind Rocket Science
We are Stella and Amy. We share firsthand stories at the crossroads of tech, business, and culture, helping leaders craft actionable cross-cultural strategies. Together, we bridge cultural divides and bring the world a little closer—one step at a time.
For many of us, “Rocket science” usually means solving the hardest problems on Earth—or off it. But what's it really like to work in software engineering for a space agency?
In our latest podcast episode, we spoke with Yu, a data engineer and consultant working with the European Space Agency (ESA). She gave us a first-hand look at the surprisingly down-to-earth challenges behind Europe's space missions—and what opportunities it may offer.
Above the Clouds, But Not in the Cloud
One of ESA’s recent projects is a “cloud migration fitness” assessment. Yes—while rockets orbit far above the clouds, the software systems that support them aren’t even on the cloud. The irony is real.
Like many large European institutions, ESA only recently finished digitizing all data that was, until the last decade, stored on paper. Now they’re just beginning to explore moving that digital data to the cloud.
But unlike in the U.S., European agencies often avoid AWS, Azure, or Google Cloud. Instead, they prioritize local providers—names like OVHcloud and Scaleway from France, or Hetzner and Ionos from Germany. It’s part technical, part political, and very much about keeping data sovereignty within the EU.
Software Engineering in Space Is Its Own Beast
Space and rocket science isn’t just about building and launching rockets. Software engineering plays a massive role—gluing everything together behind the scenes to ensure smooth operations. It’s like how tech powers modern logistics, air traffic control, or smart manufacturing—but in space, the stakes (and constraints) are even higher.
Software engineering in space operates very differently from typical tech environments. Take something as simple as timestamps: spacecraft don’t use standard UTC time. Instead, each satellite starts counting time from the moment of launch, using its own epoch and unit—sometimes milliseconds, sometimes nanoseconds. Every mission is different, and the data systems are built to accommodate that.
Another major challenge? The physical systems are in orbit, far above the clouds. Once a satellite is launched, the data it sends back is all you get. You can’t tweak the data generation process or restart the hardware. The software has to work with whatever gets beamed down—often encoded in mission-specific formats that require layers of decoding and translation.
And when something goes wrong? Diagnosing it can be a nightmare. You only get a few windows a day—called “passes”—when the satellite is in range of a ground station. If a command fails or telemetry looks off, the team has to scramble to analyze it and prepare the next fix before the next pass. Sometimes, they even have to consider sending ships to polar stations just to investigate a glitch. It’s root cause analysis with a countdown clock.
Legacy Code: A Business Model of Its Own
Many of the software systems at ESA—and across large European institutions—are built on codebases that have existed for decades. These systems are notoriously hard to maintain, and even harder to staff, as few engineers today are trained in them.
To address this, many organizations are spending real money to decommission outdated systems and rebuild them using modern tech stacks. This work is often outsourced to external consultants—small, specialized firms that can move faster and adopt newer tools without being constrained by decades of institutional process. For these firms, helping legacy-bound giants modernize has become a thriving business—and for many engineers, a strangely stable long-term career path.
Looking Up—From the Ground
What surprised us most in this conversation wasn’t the complexity of satellite telemetry or the outdated UI of mission control systems. It was how familiar it all felt. Beneath the rockets and acronyms, the problems are the same ones engineers face everywhere: legacy code, misaligned incentives, organizational silos, and the constant friction between vision and execution.
Not everyone works with cutting-edge technologies, and sometimes our tasks can feel repetitive or mundane. But Yu's story reminds us that meaning often comes from exactly that kind of work—the quiet, steady effort that keeps critical systems running. It’s a powerful example of how impact doesn’t always look flashy, but it matters deeply.
If you are interested in working with us more closely, we offer tech / business consulting service. Refer to [this article] to see why working with builder-strategists like us is different from traditional business consultants.
Email us at stellaxamy@gmail.com or
Become a member and meet with us monthly.
love these Thanks for these sharing:)