“We’re building software that directly shapes the mission’s success." – Atta Kashmiri, Manager, Spacecraft Software
Mission critical by design
Say hello to Atta Kashmiri, Spacecraft Software Manager at Impulse.
Atta has been building software for aerospace and defense applications, with work spanning fight software, embedded systems, and missile defense, for nearly a decade. Before joining Impulse, Atta gained experience in the industry holding engineering roles at Orbit Fab, Boeing, Lockheed Martin, and Raytheon.
Atta first stepped into Impulse’s factory in 2023 as a Lead Software Engineer. Since then, he’s helped build and lead multidisciplinary software teams spanning radio frequency (RF), embedded, and flight software. In his role as Spacecraft Software Manager, he's part of the team helping develop the tools, infrastructure, and flight-critical systems that keep Impulse's Mira and Helios programs moving forward.
What system or problem do you own?
I’m responsible for spacecraft software, including flight software, embedded software, and Radio Frequency (RF) software. These programs encompass the flight computer and the applications that run the spacecraft, the firmware that spins reaction wheels and drives propulsion hardware, the radios and GPS systems that handle communications and navigation, and more.
At a high level, it’s making sure the vehicle behaves correctly while running multiple systems at the same time – hardware, control loops, radios, mission logic – things that determine how the vehicle behaves in flight.
What’s the most exciting part of that right now?
Right now it’s handling edge cases that only present once we’re on orbit.
We simulate a lot on the ground, but flight inherently introduces combinations of conditions you don’t see until you’re actually there. The challenge is building systems that behave correctly even when the inputs aren’t what you expected.
What does this enable?
Software is the layer that makes everything else usable.
You can have great propulsion, great structures, but if the vehicle doesn’t know where it is or how to respond, the mission doesn’t work. Software is what turns a collection of systems into something that can actually execute a mission.
What’s a decision you’ve had to make that mattered?
Our team had to decide how much autonomy to build into certain failure responses versus relying on ground intervention.
There’s a trade between responsiveness and control: too much automation and you risk unintended behavior, too little and you can’t react fast enough. We ended up pushing more capability onboard because timing matters more than perfect information.
What’s something about this work that people would underestimate?
How much of this job is really about interfaces between systems.
Most problems aren’t one dramatic bug. They’re small mismatches between systems: timing assumptions, state machines that don’t line up, data arriving later than expected, or one layer interpreting a condition differently than another. A lot of good engineering is catching those mismatches early, before hardware or flight finds them for you.
What’s it like to have your hands on real flight hardware?
It keeps you honest.
There’s nothing abstract about seeing real hardware respond to software: motors move, telemetry starts flowing, a radio link comes up, or something behaves differently than it did on the bench or in simulation. That’s also what makes the work satisfying: you’re not building software in isolation, you’re building a system that has to work in the real world.
Are you ready to get your hands on flight hardware? Apply to one of our open roles.
