How does the U.S. Department of Defense (DoD) drive innovation while navigating complex bureaucracy? In this insightful session from Prodacity 2025, Bess Dopkeen, former Senior Advisor to the Under Secretary of Defense for Research and Engineering, shares hard-earned lessons from her 19-year career in the federal government.

Bess reflects on her experience tackling major defense acquisition challenges, working with the Defense Innovation Board, and leading software acquisition reforms in Congress. She explains why breaking legacy processes, embracing iterative development, and integrating warfighter feedback are crucial for digital transformation in national security.

🔹 Key Topics Covered:

• The need for unlearning outdated DoD acquisition and software practices
• Why bureaucracy is designed to resist innovation—and how to overcome it
• The Joint Fires Network and real-world examples of software-driven military decision-making
• The role of Congress, industry, and government collaboration in shaping digital transformation
• How agile development, DevSecOps, and rapid experimentation can close capability gaps

🕒 Key Highlights & Timestamps:
[00:03] - Introduction: Bess Dopkeen’s career in defense acquisition & innovation
[01:21] - Challenges of traditional defense acquisition & why it needs to change
[02:26] - The Defense Innovation Board’s findings on DoD software failures
[04:10] - How bureaucracy stamps out innovation (and how to protect it)
[07:18] - The missing link: Who is responsible for military system interoperability?
[10:44] - The biggest obstacles still facing the DoD in the digital era
[12:59] - Joint Fires Network: A case study in agile military software development
[14:32] - The danger of four-year development cycles in national security
[16:51] - How the Pentagon is testing & integrating emerging technologies
[18:42] - Using real-world experiments to bridge the gap between tech and warfighters
[21:18] - Unlearning in government: What senior leaders & Congress must change
[24:14] - Final thoughts: Measuring capability, not just software code

🔗 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 found this discussion valuable, hit the like button, subscribe to our channel, and share this video. Let’s work together to bring real digital transformation to government and defense.

Bryon Kroger (00:03):

So good to see you and fun fact, some of you know that my journey with all of this kind of started at Kessel Run and one of the first people that I met when we were going up to the Hill was Bess Dopkeen, who was a huge help to us. So I'm excited to dive into it, but maybe to start, if you could just tell folks a little bit about your background and how you got here.

Bess Dopkeen (00:22):

Yeah, no, thank you for having me. Everyone can hear me. Okay. So I just left the Pentagon on January 20th. I was the senior advisor to the undersecretary of defense for research and engineering, which is very fun. You get to just kind of run at these kind of stratospheric levels of seeing the whole department and all of the major issues and gave her the best advice that I possibly could. I just ended 19 and a half years with the federal government. So I did. Thanks. It's crazy. I'm mentally getting through that. It's been full two weeks that I've been in a non-government world, so it's very exciting. So yeah, I was in the government for 19 and a half years. I started in the undersecretary of defense for acquisition technology and logistics. I was focused on acquisition of major weapons systems. I did monthly reviews on the worst performing weapon systems.

(01:21):

So it was a good three years of a deep dive into all of the difficulties that the major defense acquisition programs have. Then I got pulled into an office that is an independent advisor to the Secretary of Defense. So they do independent cost estimates, independent worlds of what is needed, what we should be buying. So I did deep dives for six months into a major weapons system that was bought by the Army, Navy, Air Force, et cetera. And then I got an awesome opportunity to move over to the Defense Innovation Board and run their software acquisition study that was tasked by Congress. And so talk about unlearning. Pretty much all I did right there was worked with defense innovation board. So it was Eric Schmidt and Richard Murray and Michael McQuade, Milo Medin from Google. I mean just very wonderful people that were from the outside looking in is good God, what is the department doing?

(02:26):

Why are we building weapons systems like the one that Bryon was trying to replace that took four years to build. And then you just wait to the very end of the weapon system and you flip it on and you're like, ah, it didn't work. And then you go back and you try to figure out what the problem was. So that was fascinating and you have to completely unlearn the way we used to do things and that kind of waterfall way, but how you build massive systems kind of slowly and deliberately and efficiently, not efficiently, but there's this old, sorry. So inside of the industrial in the 1980s, there was industrial theory and the bureaucracy was meant to be as efficient as possible in doing whatever it was. So you stamp out anything that is new, you stamp out any idea fairies, you stamp out anything that is different because you're going to just make this one widget as perfectly as possible.

(03:25):

And so that is the bureaucracy of the department. And then you have to, in the eighties, they knew this. You have to kind of protect this little innovation bubble because you need to constantly be thinking about the next generation. You can't just stamp out the same widgets forever. Someone's going to build a better widget. You have to think of the next things, but you have to protect that bubble because the bureaucracy will stamp that bubble out. It is built to stamp that bubble out. So you have to think about that in the world of defense. You need to be able to think about how things are going differently and you can iterate on requirements and if you can iterate on what you're doing and you can build a little test, a little field, a little, build a little test a little field, a little right, continuously with the war fighter and make something better and deliver it quicker.

(04:10):

That's what I got to do a little bit in that year that I was running that study. But to do that inside of the department, you need to take all of these people who have been in the bureaucracy and they're the best at what they do, but you need to bring them in to be like, how do we do this better? So we built these 10 teams, acquisition contracting, J Mo is here and you're going to hear from him later on requirements how you pay for it, how we budget for it, how we do all the things, right? And everything every single level, you kind of break the way the department does things for software. But I mean as I've seen actually now seven years later from that, you actually want to do that with a lot of things, not just software was just software was kind of ahead of the curve for that.

(04:56):

Alright, so then I left there and I went the house. I went to the Hill into Congress. So I left my civilian job being apolitical and I went to work for one side. So I went to work for the Democrats who had just come in 2019 and became the science and technology and innovation professional staff member on the House Armed Services Committee. So the House Armed Services Committee is what writes the laws and the statute that govern the Department of Defense. And so I worked a lot of outside committees, small business agency, I mean a small business committee and all the other things that govern everybody else, but really we write the laws for the Pentagon.

(05:36):

Got to spend a lot of time sitting with small iterative tech businesses, community, private capital, venture capital, all of that kind of hearing about their frustrations of working with the department. And so spent a good three years sitting in that and trying to help bring about statute to statute, which is law to make things better in the Department of Defense. It was very hands off, which is harder for me. I like to be in the government kind of fighting those battles left and and running up against a wall, bang my head and then figuring out a way around it. So when you're on the Hill, you kind of write something and you throw over a message to the Pentagon, everyone runs that way and then you throw a message this way, everyone runs that way and you can kind of get them to where you want them to go, but it's much more hands-off.

(06:28):

But it was very exciting and it was a great way to see all of the issues across. And then I came into the department three years ago as the senior advisor to the undersecretary of defense for research and engineering. So that was Honorable Shyu. She had been the ASA(ALT), which is the person in charge of buying things for the army. And so she had been from industry, she was an A salt, she had been on the Air Force's Science to Advisory board and all the other things. And now she was running all science and technology. So all of the basic research, applied research, advanced development, prototyping, and then we kind of built in the experimentation aspect for the whole department, overseeing all of that, all of the laboratories, et cetera. So that was extremely fun and really got us focused on what she was very focused on.

(07:18):

And so I am very excited about the joint war fight. So everything that you kind of work on today is how to make the army better at doing the Army's things and how to make the Navy better doing it, the Navy's things and how to make the Air Force better doing the Air Force things and the Space Force better doing the Space Force things and the Marines better doing the Marines things and who's in charge of all the things that fall in between the cracks and don't actually don't belong to anyone. So one of my favorite things that Eric Schmidt used to say during my year with the Defense Innovation Board was he's like, he would see these OV ones, these overarching like, okay, my helicopter is going to talk to that jet that talks to the satellite that goes down to the surface vessel that goes down to the underwater vessel and then we're going to shoot something and there we will close a kill chain.

(08:07):

That's the kill chain closure. But he's like, so who's in charge of the lines that connect all that I'm sure usually displayed as the lightning bolts. He's like, who's in charge of the lightning bolts? And everyone kind of just stares at you and blinks and nobody has been responsible for the lightning bolts. Nobody is responsible for building that connectivity between the services. Everyone's building their own code that doesn't talk to each other and they're not building it with APIs. They are now hopefully building it with APIs and other things like that and all the things. But back in the day you kind of built it in your own script and you were going to talk to your own things in your own service. And if we all show up to fight a war, I guess we'll figure it out and we'll pick up phones and call each other.

(08:50):

But when you have the thing like closing the joint kill chains, someone's going to shoot something from a ship that has to talk to a satellite or something in the stratosphere that no one is responsible for. We can't get anyone to take over. And then it has to actually land on something that is massive amounts of information that has to be automatic, that has to have someone sitting over it overarching. But who runs the rules of the game? Who does the decision on what happens if you bring Army, Navy and Air Force and Space Force to a fight who is shooting our very limited weapons because they cost a lot and take a long time to buy and some of them are way more capable than others. And are we going to shoot seven of the same thing or different things at one thing? No one's talking, right? These are the conversations that INDOPACOM has to figure out and they're going to have to figure out by themselves with no buying power and all the things. And so who's responsible for that? And so that's a lot of what we did in the undersecretary of defense research and engineering. I love to talk about, one of the things is the Joint Fires Network. I'd love to talk a little bit about that, how it is getting at the world that we set up in 2018.

Bryon Kroger (10:05):

Yeah, maybe before we do that, I would like to ask you, that's a really unique perspective. You've kind of seen all sides of the department and how they do software. You've mentioned Eric Schmidt a few times. Eric used to have this quote I put in almost every slide deck which said, "the DOD breaks every rule of modern product development." He didn't mince words. And Lt. Gen. Garrant this morning talked about why government needs to adapt for a digital era. When you put those two things together, I mean what are you seeing still today? Because the swap study came out with a ton of findings. We're what, seven years on from that? What are the biggest obstacles that are still facing the department and the larger federal government?

Bess Dopkeen (10:44):

Yeah, mean? So there are so many obstacles. Alright, so okay, there's a whole conversation about strategic visionary leadership and then there's a whole idea of agile is pushing decisions down as low as you possibly can. What we end up having a lot is leaders come in and they're frustrated that nobody inside has done anything. And so they're like, I will solve these problems by myself up here, which you cannot do. You have to empower the teams below you to figure things out, come up with better suggestions, bring in tech experts, but also bring in those people who know the systems today and how can you iterate. And so I think one of the things that we did in the swap study was very important on that is we built those 10 teams and we pulled from inside the Pentagon so that when we finished this report, it wasn't a report that sat on the shelves, but everyone was empowered to go make change in contracting. The people who had contracting policy were empowered to do that. The people who have acquisition policy were empowered to do that. And so I think they're still working towards it.

(11:55):

I think it's just overwhelming. I think a big thing that we have is just overwhelming. We have so many legacy systems and how do we even start? And so we have these things like combined joint all domain... JADC2 whatever command and control. And so you can't boil the ocean, right? We're not going to just say at some point at this time in our schedule chart, there will be combined decision making for all the world around and every single combatant command you have to start in a smaller place and you have to be agile about it and you have to iterate and you have to have a DevSecOps sort of mentality. So one example for example for Joint Fires Network is the thing that we are building a small thing that we are building inside of INDOPACOM to get kind of that decision making and software backed and data backed backbone to how we're going to fight that war.

(12:59):

And everyone gets confused. They're like, well how is it different from JADC2? I'm like JADC2 is everything. We're just going to take a very small thing and build a little software and then iterate with the warfighter. So you're sitting with the warfighters. It started with Admiral Aquilino who was the combatant commander and he was like, here's what I want to do. This team built in an agile sort of way, but iteratively with the warfighter sitting there built them the software and it had this joint virus network 0.5 where they turned it on initially and said, here's what it is. You wanted us to close the kill chain for these nine things. And they actually clothed the kill chain for all those nine things except for one of them that actually the system couldn't do, but they did what they needed to do and Aquilino was like, great, that's not what I want.

(13:51):

You know what I mean? Because he realized now the capability of this software and he's like, actually, I want to go in this direction. And so if you hadn't done that, if you hadn't built a little for the war fighter and had them play out exactly what they wanted in this tiny little small chunk of time, you wouldn't have been able, Aquilino would've been able to be like, yes, but I didn't even know what I wanted now I want it to do this. So if you do the things that we used to do, which is build a new system that will replace the old system and that's literally all we're doing just with new code and we take four years to build it and then turn it on. I mean you're always going to deliver something that 20 iterations ago the warfighter would say, that's no longer what I want.

(14:32):

And so we have so many different issues. One is you have to take small bites of the apple and two, you need to constantly iterate. And three, you need to do it with the warfighter. One of the things Shotgun Browning who did Assault Breaker Two and some other very cool things that kind of how JADC2 came out of how we actually do this engagement with the People's Republic of China. And if we were going to do something in INDOPACOM, one of the things that he loves to talk about is a really boring Christmas. So I'm Jewish, so I will talk about it as a really boring Hanukkah. But the idea is you don't want a gift that you open and you're like, oh, that's awesome. I really wanted this color sock. But what you want to do is you want to say what is it that you want?

(15:17):

And then you want to go and get exactly that and then you want to go, Hey, I found something even better. Would you like this? And then they go, yes, I really want that. And then you have a really boring but awesome Christmas Hanukkah and that's kind of the way you want to be doing this with the war fighters, particularly the joint war fighters, the requirements folks, the acquisition folks and the science and technology folks about what's actually Iterable, what you can actually iterate on and get even better than what you knew beforehand with a smaller timeframe and expenditure.

Bryon Kroger (15:50):

Okay. I think something you said there that's really interesting is I talk about gal's law a lot, which is complex systems form from simple systems that work. The inverse proposition is true. You can't build a complex system from scratch. You have to start over with working simple systems. I think an interesting thing I'm seeing in the department, I'd be curious if you saw any of this, is that we say think big, start small, but the start small always ends up being some little small greenfield project versus hey, let's actually try to fix the legacy thing. And we almost set ourselves up for even if you do incremental development, it's still a waterfall delivery because you can't deliver it. I mean even Kessel run fell into this trap of we can't deliver the thing until it replaces all of the legacy theater, battle management core system, of course large acronym. And similarly we see that with almost every thing. So have you seen any attempts to make that a little bit easier? I know you talked about a integration environment for people to be able to test with war fighters directly.

Bess Dopkeen (16:51):

Yeah, we actually have, there's been cool things that have been happening in the Pentagon. The acquisition folks have this kind of like what is out there that can solve, okay, sorry, I'll start. The joint staff is responsible for joint war fighting capability. And so they have, here's what we want to do if we fought in a joint event at some point, right? And these are the joint war fighting capability concepts and then underneath it, there's a ton of things that we can't do today. One could call them gaps, although we're not supposed to admit that we can't do everything, but we can't do everything. And so then there's the acquisition community is doing this review of, okay, what do we have today that we can easily buy and solve some of, excuse me, close some of those gaps. And then what our science and technology teams are doing is what is it that is coming down the pike?

(17:46):

What are cool tech companies building are the things that we can iterate on the tech companies that might actually get after those joint warfighting capability gaps and start to close them. And so one of the things that we're doing is this experimentation world, right? In which we are, so it's called Rapid Defense Experimentation Reserve. Sorry, yes. Things get set up and then you'll live with them forever, but it's called RADER. But you actually, we have these technical readiness experiments. So the T-Rex right, and so you can actually just show up as a company and test out your thing in a kind of controlled environment where the war fighter actually picks it up, shakes it, drops it on the ground, does something or tries to do something and can you connect the things that need to do. And usually the tech companies then have an experiment that they work with four or five people to actually get something done that would've normally been a gap.

(18:42):

And then you actually take it out into a contested environment and you go to these experiments and you bring these kinds of folks that are recording how your technology gets after that capability gap. And then we collect that data and we show it to the services and go, "Hey service, this is what that technology did. It closed this joint fighting capability gap. Who's responsible for buying it?" And what we found is for the things that actually close service capability gaps and things that are obviously are mine, if it's a tank or something like that or something cool that you inject into a tank and I will buy it as the Army, but if it's things that are actually bringing massive capability advancements to three combatant commands that might involve the stratosphere. I don't have a balloon person and I don't have a person that works with flight vehicles that hang out in the stratosphere for a little bit.

(19:43):

I don't know how to, I can't do that. And we had the same issue for software people, right? In the Air Force you don't have an MOS for software people and then we're going to have to design one and that's hard. And we don't want to bother the people who are in charge of people. So instead we'll just try to fit this in a different way or we just don't do it. So right now we have a lot of issues by that, but the only way to get at that is to collect that data on how well your technology performs and then get back to the services and say, this closes this capability gap, ideally a joint warfighting capability gap and someone needs to buy it. And so that's how we're trying to pull things through from that science and technology world more into the acquisition world where there's been that kind of valley of death in between.

Bryon Kroger (20:24):

There's an added benefit there too. One of the things I'm pushing on really heavily on the government side of the house is how we run competitions. I've come to the belief and I thought that I had it all figured out when I was on the other side. We did all this agile acquisitions and then now I'm seeing those competitions from the outside and I'm like, the competition's still a farce. It's not actually competition. You're not testing if it's custom code, how well people can write code or if it's existing code, how well it fills the capability gap. So I think having those environments also allow you to do more of a fly off style competition between vendors. I think that's really powerful. So last question I want to ask you. We just heard a ton about unlearning. This is a a lightning version. I'm going to put you on the spot. What are one or two unlearning you would have for senior leaders in government and then on congress as it relates to digital government?

Bess Dopkeen (21:18):

So I'm going to take JFN, Joint Fires Network, as an example. So Joint Fires Network. So the things that we have the teams have done because they were empowered inside of this joint fires network, we knew we had a gap. The fact that the INDOPACOM commander says this is his number one priority gives you a little bit of ability to break through red tape, but we need to be able to do this. We need to be able to start replicating things like that. But they were able to do the initial requirements document in 30 days and it's 10 pages and they were able to get through the boards and have it ready to be signed in 30 days. That is something that has never happened before and we need to be able to unlearn the way we've historically done it. That takes the joint staff massively moving in a direction that is more software based and kind of keeping it as those initial capability developments as opposed to finalizing something in the future but constantly kind of iterating in the same way that software iterates.

(22:18):

That is a huge unlearning that the joint staff is still going through. And so it only works when the four star of INDOPACOM tells them they must do it, but you need to be able to break through that gap and you need those senior leaders that say you must iterate, you must get better at this. And then that staff needs to let go of the things that they've had before. That applies to everybody and we still have, I come from CAPE, that's the independent analysis group that does the deep dives for six months and does the assessment, the picture that was like, this is how it's been done before and we're going to slowly go like this and this is what innovation does. That's absolutely correct. And new ways of doing things, iterative ways, building and testing, building and testing, trying to get at the fact that people can use things before.

(23:10):

Maybe you can't sunset the old thing fast enough, but you should get a working thing that people are transferring to as they move as much as possible. All of that needs to be unlearned and we still have that fight. I mean even on joint fires network and coming from the cost community, but you still have a fight of like, well, I don't agree that you did your cost estimate well enough on that. And so back in the day when we did these major automated information systems, then they would have to be done in four years. So everything just went to right before four years, so they wouldn't get there and they never even turned it on beforehand. All of that, you take that history and you project it forward and we are never going to update any software ever. You have to unlearn that and pivot to the world where we are no longer counting lines of code as success, but you're accounting actual capability and how often you get new capability and is it in my right direction towards my vision delivered to me quickly.

Bryon Kroger (24:14):

That's great. I didn't even plan that, but we have a ton of talks specifically related to those two issues. So I'm excited. Thank you so much for coming out. I appreciate you. If you don't know, this was actually a scheduled pivot. You might've noticed, so I asked best to come two days early to help us with a travel snafu. So I really appreciate your flexibility and I love the conversation. Thank you so much. Thank you

Bess Dopkeen (24:35):

For having me.

‍