The next fight will be won with software. In this thought-provoking fireside reflection from Prodacity 2025, Kim Crider, Founding Partner of Elara Nova and former CTIO of U.S. Space Force, and Scott Brodeur, Sr. Partner at Partners in Air and Space, Inc., break down the challenges and breakthroughs in modernizing Space Force operations through digital transformation and agile software development.

From years of delayed software programs to new models for integrating commercial tech, Crider and Brodeur discuss the operational realities of space warfare, the shift toward agile acquisition, and why Space Force must rethink how it delivers mission-critical software.

🔹 Key Topics Covered:

• The real-world challenges of software modernization in Space Force
• How traditional acquisitions models fail to meet operational needs
• The lessons learned from canceled programs like JMS
• Why small, empowered teams outpace traditional prime contractors
• The role of commercial software in closing critical capability gaps
• How "Apps to Fill Gaps" is accelerating mission impact

🕒 Key Highlights & Timestamps:
[00:04] - Introduction: Why software is now central to space operations
[02:17] - The evolution of Space Force command & control systems
[07:37] - The failure of JMS & the shift toward agile development
[10:47] - Why the traditional DoD acquisitions process is broken
[12:00] - The power of small, focused software teams solving real problems
[15:43] - Overcoming bureaucracy: How to push past institutional resistance
[19:02] - The rise of SuprCoders & integrated mission deltas
[21:45] - How Space Force is embedding operators in software development
[24:54] - The "Apps to Fill Gaps" initiative & how industry can engage
[26:38] - Final thoughts: How Space Force must adapt to win future conflicts

🔗 Stay Connected:
Learn more about Prodacity: https://www.rise8.us/prodacity
Follow us on X: https://x.com/Rise8_Inc
Connect with us on LinkedIn: https://www.linkedin.com/company/rise8/

👍 Like, Subscribe, and Share:
If you’re involved in defense tech, digital transformation, or Space Force modernization, give this video a thumbs up, subscribe to our channel, and share it with your network. The future of warfighting depends on software—and software depends on speed.

‍

Scott Brodeur (00:04):

So we're standing in between everyone and cocktail hour,

Kim Crider (00:07):

so

Scott Brodeur (00:07):

This will be interesting.

Kim Crider (00:08):

I heard there was line dancing last night, so we'll see what happens tonight. Well thanks Scott. It's really great that you and I get to get back together again. It's been a while.

Scott Brodeur (00:18):

Yeah, this is a fantastic opportunity for me and I'm looking forward to sharing a little bit about how I worked with the team and what we did for a little bit of agile software development.

(00:33):

I retired from the Space Force in late 2022, so I did most of my career in the Air Force. And then the last couple of years, once we set up the Space Force and I had the unique opportunity, as Bryon mentioned, to be a part of a couple of centers that really benefited from software development, agile software development, and struggled with some of our capabilities without having it. Once I retired, I started right away doing some space consulting and well, most of my customers are space force focus, so I support Space Systems Command now, and I don't want to get too, I know this isn't a military audience, but I support the space domain awareness TAP Lab, which stands for tools, applications, and procedures. A little drawback from being in the military is, I'm fluent in acronym, but I'll try to keep that to a minimum.

Kim Crider (01:42):

Yeah, well that's good. So we're going to talk a little bit about that progression. You've been on all sides of this, and I wanted to go back to what Bryon mentioned in the introduction. You were there on the ground floor when the space community stood up, this thing that we called the jpac, and then it became the cpac and you were the director. Tell the audience here a little bit about that. What was that organization responsible for? What were you trying to accomplish? What were some of the big issues that you were getting after?

Scott Brodeur (02:17):

Yeah, so the Joint Space Operations Center, which became the Combined Space Operations Center, was a kind of an epicenter of where we started to leverage space capabilities to integrate into terrestrial war fighting operations. And it was based off of a model that we used in the air domain, so an air operation center. It looked and felt, and it was named exactly like that. We had a strategy division, we had a combat plans division, a combat ops division. It looked and sounded and smelled exactly like an air operation center. The difference was we were space focused, and so we were also, space was an enabler to every domain of warfare, and we had the privilege of integrating things like satellite communications, missile warning detection, position navigation and timing, and GPS, electronic warfare. Those types of capabilities were all planned. They were strategized, if you will, and they were tasked to subordinate units through that op center. And unfortunately, we were a conglomeration of software tools and our weapon system itself was called a OC10.2, which was Kessel Run built Air Operations Center centered software system.

(03:59):

And so it didn't fit, and some of the tools that we used were beholden to some honestly very antiquated software systems. And we were ripe for an upgrade to build a software platform that was going to be custom designed for the space domain and basically integrating space capabilities and tasking those units just like we would in a maritime or air domain. So that was the baseline that when I started working in the business, that was what we were faced with and the acquisitions community of the Air Force Space Command at the time, they looked at a system to replace all of it, and it was, I mean, the genesis of it, everyone was in the right state of mind and they laid out all these requirements that we were going to need to be able to do this mission. And as they formulated and established those requirements, everything changed. We had events happen in space like the Iridium Cosmos collision that caused a huge amount of debris in space. And all of a sudden the things that we were tracking went from low digit thousands to tens of thousands. And then two years later, the Chinese in 2009 launched an anti-satellite missile at their own weather satellite and blew it up and it caused another boatload of debris. And so we went from a set of requirements, that space was pretty benign and then all of a sudden it's not.

(05:52):

And the tool that we had built to do this command and control was wholly inadequate from the get go to be able to serve what we needed to do. And tragically we struggled to deliver. The Air Force struggled to deliver even on that platform. And so if you fast forward, I mean that was early mid two thousands, and then by 2011 I was a major and I was back in the center and we were about to deliver this tool. This tool is actually called JMS, which stood for JSpOC Mission System. And it was a big program of record. It was led by multiple primes, and what they were struggling to do is launch software in an incremental fashion that met the needs and allowed us to discontinue the use of the systems we were using and fail over to the new system. It just wasn't meeting any standards, not even close. I take a break from that type of work and about another, I guess by 2017 I was coming back into the fold to take command to this unit again and the three-star general at the time of Space Systems command, it was still Space and Missile System Center

(07:37):

Was Lt. Gen. JT Thompson. And I remember he was the acquisitions three star and I was working for Lt. Gen. Buck, he was the ops numbered Air Force commander. And I was sitting in a room and we were talking about JMS and we were talking about the next increment that had yet to deliver from 2011 when I was still there before. And so they still hadn't delivered it. So this is like eight or six years later. And so we're dumping millions and millions into the development of this system, and it's become a joke. And so we had this discussion and JT Thompson slaps the table and he is like, I think we've got to cancel it. And there was really, we were kind of like, can we do that even? Are we going to get in trouble? Who's going to jail for this?

(08:38):

So we end up canceling the program and then we started from scratch and the idea was, well, let's talk about the requirements that we need today. And I'm whitewashing a lot of the story, the names and that were associated with this effort. There are numerous, and it was an embarrassment in many respects of Air Force Space command's inability to deliver a software program that we would joke and say, any software company out there could do this no problem. And there were just so many hurdles and so many things that if you weren't one of the primes, you weren't in the decision space.

Kim Crider (09:27):

So I want to talk about what some of these hurdles were, and thanks for that background, and I kind of watched some of this play out too. But you are right in the middle of it and you're seeing it taking years, almost a decade, and you're still not getting the deliveries that you need for the operations that are so critical. Meanwhile, the operational environment is continuing to change. The threat is becoming more and more prominent. You mentioned that there's now much more debris that needs to be tracked. There's collisions that are happening, there's China doing things in space that they're becoming much more active in space. So it's becoming much more problematic. And then you've got this big mission. Your mission is to ensure that these services are available to all these joint combatant commands around the world, that they can get access to satellite communications and GPS and critical imagery capabilities. And that capability can all be protected, but you don't have the systems to allow you to do that command and control, and the whole system is canceled. Now you're sitting there on the ops floor trying to figure out what are we going to do? How are we going to go forward? So what did you guys do at that point?

(10:47):

How did you decide to move forward? And then how did you maybe think about bringing in a new model for rapid software?

Scott Brodeur (10:57):

So we laid out the requirements, which at this time what had changed was the threat on orbit. And so everything became hyper-focused on how do we figure out what's going on in this space domain threat wise? How do we maintain custody of it, determine what it's threatening? And everything became almost laser focused, no pun intended, on the Protect and Defend mission. And we stood up the other op center, the National Space Defense Center, and it had another name before that, but we stood that center up just to do that one mission. So they carved that out of the combined Space operation center. And so the program office, they renamed this effort, they called it Kobayashi Maru, which it still is, the program that it's under today. And the idea was we were going to move away from this incremental delivery to agile support. And I mean, it sounded cool to me, but I had not, honestly, I had no experience in it.

(12:00):

And I was still at the ops center that was supporting terrestrial operations. So the focus now they're dumping money, millions of dollars and all kinds of folks were coming out of the woodwork to bring solutions to the forefront. And my sister op center was the beneficiary of all that. So I'm in my own op center and I'm like, I don't even have a decent map on my, we have a screen the size of the stage that is supposed to be for where the space fight unfolds, and I couldn't get the right tool to just describe to anyone how to make a decision or how to conduct a schema maneuver without having the right software tool. And we were using Microsoft and we were using whiteboards, and it was just crazy. The program office said, listen, we're going to send you a team of guys that are just focused on your problem set.

(13:03):

That's really the culmination of how I came to be here today. That group was under the tutelage of Pivotal software at the time, and then it became VMware. But this group down in Santa Monica, they called themselves Section 31, and it was Carlo and Davis, Gunter and Matt Holland and young officers in the Air Force at the time that were like, Hey, we are agile software developers and we're here to specifically work your problems that they came up to central California where I was. And we just sat down and we mapped out what are your needs right now? And these guys decomposed my problem set in a couple of days. We were doing some mission planning. We'd go have beers, we'd come back, we'd do some mission planning the next day.

Kim Crider (13:59):

Beers are always helpful for that.

Scott Brodeur (14:00):

Yeah, beers are helpful for that. And what they did was they started to produce in this agile framework, applications that were not only time-saving and useful on our ops floor, but I was throwing challenges on them. Look, whatever you deliver to me, it has to work in the Canadian Space Operation Center in the UK space Operation Center in Australia. It has to be exportable. We have to all be looking at the same thing at the same time. And these guys were working in days and weeks, not years and years. And so I went down to their offices and I was telling Kim, this was the first time I'd seen how the other side lives in software development world. And again, money was flowing at the time. So we're in these collaborative workspaces and everyone is working together. And it seemed like they were hyperfocused on my problems and they weren't afraid to ask for help. They weren't afraid to erase the whiteboard from what they were working on yesterday to work on a new problem today or to change their method. And I had never seen anything like it. And I was coming from a military background, I was just like, you guys are just blowing me away of how you're tackling these problems. The system itself still pushed back on the methodology though we did get authorities to operate, which were a bear, to get approvals to install the good work that was being done. The system is meant to push back.

(15:43):

And so no one wanted to believe that a solution would come through this methodology because of the scars we had from our past. And so it was challenging. And for my situation in particular, it was a struggle to, was a struggle to get this small team. Even though we had four or five lines of effort funded, it was hard for them to tackle my hardest problems because those were always going to come from the big program of record. And so even if you went to the CSpOC today, the system that was supposed to be delivered still isn't delivered. It's still, it's under another name called Atlas. And we're still beholden to, I'll even go back one other anecdote. The system that we meant to replace was literally 40 years old in the early two thousands. And it ran, I mean, this is like you're watching Pong, it's like old school screens. And we were so afraid that the computer hardware stacked that it was running on, we could never shut it off. And so we thought if we shut it off, it'd never come back on. So some other software people built another stack to replicate the old school system and ran it in parallel. And then we finally years later failed over to it where that became the primary system. And today that is more stable. We're still running off the old stuff

(17:25):

That's more stable and has out delivered what was meant to deliver back in 2007. So it's just been a wild ride to see the successes that agile development brought yet still live in and fight in a space force that is still struggling to be digital.

(17:53):

It's still struggling to accept solutions that exist today. I mean, we have this penchant for building our own thing or starting from scratch or trying to figure it out ourselves as a government rather than sometimes just buying it that it already exists and you have the talent and you have problems that have been solved that simply could be purchased. But we think of reasons why not to do that.

Kim Crider (18:23):

Yeah, we heard one of the earlier speakers today talk about one of the hurdles sometimes is just trust. And I think you're kind of touching on that a little bit here, this idea of can you really trust that a small group of innovative focused developers can come in, can really understand your problem, and can work with you collaboratively, and then can start to deliver products to you on a regular basis? I mean, it sounds like you saw that happen, you got a taste of that, but the big system doesn't necessarily trust that that could happen.

Scott Brodeur (19:02):

If you talk to those guys, which some of 'em are here today, they'll tell you that the number one thing that they were allowed to do was work autonomously. They had decision space, they had resources, and they were given a problem and told to solve it, and they had access to operators. That was another struggle that our acquisitions mechanism had difficulty understanding what the actual operators wanted and what they needed rather than, Hey, I think I can solve this problem. I think I know what you need. And they would deliver something that just wouldn't either be right or feel right or it didn't flow right. And there were all these kind of user experience things and all kinds of things in the background that just made it feel clunky. And that in the before Agile methodology, that just took forever to get the changes made.

(19:58):

And so the guys that came in for Section 31 were able to create real solutions and they were able to work with operators. In fact, we sent, I don't know if they were, they weren't called Supra Coders at the time, but I sent a couple of my comm cyber guys down to Santa Monica on a sabbatical, and they were all coming to work in t-shirt and shorts. They didn't have to wear their uniforms or anything, and they would develop do this work hand in hand. And it was really cool to see the value that these guys got from understanding and working with the actual hands-on operators to be able to develop what was honestly a much more complete product once it hit the ops floor. Then them just trying to imagine what the solution should be. And so that interface was key. And since we stood up the Space Force, that's been a huge vision realized by General Saltzman and the current leadership team, the acquisitions team, on how we're posturing guardians to be these Supra Coders.

Kim Crider (21:15):

Talk a little bit about that. What has changed, what has evolved? You experienced this a great scenario there where you saw the mission impact, you saw the value, you were part of the process, you saw the benefits of Agile continuous software development, even though it was relatively limited, but what has evolved in the Space force that maybe gives you some hope that we're moving in a better direction, albeit not fast enough?

Scott Brodeur (21:45):

Yeah. I had an experience after I went through a weapon school program and I got sent to a fighter wing for an assignment, and the fighter, the F 16 F 15 community, they paired their ops flying squadrons and maintenance squadrons together. And you could see a dynamic develop between the pilots and their maintainers when it came to aircraft performance, maintenance issues, et cetera. And that linkage led to flying more sorties and having just a better wrap rate for being able to do flying operations. Well, the Air Space Force, excuse me, they've now made the decision to go with what we call integrated mission deltas. And our Delta structure is in the Space Force. It's the largest command element for a mission area. So there will be a Delta and a Delta Commander for space electronic warfare, and there's a Delta and a Delta Commander for ISR operations, and there's one for satellite communications, things like that. So they've decided to make them integrated by taking an ops commander and a acquisitions two colonels, and they put them in charge together to be able to blend the synergy you get from having the two communities blended together under one unit. And so we've done that now for missile warning, we've done it for position navigation, timing, GPS, we've done it for space domain awareness, and we've done it for electronic warfare.

Kim Crider (23:36):

Are you seeing some positives come out of that?

Scott Brodeur (23:38):

Absolutely. So we're now seeing the ability for the ops and acquisitions community to have a much more open dialogue. And if you are an operator, you're stove piped into this thinking that my support system understands what I need in their working diligently to solve my problems. And interestingly, having an acquisitions professional that speaks both languages that can talk back with their own community, just pays huge dividends in bridging gaps that honestly, they're manufactured, but they exist today in the Space Force. There's tension between, and you see it in the news, there's tension between, Hey, our acquisitions community broken, they need to fix it. They're not performing. And the reality is they're working within the boundaries of the left and right boundaries of what they can do. And it's just not, it hasn't been the best environment for this service to deliver the capabilities that are needed and things are changing so fast.

Kim Crider (24:54):

So in the last 15 seconds or so, how would you leave it with this audience here today? What would be your advice to an audience of government program managers and developers, commercial software developers, what would you tell these folks?

Scott Brodeur (25:12):

I'll tell you that, so the primary work that I'm doing today involves people in this audience. It is, we have taken the, what we call the kill chain, the steps that our adversaries would take to deny a space capability. And we've decomposed it into discreet little problems. And we've asked the commercial space community, and this is namely software developers to build application, we call it apps to fill gaps. So gaps that we have in the kill chain, what are those discrete things in the 29 problem statements that we've developed, where can a software company come in and build something that can be used right now put on service and deployed to the op center? And so we just graduated our fifth cohort last week, and we had 104 companies participate since the first cohort. We kicked off number six, cohort six today. And this is an opportunity for people like you to make a huge difference in vulnerabilities and gaps that the Space Force is facing, that we just simply can't deliver on a timeline that's going to give us the capabilities we need to be ready for supposedly any action that China might take in the next double digit months.

(26:38):

Yeah,

Kim Crider (26:39):

Absolutely. Alright, apps to fill gaps. Sounds like a great topic. Discuss at happy hour. Scott, thanks so much for staying in the fight.

Scott Brodeur (26:46):

Yes, ma'am.

Kim Crider (26:47):

For helping to deal with some issues that are still so important and for continuing to move this along. Thank you for being a part of this today, and thank you to the audience for sticking with this. I think

Scott Brodeur (26:56):

We're taking questions afterwards, so if you guys want to talk or ask more questions, we'll be at the Q & A area. Thank you guys very much appreciate you.

‍