How do you close the gap between mission needs and software delivery in the U.S. Space Force? In this candid fireside chat from Prodacity 2025, Carlo Viray (Rise8), Paul Contoveros (Space Operations Command), and Lt. Col. Jeremy “JJ” Homan (Space Operations Command) break down the challenges of modernizing mission-critical software, overcoming acquisitions roadblocks, and accelerating innovation in defense.

From shifting operational mindset to integrating acquisitions & development, this discussion offers a rare inside look at how Space Operations Command is transforming its approach to digital capabilities, software sustainment, and mission-driven technology.

🔹 Key Topics Covered:

• Why operators & acquisitions teams must collaborate early for mission success
• Common bottlenecks in defense software development—and how to fix them
• How Space Force is building its own software capabilities inside operations
• The critical role of value stream mapping in identifying mission priorities
• Metrics that actually matter in closing the gap between capability and threat
• How small, incremental software improvements can deliver massive impact

🕒 Key Highlights & Timestamps:
[00:03] - Introduction: Why bridging the gap between ops & software matters
[05:09] - The mission of Space Operations Command & its modernization challenges
[06:27] - Biggest bottlenecks in defense software development
[08:28] - How Space Force measures success in closing the capability gap
[10:26] - Real-world example: Optimizing space domain awareness through software
[12:24] - Why modernization must be incremental—not monolithic overhauls
[14:57] - The evolution of Space Force’s software acquisition approach
[17:42] - From “innovation” buzzwords to real mission-driven change
[19:45] - Building a collaborative, outcomes-focused acquisitions model
[21:39] - The future of Space Force software: Building prototypes before defining requirements
[22:42] - If you had a magic wand, what would you change?
[25:34] - Final advice: Don’t go it alone—connect with like-minded change agents

🔗 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 tackling defense software transformation, acquisitions reform, or mission-driven innovation, give this video a thumbs up, subscribe to our channel, and share it with your network. The future of warfare depends on software—and software depends on collaboration.

‍

Carl Viray (00:03):

Before we actually get started, I don't know how, it's kind of surprising to me that we're in Nashville, we're on a stage and not one person has asked Nashville, how are y'all doing? So if you all would just kind of humor me, a mild woo will suffice. I just want to do this once in a lifetime thing. Nashville, how are y'all doing today? Much better than mild. I appreciate it. I appreciate it. Alright, so before I let these gentlemen introduce themselves, for those that know me, I'm Carlo Viray. I'm the director of growth at Rise8. I am really excited to host this fireside reflection though because as a former government program manager and software product leader, I found myself very much at the intersection of acquisitions, requirements and operations. Dealing with that friction, intentional and unintentional friction, and often dealing with a lot of chaos.

(00:54):

So I'm excited to see in here from Paul and JJ how they're approaching that. We had two great talks on value stream mapping and system modernization, which I think is a tale as old as time in the government, especially when it comes to software delivery and transformation. And really what we want to focus here on is how do we think about bringing the mission closer to software delivery and how do we think about bringing software delivery closer to the mission. So with that, Paul, JJ, if you don't mind, just briefly introduce yourselves, your role and maybe one thing that you're hoping that the audience can take away from what you're about to share with us today.

Paul Contoveros (01:27):

Yeah, sure. So, hey, good morning everybody. So Paul Contoveros, career space operator. As Bryon mentioned, I'm probably, I'm the least likely person to be here, frankly. So I got a degree in criminology. So of course the Air Force made me a space operations officer, so that was fun. Learning how to become a space operations officer was interesting with my background, but thankfully Air Force training is excellent and even this knucklehead was able to figure out how to fly satellites across my career. It's been interesting to see this tension between ops and acquisitions. As an operator, I'm needy. I want it now. I want it fast, I want it accurate, I want it lethal. I want all these things. And growing up as an operator, when we start early in our careers, having touchpoints with the acquisitions community, we don't know how acquisitions software, the DOD software acquisition pathway, DevSecOps, agile, Kubernetes operators don't know any of that ****.

(02:37):

And they don't care. They don't. They just want the product. So from an operator's point of view, starting off in this directorate and being basically the first person to be in the director of innovation, before we became the combat force enhancement branch, my learning curve was just steep. But the proof in the pudding is that if a knucklehead with a criminology degree from a land-grant college can get this, then I think anybody can. And I think we're going to talk a little bit later about some of those cultural things. And I think one of the great things about Colonel Holman and I, him having acquisitions background being really sound at engineering. I'm an INTJ intuitive guy. I just make gut decisions. He keeps me grounded. And basically the first integrated mission Delta was this office and it's worked really, really well. So I'll turn it over JJ, because he's really the brains behind the operation.

Lt. Col. Jeremy "JJ" Homan (03:36):

No, Paul, you're too kind. Welcome everyone. Appreciate being here. Like Paul said, our office has gone through a lot of learning background on me, acquisitions, ops, analyst. Sometimes I joke that I'm the acquisitions guy in the division. But bringing back to Carlo what you asked about, what do you hope get out of this conversation? I really believe that there's a lot of tension like Paul said, between acquisitions, ops and industry. And I've been a little bit on all sides of that. I've seen some of the tension and I really believe that events like this coming together where we can have open conversation, really talk about some of the issues and kind of grow together, be more empathetic, be more understanding, that's going to get us where we need to go. So beyond all the buzzwords and agile software development, it's more about all working together as a piece of team. And so that's what kind of is the theme of we're going to share some challenges, some things that we've gone through that helps us to get where we are today. But we're hoping that you take away some of that and realize that we have to be thinking about everyone as like, Hey, you're a partner in this. Not okay, I have to write a contract. You do what I say. There's too much of that going on. So we really need to flip the script on that.

Carl Viray (04:54):

Cool. So we have a very diverse audience here today. A lot of people probably not from the Space Force, not from defense. So maybe it'll be helpful if you just set a little bit of context about what are the missions that you support today and as your organization, how are you supporting them?

Paul Contoveros (05:09):

Yeah, sure. So it's interesting, there are five mission areas in the Space Force. We've just updated that. Some of you may be familiar with some of our mission sets like MILSATCOM, GPS, we have missile warning radars. What's been great under the reorganization of Spock is that now we were an outside organization as the directorate of innovation, but now under combat force enhancement, we are with all the mission area owners. And so that progression has just changed everything for us because now one of our biggest pain points, and you wouldn't believe this, one of our biggest pain points is codifying pain points. If you ask an operator what do you need? They're not going to give you anything worth ****. You have to almost tell them. You have to bring them to the well and be like, I think you need something like this. I didn't know that it took time. So now I think that approach has been working, at least it's starting to work.

Carl Viray (06:10):

Yeah. Awesome. So you mentioned a little bit about the pain points, kind of this will lead into a lot more of the discussion and your examples of how you're solving. But what are some of those biggest challenges or the bottlenecks that you're seeing that have led you to structure your organization in a way to solve the problems that you're trying to solve now?

Paul Contoveros (06:27):

Well, some was external, some was internal. So as part of the realignment, we lost about half of our manning, so we were forced to focus in. And that was a good thing I think because we'd been playing whack-a-mole with all kinds of different things. We've got industry telling us, we've got this great thing for you academia, we can do a study, we've got grant money. There's no way to juggle a thousand things at once. And so when we were paired down, now we get to be laser focused on software development and delivering capability to the war fighter. And we do that through our combat enhancement teams, which are essentially Rise8 software developers. Rise8 is our contractor. Can't imagine why JJ was here last year at Prodacity. He came back all fired up and energized and we were lucky to get into this partnership.

(07:19):

I think because what we're trying to do, it's not about the bottlenecks necessarily in the organization. What we're trying to get after for every single one of our mission areas is closing the gap between capability and threat. So imagine an XY axis threat over time, 45 degree angle, but you get stuff delivered here and then maybe here, but the threat keeps going and your capability, our job is to close that gap. And the easiest, fastest, most impactful way is doing what we're doing here, getting after the ones and zeros and codes. It doesn't matter how much Gucci **** we have on orbit, if you don't have the data and you can't exploit the data, there's no point.

Carl Viray (08:02):

Yeah. So you mentioned closing the gap between the capability of the threat, this kind of topic around success and how do you know that you're achieving success? Karen brought up in her talk, success isn't always success and it's thinking about from a larger system or enterprise perspective. So what are those key indicators of success or those metrics for you? We talked about the mission metric that matters yesterday. How do you know that you are effectively closing the gap between capability and threat?

Paul Contoveros (08:28):

JJ has probably got a good answer for this, but the real quick answer, you know what, I'm going to shut up and just let JJ answer. Nevermind.

Lt. Col. Jeremy "JJ" Homan (08:37):

Yeah. So I've been thinking about this from a, after Doug's conversation yesterday, we talked about ROI and how do we say what we're doing matters. Just fundamentally being in the government, we are, as the government, we don't make money. We spend money. So trying to say, Hey, I made this much money by spending this much money, it doesn't really work. So we can try to do some extrapolation, do techniques like that. But to be honest, I prefer simple. I prefer just going down to the lowest level and understanding, hey, what the problems really are and walking that dog. So value stream mapping, talking about, like Karen brought up, I love value mapping. So I'm a system engineer, background systems thinker at heart. You've seen me post some of the things on there. The collectible kind of hit me with a lot of the conversations is I think systems thinking and systems engineering has kind of fell flat with thinking we just understand the system or almost admiring it, right?

(09:37):

That's not useful unless you actually do something about it. So I almost want to start preaching mission engineering missions thinking where it's like, okay, great, I understand the system, but how do I actually optimize it? How understand that value stream. So just give an example of, okay, well what metrics are you looking for? So we're not trying to do set out, hey, we'll have 20 apps this year, that kind of thing. The apps are useless. Then what have we done? So we're really thinking about the outcome. So an example of walking the dog, kind of the value stream mapping approach. And this is a shout out to the one of the Del 2 units, 15 SPSS out in Maui. Some of the guys are out here and then some of the teams that have worked on this project, it's called the Moss tool. So really layman's level version from JJ is basically a scheduling tool for some of the optical telescopes out in Maui.

(10:26):

So a lot of this data needs to be collected and it feeds into other battle management systems. Other things that we need to use. A lot of this data was falling flat or was those assets were not being utilized, right, because they were doing ad hoc like, Hey, I got a spreadsheet here, I got a SharePoint there, I got talked to this guy and you may get some time on the system. So the proposal was, hey, we probably need something to do that's better, but better is kind of in the eye of the beholder. So they actually got some teams out there to really understand the workflows, understand what do you guys do right now, what is value, what is just wasted back and forth stuff. So through that they started kind of mapping out like, Hey, this takes this long, this is how much.

(11:11):

If we had more time to not do scheduling, we could do more time into the assets. So I won't go into the details how they came up to this, but just kind of believe me, they were able to articulate, hey, we could get it up to an increase in 20% more space, domain awareness time and collections by just optimizing this system. And then if you start doing some things like, hey, let's take that a little step further, let's monetize things like rather than opportunity costs. Rather than buy a new telescope, which is kind of a lot of times we always think I need new weapon systems, I need new monolithic efforts. Sometimes you just need to make the thing you have a little bit better. So we were able to monetize that. I know it's a little estimation kind of things. You could pick it apart and say, oh, I don't know. I don't believe that number exactly, but we're able to see and walk the dog of this could save us up to 5 million a year versus doing something else versus just buying another telescope. So these are real tangible things and we're constantly looking for those, Hey, let's not try to turn this into some ridiculous number that no one understands 82% a better, let's try to understand those workflows and value stream mapping is a great way of doing that.

Carl Viray (12:24):

Yeah. You mentioned the thing that Joe first in his presentation said was take the systems that you have now and then figure out how to incrementally modernize it. So you're kind of reemphasizing that you mentioned of what this team was able to accomplish and the metric that they achieved. But how did you even get to the point, if you think back a little bit further of how did you identify this was the thing to tackle when you're actually prioritizing across all of space operations command and all the different deltas, what do you put your resources against and then why are you going to tackle that in the first place? So what's that process look like in your organization? How are you doing that?

Lt. Col. Jeremy "JJ" Homan (13:01):

Yeah, so this kind of goes back to the, I think to really understand how we've gotten to where we are today. Paul brought up, frankly at some points we were doing a little bit of whack-a-mole like, Hey, that looks like a problem, let's go fix that. I can't remember how the quote goes, but I love the quote of optimizing basically something that shouldn't exist in the first place is the most useless thing to do. So we've had to learn a lot through the school of hard knocks and I've loved that. We've been a learning organization since day one. I got here about two and a half years ago. Paul was honestly, he used to be my support contractor, now he's my boss. So for anyone that has a support, treat them well, they could become your boss today. Always treat everyone with respect. So when I got there and Paul admits there was a lot of like, Hey, we're the innovation director.

(13:51):

What does that mean? Honestly, I dislike how we as a country always innovation. We keep saying it, but without context it's meaningless. So when I got there, it's trying to give some examples of how we got to this place where I think we're now performing with more focus and all that. It took some learning and a lot of learning and we had to be willing to fall in our faces, say like, Hey, that's not working. Let's do something differently. So from a software delivery point of view, how we kind of got into this place initially, we were very much more a like, Hey, let's hire a team. Let's go out there hunt and feel, hear about some problems and then that sounds reasonable. Let's go. You'll figure it out. There wasn't a lot of value stream mapping. There wasn't that kind of thing. We were also, we would get ideas from the force love, the super coder program, some really great ideas out there, but what we were really struggling with enabling and sponsoring things, but we weren't necessarily owning the problem and we weren't owning the solution.

(14:57):

We were this enabling organization. I really think we've kind of shifted and we're still growing into this. I know software factory word gets like, oh my god, you're going to become huge and all those things. I think a software factory, there's a guy at Platform One, it goes by shifty. He said something in a brief that I really liked. He said, software Factory is really as an acquisition decision, it's a way of doing business. If you think of it as like, well, it's the nuts and bolts of all my factory, I think you're thinking about it wrong. So I think any organization, this isn't just an acquisition thing necessarily. Operations and any organization can do this type of thing. We've gotten to a place now where it's like, alright, the team out at Maui brought the idea to us that hey, we have some challenges here.

(15:43):

And they were able to articulate at that point, to be honest, this example, they had already been doing some of the work, so they were able to show us some of that return on investment. It's like, hey, this is a good project. This has tangible value. And we're trying to make that more the standard where we get a lot of good ideas or a lot of problems brought to us and we start methodically going through, okay, how do we rack and stack? But if all you hear is I want an app, I guess it's nowhere, we shouldn't be starting there right away. Sometimes you don't need an app. We always want to focus on building tech without understanding what the problem is. We've kind of lost everything,

Paul Contoveros (16:17):

And that's been one of our biggest problems. So everything we've done is we said we've had to start from scratch and we don't have the resident expertise in-house, right? I'm not a software person. I had never even heard of value stream mapping when we first started. So we had to learn everything and get to that ramp up. And now over the course of years, we've convinced people that we actually, we have a plan and we know what we're doing and the generals are behind us. And now we've got an operational planning team that's bringing in all the mission areas to talk to us about codifying the requirements and their pain points. So we're getting some momentum and that's the real answer now, is that we have a formal mechanism finally to capture those pain points rack and stack them one through one and then get after.

Carl Viray (17:05):

Yeah. JJ, you brought up about how the software factory can belong in any type of organization. And Bryon talked at the very beginning also of a software factory or the people process and technologies that enable continuous delivery of outcomes and production. You all are effectively kind of executing a brand new model where an operations type organization is being involved both from an acquisition perspective but actually doing software delivery. So how are you one, what were some of the points of friction that you came across with setting that up and then also collaborating with the traditional acquisitions authority or an organizations like Space Systems Command? How have you tried to bring that together?

Lt. Col. Jeremy "JJ" Homan (17:42):

I'm sure Paul will have some things to add on to this, but to be honest, when I first showed up, there's already kind of natural as an acquisition guy, Paul's background is operations. There's just this natural tension. So day one, it was almost like, okay, I honestly thought what we were doing is crazy. The idea of I came from traditional acquisitions, more waterfall systems, honestly didn't love all. We were doing that business either, but I was kind of taught a certain way. You get your requirements, you do the thing, you go find money, you get your money cut, and then you just keep pressing on and you deliver what you were told to deliver. When I showed up, Paul basically said, Hey, we have a program and we're funded. And I'm like, to do what? It's like to do innovation. I'm like, what does that mean?

(18:28):

So we started talking through what kinds of innovation. We didn't realized that we really meant more digital innovation, more what we've now kind of coined ops enhancements where it's more focusing on, I would call, generally speaking outside the weapon systems. It doesn't mean it couldn't be, but that's where we're focused on the stuff that gets left behind. So he started talking to me about, Hey, we have this money to get after this effort and to do that we need people, we need teams to get after this and do this. Well, again, we did a lot of learning, but initially I thought it was like heresy. I'm like, what do you mean we don't know what we're going to deliver? And that's what we're constantly dealing with. I'm a big proponent of acquisitions taking, especially when it comes to software intensive systems, getting away from writing laborious, the huge spreadsheets, even though I'm a spreadsheet guy, I love spreadsheets, but that don't tell us anything and that we never will edit.

(19:20):

They should be living documents to some degree config control, but living documents to understand, hey, it's what you need to do now and let's apply the money and the resources to what we want to get done. Not what someone a couple years later thought was a good idea and that's how actors was built. So we've been able to just fundamentally, I want to thank Paul in front of everyone. He was fundamental in fighting what is the hardest thing in the government getting money. And the second thing, hardest thing is not getting your money taken away. So he's been adept at doing that. Something that is a skill that can't be taught, just you got what you got. So that's been huge. It helping us fight a lot of constantly educating others and having an open mind of like, Hey, we're not just out here just funding teams just to build stuff that doesn't do anything, right. We're really methodical about it and we're getting more methodical about it.

Paul Contoveros (20:09):

Yeah, I'm really excited about where we're headed in the future. I said earlier as a captain dealing with acquisitions, we're putting geo one on orbit and doing all the testing. And I would just get so frustrated because I would go to the contractor and say, the operators need this on their console. Well, there's no requirement for that. And I didn't understand it at the time. I would just be requisitions. Thankfully, as I've matured and have had more experience, I've learned that our PEOs, our SMLs, our MLs are good Americans just like the rest of us. They want mission success. I know cost, performance schedule is paramount. What they really want is impact. And they have way more requirements than money. I didn't know any of this. They have all the money, right? SSC has billions of dollars. Why can't I get some of that? And so thankfully maturing over time and seeing how things work and then having the best IMD on the staff has just completely changed my way of thinking too. And so I don't know if Dave Williams is here, I don't want to throw him under the bus. He's going to be talking later, but he's our acquisitions partner and we're doing something really cool. We're going to build basically an example application. This is what the operators want, and then we'll go off and build from there. Instead of handing a requirements document to the acquisitions community, that doesn't mean anything. We're going to show them what the operators want. And I'm really excited about that model. I think it's really cool.

Carl Viray (21:39):

Cool. Alright. One question, a couple fun questions. Actually just wrap this up. It's the magic wand question. If you had a magic wand, what would be the thing that you'd change? And then I'm going to add this that you weren't prep for. If you were going to, if somebody else was about to embark on a very similar journey, what piece of advice would you give them? What is the one piece of advice you'd give them? So those two questions, magic wand and advice.

Paul Contoveros (22:02):

You want to go first? Sure, I'll go first. So I thought magic wand, it could be easy. I could have money and that's kind of where I was headed. But as part of being here and being part of this thing, I think if I could wave a magic wand and fix something, it would be the mindset, right? When Siobhán and Josh were talking about the dory moment that we've all had and have to explain ourselves over and over and over and over again and the value that we bring. If I could just wave a magic wand and everybody just got it, the money would flow. Everything would be wonderful. I think that's mine. I'm sorry, what was the second part?

Carl Viray (22:37):

What piece of advice would you give to somebody that's about to go through a similar journey or an experience?

Paul Contoveros (22:42):

I think what's paramount and what we learned pretty early is that you got to get connected with like-minded individuals who know what they're doing and you can take their lessons learned because starting from scratch without that network is not easy and it's not fun. JJ.

Lt. Col. Jeremy "JJ" Homan (23:00):

So I'll just kind of say what he initially was going to say. I do think we need money. I would just want more, I know we joke about it, but sayings put your money where your mouth is, right? So without resources, all you get is a lot of talk. So I'll use example. I didn't really talk about it earlier, but one of the things that also we were doing when I first got there was a lot of sponsoring, a lot of sbr, small business innovation research prototypes. I love honestly what the program could be, but I have some concerns about what it is doing right now. Just for the sheer fact, I think everyone shares these, right? It's almost like acquisition gymnastics to figure out how to use that program. It shouldn't be like that. So there's some of those challenges. Also, on top of that, we hear words, I got to bridge the valley of death. The fact that there's a valley of death is already a problem that someone has to figure out how to do that. And almost you have to have a superhero power to figure that out. That's

Paul Contoveros (23:59):

Built in.

Lt. Col. Jeremy "JJ" Homan (24:00):

I've almost started just saying there's a chasm. No valley, there's just death. Because there isn't this concept of a phase three, which confuses people. They're like, oh, phase three, why do we get that money? That's your money. Well, I don't have any money. And it becomes this problem area where a lot of good ideas kind of die. So I would like to see things like that when we talk about innovation, instead of just saying, let's do more of it. Most program offices, there's this fallacy of thought that program office just have this humongous slush fund to just do whatever good ideas come. Most of that money's spoken for. I knew my budget. I've protected it like a hawk because I had things that needed to get done right? I've already been told things to do. So you're adding more layers and more requirements isn't helpful.

(24:44):

So I like to see some type, what I'm going to just call it, the sustainment innovation pot that's there and available. Not like you have to figure out how to get it. It's already there for you. You have to prove that you deserve it, your tech is worthwhile and start taking some of the shackles of data, IP and all this other stuff. I think a lot of companies need some ability to do things like magic wand stuff. Not every company wants to sell their widget. Some want to sell them and say like, Hey, I want to show that I'm good at, I'm basically a VC capitalist. Kickstart me, let me get off my feet and then I'll show you what I can do. They integrate me into the rest of the full. So I think ideas like that. If I could just do massive PBB reform, I would love that. And a lot more money. And what was the second question again? Yeah,

Carl Viray (25:30):

We're out of time, but what advice advice would you give somebody?

Lt. Col. Jeremy "JJ" Homan (25:34):

Just go back to, I said earlier, I think we just, events like this are huge. To have people come together, keep going after them, keep coming to events like this. I am going to go back and DTS, that's the government travel system. I think I put this operations was the reason I'm here I'm going to put down is therapy. I think this is therapy for all of us, especially acquisition types. We need this. Yeah, I know you agree, right? Where we actually start talking and what the issues are and we're coming together as a team.

‍