How do we modernize defense acquisitions for the digital era? In this candid fireside reflection from Prodacity 2025, Lt. Col. David Williams, a leader in Space Systems Command (SSC), shares hard-won lessons from adopting continuous delivery, rethinking acquisition incentives, and integrating testing from day one.

From breaking down bureaucratic barriers to optimizing software delivery contracts, Williams offers a practical, no-nonsense approach to accelerating digital transformation across the DoD. If you're tackling software acquisitions, DevSecOps, or platform strategy in government, this is a must-watch session.

🔹 Key Topics Covered:

• Why traditional DoD acquisition models fail in software development
• How contracting incentives impact software modernization efforts
• Why test organizations must be embedded from the start for CD success
• How to apply commercial software delivery lessons to DoD programs
• The real role of software factories & where they need to evolve
• Why the DoD should get out of the platform business

🕒 Key Highlights & Timestamps:
[00:05] - Introduction: From acquisitions to software leadership in SSC
[01:19] - Lessons from launching a continuous delivery acquisition strategy
[04:49] - Why cost-plus contracts kill automation & efficiency
[07:28] - The biggest bottlenecks in continuous delivery for DoD programs
[09:00] - The problem with traditional testing & how to fix it
[10:58] - How to implement mission-level automated testing
[12:33] - Software factories: What’s working & what needs to change
[14:04] - Why DoD platforms should be commoditized, not government-built
[17:18] - Breaking the cycle: How acquisitions leaders can drive modernization
[20:00] - Final advice: Educate, network, and be ready to lead change

🔗 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 leading acquisitions, software modernization, or digital transformation in government, give this video a thumbs up, subscribe to our channel, and share it with your network. Better software starts with better acquisitions.

#Prodacity2025 #DoDModernization #DavidWilliams #ContinuousDelivery #DigitalTransformation #DefenseIT #SoftwareAcquisitions #GovernmentInnovation

‍

Bryon Kroger (00:05):

All right. I gave a little intro, but maybe if you wouldn't mind just talking a little bit about your background and what you're working on right now.

Lt. Col. David Williams (00:11):

Sure. Yeah, so thank you. Humble to be here. I'm not a C-level officer, just a mid-level government bureaucrat. Don't have a software engineering degree or cute accent, so it's very nice people to be here. Yeah, so math, background ops research, spent a lot of my time in program offices as a young officer, so when you get to the lieutenant colonel level, they want to send you to a leadership assignment wound up at SSC in a software program. I think it's because none of the Space Force program managers were willing to do it, so they asked me to come in and do it, but I had actually had done a previous assignment with software, found that I had a passion for it, found that I relate to the story of Max shared on day one, that this is where I can leverage my skills to better than most war fighters. So very passionate about that.

Bryon Kroger (01:05):

I love it. And before you got to this assignment, you led a pretty large scale acquisition strategy, trying to adopt continuous delivery and platform we just talked about. Would you mind giving an overview of that, what you learned from it?

Lt. Col. David Williams (01:19):

Yeah, so I had a cool opportunity. I was doing a prototype that led to a program of record. I was helping the program of record team stand up and now I'm in charge of executing that effort. So some things we tried, some lessons learned, both good and bad. So some things that worked, we actually borrowed a notion from the Navy of in your RFP source selection documents that go out, have the proposal include a backlog decomposition, so the government seated it with maybe some high level epics for the first couple of increments and then we wanted to see them demonstrate all the way down to the story level to show they knew their domain expertise and also how to handle agile. The cool part was it clearly showed who the experts were and then on day one we had a backlog to work with and didn't have to wait for that.

(02:08):

So that was a cool thing that worked. We've developed a government product team, so a little bit of context, I actually sit adjacent to the Kobayashi Maru factory. I help lead more of like the classified side for space control for the National Space Defense Center. So we set up, I call it a factory. It was a multi-vendor collaboration comp mates. We had an IDIQ and competed various software subsystems or software domains we called them. So when you had multi-vendor software getting delivered to an ops floor, the government team wound up being the unified front of the product of the overarching software suite to the operator. It is pretty cool hearing some of the talks about value stream mapping. We were in the trenches with that product team, with the operators value stream mapping their user workflows. We had a software architecture team taking notes about how they could time phase out software delivery.

(03:09):

So having a government product team is kind of a unique thing and that's working for us. Some things that didn't work, we did not lead with it. And platform and CD at the outset that was part of the development work, which I have to tell you has not gone very well and has held a lot of development work back. We also overestimated a little bit about how much mates we're willing to work with one another within a portfolio. And then I think we've learned a lot about how contracting strategy sets up the personality of an effort, especially when you have competitors working together that have been really hard to overcome, but you've got good people. You try to appeal to their Americana, their heart for the war fighter and have 'em overcome those obstacles and we've seen a lot of that.

Bryon Kroger (04:08):

Yeah. One thing you and I have talked about is the interesting incentives that can be at play, especially for services companies. I think I'm sometimes a little bit rare. In fact, Shawn is like we agree because a lot of the services vendors, they see platform as a really great opportunity to deploy services. I still think you could do that if you were building a low opinionated platform, you didn't have huge operational workloads to run. You could still kind of DIY your platform, but how do you make sure that they're incentivized to spend as little as possible on the platform and are focused on maximizing mission value?

Lt. Col. David Williams (04:49):

Yeah, so we've echoed the quote from day one a lot. How demoralizing it can be to work on the wrong thing. I think wrong is also relative and there's only so much you can ask an individual team to do to fight what I call a corporate gradient or like a corporate vector field. If the government sets up a contract with the corporation that doesn't incentivize the behavior you're asking for, you can even get the development team or the platform team to agree, yeah, this is the right strategy. We should automate everything, make it where deployments are fast, enable cd, but if there's no profit in the company for that, there's no incentive structure backing that they're fighting against a gradient and I've just found you can't quite overcome it. So incentives are super important when you're crafting your acquisition strategies. I personally will never bring to a decision maker an acquisition strategy where we're doing a cost plus contract for a platform ever.

(05:46):

Again, I think we've crested the hill. These are no longer developmental concepts. We're no longer going to do cost plus anything. If you're going to bring in a platform, I think incentivize by either going firm, fixed priced or some kind of fixed price incentive fee to inspire automation and efficiency because if you're on a cost plus you're getting paid by the hour, what motivation do you have to automate anything? And the government can jump and scream everything they want, but they're like, Hey, the contract says I don't make more money if I do that. So also looking for a leveraging strategy and we can talk more if you want about more like bundling contracts. I also am seeing several platforms suffering from getting rushed to too many markets before they made one market work. And not only do you have to make that one work, you have to make it work exceedingly well and make it exceedingly automated before you say, now I'm going to sell it to a bunch of people and by sell I mean a government pm convincing other government PMs. I've got a great platform, you should use my platform. Personally, I think the government should be getting out of the platform business and it should become a tech layer that is a CLIN or a subcontractor assumption. I'm going to award a capability delivery contract to you. You're going to figure out the platform you need and bring it to me. Kudos if it's well proven or even has a commercial backing behind it.

Bryon Kroger (07:08):

I love that and that is a very rare perspective. Thinking about Edwards talk and continuous delivery, you've got a lot of lessons learned now. What are you thinking about as you go back in terms of what are the biggest bottlenecks that are still getting in the way of continuous delivery and how are you thinking about addressing those?

Lt. Col. David Williams (07:28):

Yeah, there's a lot of DOD regulations, especially in the acquisition rule books about the acquirers can only do so much and then you have to bring an independent test organization in. And I think separating out, you have to bring up a whole nother government team. And I guess I agree in some cases, especially in hardware, you don't want the government program office who might be corrupt checking their own homework. We have a serious trust problem, so we have an independent test organization come in and unless they have been involved from the get-go, it doesn't work. You wind up with another throw over the fence problem. And by the way, that test organization is also not the operators. So they show up to the software and they're like, Hey, can you show me how to use it? You're like, well, I've been working with a user, they know how to use it.

(08:21):

Why don't I have the user do it? And they're like, yeah, but I'm a tester. So CD in a government context, if you're a major acquisition program has to include testers from the beginning. And I see a lot of integrated task force concepts where there's openness to that, but most of your test units do not have people that understand pipelines. They don't trust robots doing test for them, which is what your helm chart is, right? So can we bring to them examples, let them test something to the nth degree with a human and then show them, Hey, by the way, here's a little that does that for you and here's the artifact and if you just look at the artifact, you can trust it. So test is a big one.

Bryon Kroger (09:00):

That's interesting. One pattern I've seen work really well there is having an exploratory test charter with the test community that's responsible for assigning your level of test, and I think we've seen a lot of success in getting a lot of developmental testing actually ends up mostly focused on having humans catch regressions, which just shouldn't be happening. It's a terrible use of humans and so getting them really comfortable with the test suites that Edward talked about in TDD unit level and even integration tests, but then there are still some manual tests that are worthwhile to run and we've seen if a pm at Rise8 for instance, checks in code, there's PM acceptance for some of these more complicated user journeys, there has to be tester acceptance and the tester is not somebody on my team. It's literally somebody that came from the 45th or the 46th. Like you said, I've seen some of these integrated test concepts that start to work. I think where it gets challenging is when you start going across programs now, like joint interoperability testing obviously becomes a big challenge because you're only as slow as your weakest link I think is what DJ said, and they just can't keep up with the level of testing that you're doing.

Lt. Col. David Williams (10:16):

Okay. Then what I would tell that person, the same mindset where we solved a single team, getting to cd, getting to where that curve flattens out, let's employ it at the enterprise level. If you can write a test before you write software, why don't you write a macro test for the mission value stream you're trying to deliver across the system of systems and then have your final integration test check out and test your contribution to that and then maybe on a nightly or weekly basis, the whole integrated system of systems is testing itself as well. I think the testers should scream the same way the developers are screaming. I don't have time to run a checklist every night or as often as I need to. Let's automate this.

Bryon Kroger (10:58):

You mentioned one software factory. I've talked about a few of them and how I think they've kind of gotten off track in some ways, but there's also a lot of really valuable lessons that we've learned from them. What do you think is going well and what do you think needs to change or what does the next iteration look like?

Lt. Col. David Williams (11:13):

Sure. I think I'm gaining a reputation as a factory hater, but I'll be very careful with that all software is delivered through a factory. I think you have to be careful how the government structures the factory. If you're the war fighter, if you're space operations command asking, what did I get for all those people working all that time, it really is what's in prod or if you're the combatant commander who's saying, I need to go to war in three years, are you going to be ready? The government, I'm sure other organizations aren't like this, but we become dedicated to where we sit, and so there's a tendency for the factory to become the end of what you're doing, not the delivery, and I think, like I said, I think all good software is delivered through a factory mindset. I'm just saying rather than having the government in the factory at each workstation with you, we need to become more like DCMA where maybe we're sitting at the factory and observing but not directing and calling every shot. I think the factory should be a contracted effort that we're assessing and we're putting outcomes on contract and then tracking progress with the right kind of metrics to closure.

Bryon Kroger (12:33):

That's a good segue to platforms and DJ's talk because underneath that you need a really strong platform, so I'm going to pin you down and ask you to give an opinion. Where are you at these days on, I mean D.J. talked about a 10X platform and what that can do for your productivity and enabling continuous delivery. What do you want to see? I know you're going to kind of let the vendor bring like, Hey, I just need you to ship the capability. You can bring the platform, but what are you thinking based on what you've seen in the field?

Lt. Col. David Williams (13:04):

Has anyone seen a platform that's it's coefficient before the X is less than one right now as a government customer, I'd like to see a one x platform, but let me be honest, the two talks right next to each other were perfect. So the list that Ed brought out about how to get to cd, the cultural things you should instill, I literally put line for line almost, I don't know if you wrote my contract, but in my contracts I said, these are the behaviors you'll be assessed on. These are compliance items. The problem was the platform was so immature, it dominated the equation and you need both and I think it's pretty reasonable to assume a 10X platform is going to make the learning curve easier. I may even go as far as saying, I don't think Uncle Sam should be paying for that learning curve much longer. I think if there are 10X platforms out there, we have the right to expect a 10X kind of behavior. Go find one when you win a contract and bring it.

Bryon Kroger (14:04):

I love it. There's also an incentive piece that you touched on. How do you think about getting the right incentives on contract? You mentioned one, but do you have others?

Lt. Col. David Williams (14:16):

Well, you can talk about fee, you can talk about structure. I think you have to question personally. I think if you question the notion of an enterprise platform, I think in a way every platform has to serve its software customer uniquely, so I'm glad to hear DJ and other commercial providers are hitting, other customers are hitting their backlog and they're realizing, oh, this works great for the one user, but I have to make it work for a lot of people. The more we can do that, we'll start to build into these larger commercial platforms more flexibility. But at the end of the day, we've gotten comfortable having infrastructure be a commercial commodity with clouds. I think it's time to view the platform as a commodity, probably with a heavy service overhead, but maybe it should just be a services clan or a materials clin that you're buying just the way you would cloud.

Bryon Kroger (15:13):

Okay, I like that. To get there is a lot of culture change probably inside of your own organization included. What do you see as some of the biggest cultural challenges in modernizing in this way?

Lt. Col. David Williams (15:29):

There's an interesting analog to risk. I think it's, I would call it trust. We as the government believe in separation of powers for a very good reason, but even within the DOD and within acquisition alone, having to separate tests from development, having to separate security organizationally from development because of bias or collusion means DevSecOps is dead at the outset unless you can get everyone together on the same mindset. I already talked about my thoughts on test. I know the other punching bag is security, so can you get your security assessor who's going to be grading your homework at the end? Can you convince them to come in at the ground floor and say, Hey, here's where I'm thinking about heading with my architecture with our design trades. How do you feel about that? They're not prohibited from advising you, even if they're supposed to be separate from you, and I'm doing my best to set up teaming constructs with OSI PJ or sa, all within the Air Force to have that collaboration early so when they're grading the homework, it's not a surprise and they've already had the ability to provide input where it matters at the outset.

Bryon Kroger (16:47):

It's really interesting. There's a corollary to that in the value stream map conversation. I think I posted it in Slack actually, but we've done a lot of VSM on people's ATO processes and pretty consistently more than 80% of the time it takes to get their atos just time waiting in queue. There's no actual work getting done. So not only getting them integrated so you don't have those long feedback loops, but spending more money. I say, put your money where your mouth is. If you want to move fast on security, you probably want to spend a little bit more on it.

Lt. Col. David Williams (17:18):

And staffing those positions with the right expertise. I mean, we've got accrediting officials and SCAS who are busting their butts for this country, but the fact of the matter is they're a retired cop, they have no expertise in software, and someone shows them this complicated BOE and they're supposed to assess it and come up with some kind of risk and they're told they'll go to jail if they do it wrong. How would you respond if you were totally outside your expertise? I'd love to see an influx of software skillset in the cybersecurity domain on a government salary, so hopefully you're independently wealthy.

Bryon Kroger (17:58):

When you and I were chatting leading up to this, you gave this really interesting analogy between space launch and enterprise transformation, so how do you see the landscape shifting in similar ways?

Lt. Col. David Williams (18:09):

Yeah, if you've been keeping track, SSC is shifting towards commercial launch, trying to incentivize that. If you think about back across the decades, space launch was a government's game for decades, right? No one else had a reason to go there. There was no viable cost model to put commercial things there. Commercial entrance started coming in the satellites, but it was all on government launch. Now we're seeing a change in the tide over there. Now we're seeing the SpaceXs, the Blue Origins, various other launch providers, and so now a satellite program can just budget in cost to get on orbit.

(18:51):

We can start to restructure the DOD budget because right now the launch program of the Space Force is larger than most of the satellite programs. It's this direct subsidy to a launch platform, if you will, but now we can actually divide that cost and track it more accurately and tell a satellite program, Hey, just account for how many kilograms you are and Elon will get you on orbit for less than it's ever cost before. I think there's an analogy there for platforms. I think it's time for the government to get out of Cape Canaveral and Vandenberg Space Force Base and start saying, go to Boca Chica.

Bryon Kroger (19:28):

Wow. Alright. So you're a material leader and there's analogs in the other services and in federal, if somebody is facing resistance at the ML assembly, they don't have, you get it, but their ML doesn't get it, what strategy recommendations would you give to them to overcome that resistance? How do you get your ML on board? How do you think? How did you transform?

Lt. Col. David Williams (20:00):

Read good books, be able to cite good books in an argument, ask your ML to argue why 21st century software has come to some universal conclusions and why maybe your ML ought to consider some of those mindsets. I think we need to develop a cadre of software acquirers. We have specialized training for each of our operator shreds. Acquirers have training for acquisition. I think it should become a specialty. This is a very different domain. You wouldn't ask me to go buy a stealth bomber. I wouldn't know the first thing about doing that, so why ask somebody like that to come buy software? There's a whole learning curve that we could accelerate if we learn it younger and then we should probably have a schoolhouse to train this kind of mindset. I'm very thankful for this environment. Brought some of my younger officers to start that education young here today.

Bryon Kroger (20:58):

Nice. And in a similar vein, talking about reflecting on your own growth, what are one or two unexpected lessons that you've learned transitioning into software and getting to where you are now?

Lt. Col. David Williams (21:15):

Code doesn't transition. Company A has a contract. They've worked for years on code. The government decides to recompete because it's better. Company B comes on, we GFE, all the code to them. I feel like I've got a lot of examples. No less than a year later, that code no longer exists, so thank you for paying your taxes. You've probably paid for the same software several times. And then I'm shocked. It was actually kind of late in my assignment. I learned about the strangler pattern and how simple that could make modernizing old systems, how little we actually use it, and how little our senior executives understand it. I've actually never seen it play out in theater. I think we should go show people, Hey, I'm just going to wrap something around this one service I'm going to show you. You can build trust around it and if you build trust there, it's like you can start doing it faster and faster. That was kind of a surprise to me, and it's actually kind of an old school thought.

Bryon Kroger (22:21):

That's interesting. I kind of want to ask your opinion on Atlas in regards to that, but I won't go there. So I mean, that's one of my biggest regrets is similar to the JMS story in Space Force was TBMCS and the Air Force and we didn't touch the legacy system and we paid for it. You either pay now or you pay later. Alright, any last words of wisdom you have for the audience as it relates to getting traction on digital modernization

Lt. Col. David Williams (22:56):

For the DOD audience? Hang in there and get older. One day you'll be in charge and this mindset will be yours to impose on others and keep having these collaborative environments. Help the DOD help us acquirers learn this stuff. And again, thanks for the chance to talk today.

Bryon Kroger (23:13):

Awesome. Thank you for joining us. It's a pleasure.

‍