NASA put out the ARRIVAL study RFI in the fall of 2025 to develop an aerocapture demonstration concept. Aerocapture is the process of using atmospheric drag to capture a spacecraft in orbit around a planet or moon from a hyperbolic trajectory.
We responded to the RFI and won the study contract. I was the system design lead for the study, developing the architecture for the flight (bus & aeroshell) system. I led our engineering team to develop the spacecraft design, driving system level requirements across the team, identifying trade studies between subsystems, and managing the system performance budgets. I also presented the risks of the NASA-proposed CONOPS and potential opportunities the team and I identified for maturing the demonstration CONOPS.
In late 2024 I joined the Carbon-I proposal team as the mission architect, to guide coordination between the JPL mission team and LM spacecraft engineering team.
My primary focus was on marrying the science operations with the spacecraft capabilities, especially the spacecraft guidance, navigation, and control (GNC) system, and the spacecraft power system. While both systems were already well-defined and robust, the Carbon-I mission requires several unique observation modes. Capturing the exact needs and constraints of each mode and validating the spacecraft capabilities was the key challenge. My other focus was on the system interfaces, between the instrument and the payload processor, and between the spacecraft and the ground.
I ended up developing and driving the power performance budget, and wrote the proposal sections for the mission design, the power subsystem, the GNC subsystem, and payload processor. I also wrote the section on system margins, as I had managed the overall spacecraft performance budgets for the proposal.
The Carbon-I Concept Study Report (CSR) was submitted in Fall 2025 with the expectation of a selection in early 2026.
For this program I was the spacecraft bus lead for a lunar orbiting mission, leading the development of the bus architecture and design through PDR.
I architected a two-spacecraft smallsat concept for a lunar mission, defining the bus architecture and the CONOPS with a space startup partner. We presented the concept to the Defense Innovation Unit (DIU) but were not selected.
After GA lost contact with the LINCS satellites and were unable to complete their laser communications demonstration, GA internally funded a rapid development program to replace that mission. The new mission, dubbed "Manhattan", was driven from a single sentence objective from the CEO of General Atomics.
Selected to lead as the chief engineer, I was given a one year timeline to define the program, develop the spacecraft, and deliver the mission. Having learned my lesson in aligning customer expectations early from MAIA, I worked with GA leadership to define a very narrow set of mission requirements and success criteria - and passed System Requirements Review (SRR) in under two weeks.
But even an internally funded program is not immune to scope creep. Despite my efforts to freeze the program objectives early to achieve the breakneck timeline and budget, the executive team began to push down additional payloads and objectives. I left GA around the time the scope changes were mandated, but the Manhattan program has not yet launched to date. It appears that an iteration of the program may launch in 2026.
While the MAIA program was winding down post-CDR, I took over the role of Deputy Chief Engineer for the EWS mission, joining shortly after PDR. EWS was a smallsat program for the US Space Force to replace the aging DMSP satellites and provide weather data for the US military.
The deputy chief engineer role was somewhat dual-hatted - because the chief engineer was located in San Diego while the rest of the engineering team was in Colorado, I was both the lead systems engineer and led much of the day-to-day engineering management. In the role I defined system CONOPS across all mission phases, including LEOP, operations, fault recovery, collision avoidance, and deorbit. I led and reviewed the engineering efforts of a team of systems engineers, maintaining system budgets, requirements, verification, interface control, and artifact generation.
The EWS program was a competitive downselect, with General Atomics and Raytheon competing for the full contract award decision after CDR. While Raytheon was an established incumbent, General Atomics had never delivered a spacecraft for the Space Force. I led the team through CDR, and General Atomics was awarded the contract. Since I've left, GA has won the award for a follow-on spacecraft. The first EWS satellite is expected to launch in 2026.
One week after joining General Atomics, I watched the team's first launch. OTB-1 was a smallsat carrying the Deep Space Atomic Clock (DSAC) for JPL, as well as a number of other small payloads. With such a small team, I volunteered to moonlight as an operator for the mission.
Because OTB-1 was also carrying a payload for the Air Force, we were able to secure a free launch on a SpaceX Falcon Heavy launching out of the Kennedy Space Center. Our free ride meant that we were unable to define the mission orbit, and we ended up a 24° inclination orbit passing through the South Atlantic Anomaly (SAA) nearly every single orbit. This drove a high rate of single event upsets (SEUs) and faults at the spacecraft level.
As the operator, I monitored the spacecraft telemetry after scheduled downlinks, and I was automatically alerted if there was a missed pass or telemetry out of expected bounds. Over the three years I was at GA, I helped recover the spacecraft from safe mode a number of times, ran the DSAC through calibrations, and led a number of failure review boards (FRBs) to investigate the root cause of some of the spacecraft faults we experienced.
In 2025 the OTB-1 mission was declared complete, having outlived its original mission lifetime by three years.
In 2019 I joined the ten-person General Atomics Space team to be the systems engineering lead for the recently-won MAIA mission. The Multi-Angle Imager for Aerosols (MAIA) mission was run by the NASA Langley Research Center to study aerosol distribution in the atmosphere and understand how different types of air pollution affect human health.
The MAIA instrument was being developed by JPL and General Atomics had been contracted to build the smallsat platform. As the lead systems engineer (and the only full-time engineer on the team), I was responsible for the overall system architecture, requirements, and interface definition for the program. I was also the primary technical liaison with the NASA Langley customer and the JPL instrument team, leading weekly system review meetings and interface control definition meetings. While managing the requirements and other program artifacts (mission operations plan, telemetry database, AI&T plan, etc.).
I also was developing the spacecraft performance budgets and performing subsystem analyses where we did not have the personnel. For example, I developed the telecom coverage analysis for the mission in STK + MATLAB, and built the power analysis for the program.
Early in the program, it was clear there was a dichotomy between the Class-D bus defined in the Statement of Work (SOW) and the expectations of the customer. Adding to the challenge was the increasingly costly and delayed instrument that was already an order of magnitude greater in cost than the vehicle. Still, I worked with the customer to accommodate deltas in the expectations, and led the program successfully through the Preliminary Design Review (PDR) and the Critical Design Review (CDR). At the same time, I led the development and delivery of a spacecraft simulator, complete with the bus avionics, ground & operations software, and payload interface to JPL.
While we had been able to impress the customer technically both with our solution and our commitment to delivery, programmatically General Atomics and NASA were unable to resolve the differences between the initial contract and the ultimate expectations of the customer. In 2021 GA and NASA mutually agreed to end the contract.
Frankly, I was devastated - I had spent every hour full-time for two years dedicated to the success of the spacecraft and the mission, and it disappeared overnight. But the program taught me a valuable lesson - a technically successful design and implementation does not always mean a successful mission. From then on I have tried to guide the programmatic and technical risk definition from the very first conversation with customer, to level-set expectations and truly understand their needs, not what is written in the SOW.
The MAIA program is still technically on the NASA books - JPL has partnered with the Italian Space Agency (ASI) to develop the spacecraft. While they initially planned to launch in 2024, the spacecraft appears to still be in development.
In late 2017 I moved from Lockheed Martin RMS to Lockheed Martin Space Systems to work on the Artemis I mission. I took on responsibility for testing the entire return cruise through Entry, Descent, and Landing (EDL) of the Orion spacecraft. Working with the Orion subsystem engineers, I developed and executed test procedures for each phase of the return mission.
Return & EDL was a particularly fascinating mission segment, because the Orion spacecraft performs several critical subsystem "transitions" in this segment. First, as Orion approaches Earth it must transition its comms from the Deep Space Network (DSN) to the Tracking and Data Relay Satellite System (TDRSS). Second, Orion must separate its Crew Module (CM) from its Service Module (SM) prior to reentry. The SM has the solar arrays and the main engine, and so the spacecraft must hand-off from a power-positive flight to a fully battery-powered sequence. It also must transition from the SM main engine to the CM main engine for its final descent burns. Finally, Orion must execute a series of critical sequence of parachute deployments during descent.
These critical handoffs and deployment sequences were often autonomous dependent on the spacecraft configuration and measured data, so there was particular scrutiny on their execution in the test environment. After writing the test procedures, fault mode scripts, and running the tests for hundreds of hours in the lab, I completed the tests for our NASA customer in the final Run for Record (RfR) tests.
In 2022 Artemis I launched, completed its journey beyond the Moon, and returned to Earth safely.
My first job at Lockheed Martin was as a systems engineer on Foreign Military Sales (FMS) programs for the AEGIS missile defense system. My first program was KDX, where I became lead Weapon Control System (WCS) engineer supporting the deployment of AEGIS upgrades to the South Korean Navy. My primary responsibility was to capture requirement changes from the ROKN customer into software updates on the KDX AEGIS baseline, working with our BAE software development partners. It was my responsibility to accurately distill the requirement change the customer wanted, work with BAE to implement them in the software, and rigorously test them and the system to ensure the update met the customer's expectations and did not impact other parts of the system.
The WCS subsystem was one of the most complex subsystems within AEGIS, because it incorporated the Vertical Launch System (VLS), the Close-In Weapon System (CIWS), and the Aircraft Control System (ACS). It also was responsible for determining the kill solution for a given threat, and coordinating the engagement of the VLS, CIWS, and ACS to achieve that kill solution. One of the primary challenges was managing the coordinated response the various weapon systems to a given threat or series of threats, as the system had a complex interlocking of dependencies between the various weapons.
In this role I implemented and tested hundreds of requirements changes, spent over 1000 hours in the AEGIS test facility running stress and endurance tests, and deployed on two Sejong the Great-class destroyers in South Korea.