What Commanding a Mars Analog Mission Taught Me About Leading Engineering Teams
The principles that make a Mars analog mission work are the same ones that make an engineering team work. Not metaphorically. Literally the same principles, applied to different environments.
In early 2026, I commanded Transatlantic MDRS Crew 261 at the Mars Desert Research Station in southern Utah. For two weeks, our international crew lived and worked in a simulated Mars habitat, conducting real science under simulated mission constraints. We grew tomato seedlings in Mars regolith simulant. We ran EVAs (extravehicular activities) in spacesuits across the desert terrain. We operated within communication delays and resource limitations designed to mirror what a real crew would face on Mars.
The mission was covered by CBS and Northwest Aerospace News. It was one of the most demanding leadership experiences of my career. And, maybe unexpectedly, it clarified something I had been thinking about for years: the principles that make a Mars analog mission work are the same ones that make an engineering team work.
Not metaphorically. Literally the same principles, applied to different environments.
Constraint is the default condition
On a Mars analog mission, everything is constrained. Water is rationed. Power is limited. Your crew is small. Resupply is not coming. Communication with “Earth” (mission support) is subject to a simulated time delay, which means you cannot get real-time answers to urgent questions. You have to plan, prepare, and then execute with what you have.
Engineering teams operate under the same fundamental reality, even if it does not feel as dramatic. Budget is finite. Headcount is fixed. Time is limited. The perfect tool or the ideal architecture is not available, and the team has to build something real within the boundaries that exist.
What I have noticed is that the best engineering teams, like the best analog crews, do not fight this. They internalize constraint as a design parameter, not an obstacle. When I work with a company as a fractional CTO, one of the first things I assess is how the team relates to its constraints. Teams that are constantly frustrated by limitations tend to underperform. Teams that treat limitations as givens and focus energy on what they can control tend to ship.
At MDRS, we did not spend time wishing we had more water or a bigger habitat. We designed our experiments and daily operations around the resources available. That mindset made us sharper and more creative. It works the same way in a sprint planning meeting.
Small teams need role clarity, not rigid hierarchy
Crew 261 was an international team. Different backgrounds, different expertise, different working styles. We had a biologist, engineers, a journalist, researchers. In a crew of that size, you cannot afford ambiguity about who is responsible for what. But you also cannot afford rigid hierarchy that prevents people from contributing outside their lane.
The solution is role clarity paired with operational flexibility. Everyone knows their primary responsibility. Everyone also knows that when the situation demands it, they step into whatever gap needs filling. The commander’s job is not to direct every action. It is to make sure the team has the information, resources, and decision-making authority they need to execute independently.
This maps directly to how I think about engineering team structure. In a healthy engineering organization, every person should be able to answer two questions without hesitation: “What am I responsible for?” and “Who do I go to when I need a decision that is above my scope?” If people cannot answer those questions clearly, you have a structural problem that no amount of talent will fix.
At the same time, the best teams have enough trust and context-sharing that an engineer can flag a problem outside their domain, suggest a solution, and have it taken seriously. That only happens when leadership models it. At MDRS, I made a point of asking for input from every crew member on decisions that affected the whole mission, regardless of their formal role. It slowed down some decisions by an hour. It made the outcomes better every time.
Communication discipline is not optional
During our analog mission, crew reports went out daily to mission support. These were structured, consistent, and factual. Not because we enjoyed the paperwork, but because mission support needed reliable information to do their job, and we needed the discipline of documenting what was actually happening versus what we assumed was happening.
I have seen the same dynamic play out in every engineering organization I have worked with. The teams that communicate well, through clear standups, honest status updates, well-written tickets, and direct conversations when something is going wrong, are the teams that ship reliably. The teams that communicate poorly, through vague updates, passive-aggressive Slack messages, and status reports that obscure more than they reveal, are the ones that end up in crisis.
At Microsoft, I managed lead flow systems in the Global Demand Center. The work was technical, but the make-or-break factor was always communication: could we give leadership an accurate, timely picture of what was happening? When we could, decisions were good. When we could not, decisions were late or wrong.
Communication discipline does not mean more meetings or more Slack messages. It means the right information reaches the right people at the right time, in a format they can act on. On an analog mission, that is a daily crew report. In an engineering team, it might be a weekly demo, a well-maintained project board, or a 15-minute standup that actually stays at 15 minutes.
You have to run the experiments you planned
One of the hardest parts of commanding a Mars analog mission is sticking to the science plan when conditions get difficult. Equipment malfunctions. Weather disrupts EVA schedules. A crew member gets sick. The habitat systems need attention. There is always a reason to defer the experiments to tomorrow.
But the mission has a fixed duration. If you defer everything, you come home with nothing. So you learn to protect the work that matters most, adapt when you need to, and accept that some things will not go as planned without letting that derail the mission.
This is identical to the challenge every engineering leader faces with their product roadmap. There will always be production incidents, urgent requests from sales, technical debt that demands attention, and new priorities from leadership. The question is not whether disruptions will happen. The question is whether the team has the discipline and the organizational support to keep making progress on the things that matter most, even while handling the interruptions.
When I work with a company, I look at how well the team protects its core engineering work. If every sprint is consumed by reactive work and the roadmap keeps slipping, that is a leadership problem, not an engineering problem. It means someone is not making hard tradeoff decisions, or worse, is making them by default rather than by design.
The mission has to be real
This is the one that cuts deepest.
Analog missions work because the crew believes in the mission. Not in a vague, motivational-poster way. In a concrete, “I prepared for this for three years and I am going to execute at the highest level I can” way. Our crew trained together for years before we set foot in the habitat. We designed experiments, reviewed protocols, built custom equipment (including a PhotoBioReactor for growing plants in regolith simulant), and held each other accountable long before the mission clock started.
That kind of commitment does not come from compensation or authority. It comes from genuinely caring about the outcome. And it is the single biggest predictor of team performance I have encountered in any context, Mars analog missions, Microsoft product teams, startup engineering orgs, or nonprofit technology initiatives.
As a technology leader, the most important thing I can do is make sure the team understands why the work matters. Not the feature spec. Not the OKR. The actual reason the work exists and what it makes possible for real people. When engineers connect to that, they bring a level of focus and care that no management framework can manufacture.
At MDRS, we were not just growing tomatoes. We were testing whether future Mars colonists could feed themselves using local resources. That context changed how the crew approached every detail of the experiment. In a company, the equivalent might be: “We are not just building a notification system. We are making sure a patient gets reminded to take their medication.” Same work. Completely different energy.
Bringing it back to Earth
I do not bring up the Mars work in every client conversation. Most of the time, what companies need from me is straightforward: technology strategy, architecture decisions, team assessment, AI guidance. The 24 years at Microsoft and the experience building practices at Artic Consulting are what provide the direct pattern recognition for that work.
But the analog mission experience shaped how I think about leadership in ways that are hard to replicate any other way. Living in a constrained environment with a small team, where every decision has immediate consequences and there is no room to hide behind process or politics, teaches you what actually matters. Clear roles. Honest communication. Protecting the important work. Connecting people to the mission.
These are not revolutionary insights. They are the basics. But I have learned, on Mars and off it, that the basics executed with discipline will beat a sophisticated strategy executed loosely, every single time.
