New to Defense Mavericks? Start here
Sept. 10, 2024

Decoding Agile Acquisition Frameworks with Jonathan Mostowski

Decoding Agile Acquisition Frameworks with Jonathan Mostowski

This week, Ryan Connell chats with Jonathan Mostowski, author, public speaker, and president of Agile Acquisitions LLC, about the truth behind “hacking” bureaucracy in government contracting, the development and impact of agile acquisition frameworks, and his career journey from a contracting officer to an innovative leader in the field. Jonathan shares his insights into creating culture change through contracting, the importance of understanding rules and strategic risk-taking, and his experiences authoring the TechFAR handbook. Tune in for a refreshing conversation on how to look at the defense procurement process with different eyes.

TIMESTAMPS:

(1:19) Meet Jonathan

(3:18) What is a Scaled Agile Framework?

(4:08) How Jonathan created the TechFAR Handbook

(7:49) The biggest challenge contractors face

(10:40) Why Jonathan doesn’t “hack” bureaucracy

(13:35) Culture change needed in contracting

(15:01) Jonathan’s writing process

(18:55) What would you change if you were king for a day?

(22:09) Why reward systems are key to success

(26:26) Are SBIRs sustainable?

(32:02) The reality behind the Valley of Death

LINKS:

Follow Ryan: ⁠https://www.linkedin.com/in/ryan-connell-8413a03a/⁠

Follow Jonathan:https://www.linkedin.com/in/jonmost/

Leading Agile Acquisitions Book: https://www.agileacquisitions.com/product-page/leading-agile-acquisitions

TechFAR Hub: https://techfarhub.usds.gov/

CDAO: ⁠https://www.ai.mil/⁠

Tradewinds: ⁠https://www.tradewindai.com/

Transcript

[00:00:00] Jonathan Mostowski: I don't really hack bureaucracy. Very, very rarely do I hack something because when you think of hacking something, you're going around the system and the procurement and the bureaucracy in general in the government is like a living body. Okay. You can go around it one time, maybe two times, and you will shock the body and the body won't know how to respond.

And you kind of get away with it. But then like anything else, the body begins to develop an immunity to it. And in the government, that immunity is takes the shape of policies of additional governance. And eventually, not only do you have more rules to traverse in the future, you've also pissed off a lot of people. 

[00:01:00] Ryan Connell: Hey, this is Ryan Connell with the Chief Digital and Artificial Intelligence Office here today with Jonathan Mostowski. Jonathan, how you doing? 

[00:01:07] Jonathan Mostowski: I'm doing great. Uh, I really appreciate the opportunity to be with you on the show. I'm a big 

[00:01:11] Ryan Connell: fan. Yeah, you and I have been connected, I think for years, it's been a while since we've talked.

you want to give a quick intro to yourself? 

[00:01:17] Jonathan Mostowski: Uh, so I started out as a contracting officer, uh, about 20 years ago at the National Geospatial Intelligence Agency. I was there for about 13 years, but about halfway through, I took over the application service contracts, which was basically the software development and, uh, serendipitously, I guess, Tish Long had just come into the agency as the director.

And declared we were going to be a scaled agile framework agency, which nobody really knew what it meant. But everybody was pretty sure you couldn't do it under the far because of the role I had, I was sort of forced to figure out how do we solve this problem? And I ended up developing some models which were new at the time, but pretty commonplace now around how to acquire these capabilities, tested them out, proved them and, uh, as a result, sort of received a request from the Office of Federal Procurement Policy to co author a document.

That would later be called the tech far handbook. And this was kind of the first set of policy and rules around how to acquire agile capabilities under the far. So I did that and then was asked by the White House to come over to the U. S. Digital Service. In the early days, I ended up spending about four and a half years there between U.

S. Digital Service and Defense Digital Service, did all kinds of fun projects, helped craft some legislation, wrote a bunch of policy with DPAP, and then I, of course, worked on a lot of acquisition strategies. From there, I left and helped do a tech startup focused on DOD national security capabilities, was there for also about four years, helping with contracts, proposal, pricing, rev ops, chief of staff, all kinds of, great experiences.

And then I left last July to take my consulting company full time. So it's been around for about nine years, but I've been doing it full time for about a year. And I'm really focused on supporting government acquisitions and companies that are trying to get into the space and make things better and building bridges to bring the two together.

[00:03:06] Ryan Connell: Oh, a lot of things said there. I jotted some notes because I wanna dive into some things. Um, what is a scaled Agile framework? 

[00:03:13] Jonathan Mostowski: Great question. So, you may know it by its acronym, it's commonly referred to as safe. 

[00:03:18] Ryan Connell: Okay. 

[00:03:18] Jonathan Mostowski: And scaled agile framework is a model, so agile being a, a mechanism for iterative software development, scaled agile framework is kind of this model that is used to.

Potentially do agile in a much larger enterprise focused fashion. So it's, how do you do product managers, products of products? How do you scale it across the agency? It's one of the more common, large, approaches to agile or agency enterprise level approaches to agile. There are other approaches that are starting to come up, but that's generally where it comes from.

[00:03:49] Ryan Connell: Okay. And then that kind of dovetailed into the, tech far. Yes, correct. Okay, so I've referenced the tech far several times in my career. I had no idea that you were involved with that being authored. So that's pretty cool. what was it like? What's the vision? Like, how is that intended to be used?

Who's using it? Are people using it? 

[00:04:08] Jonathan Mostowski: Yeah. So when, you know, when it first came out, it wasn't like, Hey, can you help write this thing called the tech far? Uh, I received a message, unprompted from OFPP asking me to coauthor a document. And I had no idea who I was working with other than the OFPP person who was kind of managing it.

I didn't know who the person on the other end of the document was, but we were collaborating in a document. So I'd write something and the comments would show up and someone else was writing something and I'd write comments. And basically the concept or the challenge we were given. Was, can you help us come up with how you can do these things under the FAR?

And that was the main thing, right? Everybody was somewhere like, we can't use the FAR. Like we need this whole new set of rules and policies around it. And myself and this other, unknown artist, unknown author at the time, had both done it. So we put together basically what are the best practices, you know, And because at this time the term agile wasn't even really known in the government, right?

Like now it's sort of, kind of maybe even overused. but people didn't know what that term even meant that were inside the government. It was an industry thing happening on the west coast. And so a lot of the document is just explaining what is agile? How does it work? How can you do this in a government setting?

And then saying, like, what parts of the FAR actually enable you to do this, right? And that is, you know, a lot of people will say, like, unless the FAR tells you you can't do something, you can do it. And that's true. In fact, I recently published a book and a big section of my book is actually reciting what's in the FAR, uh, in section 1.

201, all about all the best practices of doing acquisitions. And I bolded and highlighted the pieces that's really sound a lot like agile best practices. And this stuff was written long, long before anyone was using those terms, but it was all the same ideas. And so the TEPFAR handbook is Hopefully an easily digestible way for someone to kind of get into the game of doing acquisitions.

I will say agile acquisitions. I will say the document was written in 2014. We have learned a lot since then. the actual next phase of the tech far handbook. was the tech far hub, which I built the original version of, and that's a live version that you can go to. And it's got resources and tools. It's got examples.

It's got all kinds of things that help someone who's wants to do this stuff, right. But doesn't know where to start. You can start there. And that's more of a live, capability. That's more current. 

[00:06:29] Ryan Connell: Got it. I'm going to take a shot in the dark with an example, and you can tell me if I missed the mark here, but, one of my, uh, favorite.

Slash unknown favorite unknown, far references is always in 39 where it talks about like modular contracting being the preferred pathway for software. Is that kind of one of the things that we're talking about in this area? 

[00:06:48] Jonathan Mostowski: Absolutely. So far part 39 is actually titled acquisition of it or it acquisitions.

The part you're specifically talking about is 39. 103 And it's amazing. It is exactly as you said, it's modular acquisitions again, long before anybody was talking about, how do we do this agile stuff? The FAR council had already put in a whole section of the FAR that recognize that it acquisitions should not be very, very large and very complex because IT changes so quickly that if we spend 5 or 10 years buying and delivering the technology that we actually want to solve for is going to be in a totally different space.

And that was there. That's a perfect example of, leveraging what the FAR tells us to do this. 

[00:07:34] Ryan Connell: So I just, I'm going to dive in a little bit. Like what, is in your opinion, the reason that it's not this obvious thing to the 180, 000 defense acquisition professionals? 

[00:07:44] Jonathan Mostowski: of the day you step in, you are personally and professionally liable. for all the decisions you make as a contracting officer. That's the first thing you learn. The second thing you learn, and that you take an oath to, is that you are going to ensure the proper and responsible execution of taxpayer dollars.

That's what you hear on day one. And not only do you hear it on day one, you hear it every day, pretty much for the rest of your career, unless you're in charge and everyone who you're supporting Who has also heard that same idea their entire career, drills it into your head. So now when someone comes to you and says, Hey, I've got a great idea, let's do things differently.

You know, red lights start flashing. This is scary. This is scary stuff. If I do things differently, I don't know how things will turn out. And part of this ties into not only the contracting officer fear of risk, but sort of the career arc of working in the federal government, right? You advance in the federal government in large part due to the amount of time you spend in the federal government.

So if you do something that makes your boss look bad, then you're affecting their career arc. They're going to affect your career arc. And so it's just this combination and continual piling on of fear of risk. and it's not taught, it's not taught in contracting classes about how to think laterally, right?

It's taught of, here's the rules, apply the rules, black and white is good, gray is dangerous. And so, you know, now we have things that I helped create the digital IT acquisition professional training or the DITAP certification, uh, that is a FedSiv certification that does teach and has now taught thousands of contracting officers.

How to do this kind of stuff, but it's not part and hadn't been part of the core contracting certification. So it's just a matter of, learning and embracing risk. And, you know, I will say that like my personal definition of, innovation is three rules. It's a belief that almost anything can be done differently and perhaps better, a deep understanding of the rules, regulations, and policies that govern the thing you wish to change.

and responsible risk taking. And so you really can't do number three without number two, right? You have to know the rules. And so like for a good portion of my career, I had this really cool title called bureaucracy hacker. I love it. Other than it's super hard to spell, it's like a cool title. but the reality is, and like when my bosses would be like, go hack that bureaucracy.

And I'd be like, Hey, you know, boss, I got to tell you, I don't really hack bureaucracy. Very, very rarely do I hack something because when you think of hacking something, you're going around the system and the procurement and the bureaucracy in general in the government is like a living body. Okay. You can go around it one time, maybe two times, and you will shock the body and the body won't know how to respond.

And you kind of get away with it. But then like anything else, the body begins to develop an immunity to it. And in the government, that immunity is takes the shape of policies of additional governance. And eventually, not only do you have more rules to traverse in the future, you've also pissed off a lot of people.

And, you know, I kind of had this concept that I talked about breaking glass, you know, in, in bureaucracy hacking, you can break glass. When I was at DDS, we respond, we, we reported. To the, secretary of defense as chief of staff, like effectively the secretary of defense, we had like a waiver to do whatever it was we wanted to do to help improve the department.

So we could go over people's head. We could break glass whenever we want it to. But the funny thing about breaking glass is you can't really put it back together. So yeah, you might get something done, but are you going to be able to do it again? Are you going to be able to do it when it really matters?

So not to say I never do it. But I reserve it for very important things. Are there service men or women's lives in danger? Are there mothers and children's in dangerous situations? Like sure, I'll do whatever it takes legally to, you know, help those situations and go through rule change, uh, rules and whatever else.

But as a general practice, your best bet is just understand the rules that are actually very easy to navigate once you know how to use them. 

[00:12:05] Ryan Connell: Yeah, it's spot on. Right. I mean, I've been thinking through this, like, uh, Visual that I haven't actually figured out yet. So I'm early to talk about it.

But like I almost want to create like Maze isn't right the word right word But like, you know when you have like a video game and you just like one of those video games You just bounce up and down That's all you have to do and like you're either going over something or under something over something under something But like I'm not It's like, I just want to draw the line, like the major part of the screen that's blocking you are going to get you, you know, having to use a new life is the rule.

But as long as you know where to be in the rule set, because that's the best part about a bureaucracy is there's a waiver for every rule, right?and so just understanding where to be jumping and ducking and et cetera. Um, I feel like that comes across. More responsible, if that's the way to say it, than just coming out and saying I'm breaking all the rules.

[00:12:52] Jonathan Mostowski: I think that's a great analogy, and I think you and I kind of come from the same era, uh, Mario Brothers, right? Yeah, yeah, exactly. And, you know, really, there's all this stuff on the screen, but the people who could do it in like 10 seconds, like from start to flag, Was because they memorized exactly where all the places were to jump and duck.

and it becomes, I love that analogy. it's exactly what 

[00:13:12] Ryan Connell: you just solved the analogy that I've been figuring out. So that's it. It's Mario brothers. Yeah, I love it. Awesome. Well, so it sounds like, you know, tech far tech hub, uh, agile acquisitions. This has been, you know, your career path. You've now, you mentioned it a little bit earlier, but you've, you recently wrote a book, Leading Agile Acquisitions, I believe is the title.

want to talk about that journey at all? 

[00:13:34] Jonathan Mostowski: Sure. Uh, so it's, Leading Agile Acquisitions. it's a guide to creating culture change in government contracting. I would describe it a little bit differently. I would say what my intent in the book is actually to talk about culture change using contracting as the framework.

Cause if you can change culture around contracting. My theory is you can change culture around any large bureaucratic machine. So that's the concept of the book. to be honest, I've, always wanted to write a book when I was a little kid. I tried a few times to write books about different things and just, you know, never really got it there.

and then, you know, life happened and I never had time and I just, it was one of those things. I was like, one of these days I'm going to write a book. And so I had a document that was on my drive and whenever I had a thought, I put it in writing and I would just kind of tuck it away in this document. I literally called a book.

and then, uh, as I transitioned out of my full time role at, the startup and I was doing my consulting company full time, I kind of found this unique space in my life where I was like, I actually have time if I choose to that I can say, I'm going to spend. X amount of hours every day just working on this book.

And I did it. And I will say, you know, writing the book was actually pretty easy. Like I got from first letter on the screen to first draft a manuscript in, in a couple of months. 

[00:14:54] Ryan Connell: There's going to be authors that hate that. You just said that. I think 

[00:14:56] Jonathan Mostowski: let me give the other half. It took me over six months to go Full manuscript first draft to printed book and it was one of the hardest things I've ever done.

It was rereading something over and over again and I I Have a thing about typos and grammar and all that and just constantly no matter how many times I read it I would still find issues in my document. I was like no And even the first print that came out in this book, I got it. I was so excited. I started flipping through and I was like, Oh my God, there's a typo.

so I fixed it. And hopefully if people buy the book and, find typos, please let me know. I want them all fixed and found. but anyway, yeah, so I went through the process. I had help from a bunch of friends who've written books. I got a lot of guidance. I talked to Dan Ward, talked to Sabra. I talked to my friend Noah, like lots of people gave me guidance on how to work through and help me with some of the editing.

but it is, it's an experience and I would do again, but at the time was thinking I'm never doing this again. Yeah. 

[00:16:01] Ryan Connell: All right. So is it, uh, Intended to be a guide or like, how would I describe the book to a colleague? 

[00:16:08] Jonathan Mostowski: So it's kind of a combination of the best practices that I've learned over 20 years.

And most of those 20 years have been around innovation and contracting. it's a lot of those concepts and examples kind of interwoven with sort of a, memoir of, my experience because I do have like a, a sort of weird, I'd say very lucky career. I just kind of always found myself in the right place at the right time for the right opportunity.

So I literally went from, I mean, it was NGA, so it was the pay band system, but I went from a pay band two to a pay band five in five years, which is almost unheard of 

five years. But it was because I was constantly being thrown into the worst situations at N. G. A. And solving those problems for senior leadership.

And they were like, just wow. Okay, here's another hard problem. Here's another hard problem. and all of that goes back to that concept of innovation that I was talking about. You know, I took that model. It's been in my head this whole time and I applied it to every situation. And that Kind of gave me new opportunities.

But, so it's sort of a mix of those things. I would say like, Hey, look, you know, this book is for people who want to change culture in the federal government, program managers, product owners, contracting officers, especially acquisition nerds. And, you know, the whole second middle part of the book is talking about the far, like there might be someone who's like, I don't care that much about the far.

Like, I don't want to necessarily know all those parts. Don't read it. But the first part talks all about culture change and leadership. The last part is all about the things you can do within the FAR and out of the FAR to streamline acquisitions, to procure agile development services. And they're not opinions.

These are things that I've done, that I've helped agencies do, that I've helped companies do. There's a whole section that's dedicated to industry. I've been on that side. I know the challenges. I know what it takes to be successful there as well. So it is literally a guide. Hopefully with some interesting stories woven throughout it.

and I hope it's inspirational. I hope it encourages people, especially contracting officers to say, if you take responsible risks, this job is a lot of fun. You actually do get to be a business advisor. If you're working at the pointy end of the spear, I mean, you feel the difference that you're making.

And I've done that. I've worked in, you know, really interesting projects and actually I've seen them executed and it, feels good. 

[00:18:28] Ryan Connell: yeah. Sounds inspirational. I love the dynamic of like some very deep dive far stuff, but then also the cultural stuff.

So appreciate that. Okay. Yeah. I mean, you, you hit a little bit earlier, um, the importance of culture. I'm curious, like, where do we go from here? Like you're king for a day. Like how are we solving all the challenges? Like, I'd love to just hear your perspective on, you know, if you actually had all of the decision making authority, what that looks like.

[00:18:54] Jonathan Mostowski: well, the first thing I would change is, it would affect appropriation of law. So I actually think the biggest obstacle we face in innovation is appropriation. And, I'll give you a perfect example of this. You've been in the government a long time. What happens every fiscal year?

They get the money later than they expect it. They have to rush to execute the funds. They come up on the contract, end of fiscal year, close out date, and they sweep the funds to an IT omnibus contract where they buy a bunch of printers, laptops, and things that they probably didn't need and will probably go end of life before they actually deploy them.

What if instead of expiring funds, money was actually treated like money? If I, in my household, decide to save money By being fiscally responsible, I can use that money to buy cool stuff. Well, what if we said, hey, program managers, be judicious on the execution of your budget. And instead of punishing you and giving you less budget next year, any money you don't spend will go into an IT innovation fund.

Your IT innovation fund. So when that really cool company shows up at your office with a capability that you would love to have and deploy for your customers, but you can't because you didn't program for it, you can actually fund it and you can fund early research and development. And most importantly, if you do it right, you can fund the transition from research and development to operational deployment.

That is the cure for the valley of death, in my opinion. So that would be the first thing I would do. The second thing I would do would be to educate. I would, I would work on the culture. I would incentivize leaders in acquisitions to incentivize their employees to fail fast and fail small. To not just hand out bonuses and certificates and plaques because you had a short palt time or because you, you know, you had the lowest findings on a, an IG review or an internal audit.

I'd be rewarding the ones who did creative things, who were the first one to do something. The first one to do a down select. The first one to do oral exchanges. The first one to do a tech challenge. The first one to structure a vehicle specifically to attract non traditional vendors into a mechanism where we can access them quickly.

That's how I would attack it. 

[00:21:18] Ryan Connell: Yeah, that's super interesting. I want to dive into that, that second part a little bit. cause that's, an area that I've spent some time thinking about as well. And, where I get hung up. So I'll give you the bad first, right? Like you see, I've seen so many examples of contract, uh, execution.

We, we reward, Within budget and how fast you got it done. Right. Nothing to do with impact, right. To the war fighter. uh, lots of analogies there. I won't get into. And so, I'm constantly saying similar things to what you said, but I am fearfulif you're just going to incentivize, Oh my gosh, you did a great, cool thing to only, solicit for non traditionals as an example, you're still in the same boat where you're rewarding the contracting or the procurement element.

and I'm curious, like how you see that playing out. Is there a way to actually, I don't want to say wait, but effectively, make the reward system based off impact. 

[00:22:12] Jonathan Mostowski: Yeah, man, I love that. net promoter score for contract execution, right? There's a lot of factors that play into it. But, you know, I always think and I've always thought of my job as a business advisor as a contracting person.

And that's why I love this field. Because when you're a business advisor, you are involved in the whole process. You feel ownership of the delivery. So I completely agree with you. It. It's the same concept we're telling our program managers in this Agile modernization initiative across the government is, hey, stop deciding what your customers need.

Go talk to them. Then, after you give them something, right away, ask them if they like it. Ask them what they don't like about it and fix those things. Absolutely, we should be incentivizing those things. I, you know, I will often say, like, when you incentivize something, you inevitably disincentivize something.

It is just like the natural balance of things. If I incentivize you to do things faster, they're going to have lower quality or more cost. And so on and so forth. And so, you know, I appreciate you kind of like calling out, like what I said, because like, if you just incentivize, you know, the wild west, you're going to have the wild west.

And I've been in contracting shops that were kind of the wild west. And those are scary too. So, yeah, I completely agree. It's not just about doing like the cool thing. It's about seeing the cool thing through adjusting the cool thing, getting feedback and helping the organization learn how to be part of the solution, not just handling and processing.

That's the boring part of contracting. I know we should change the name, right? Like the name contracting talks about the worst part of contracting. Like I can read clauses all day long. I know what they mean. But I don't like doing it, you know, I was incredibly fast at writing contracts, but I didn't like it.

I did it fast because I didn't want to do it anymore. I wanted to get to the fun part where I could go hang out with the program office. And like, see what the contract did and like, give them advice about like, Oh, you're having a problem here. I could change this thing and then we could do it that way.

You know, that's cool. That's fun. 

[00:24:14] Ryan Connell: Yeah. I've literally never thought about that. Right. I love that. That the name of contracting is the worst part of contracting. Uh, that's hilarious. I love it. Well, do you have a, do you have a proposed new title? Yeah, business advisor is the true thing, but, you know, it doesn't necessarily encompass the other acts aspect of it, which is, you know, executing the, yeah, exactly right.

Because advisory doesn't necessarily give you that, like, uh, understanding that there's a decision authority with it. Yeah. So I understand. Awesome. all right, I'm going to, uh, segue here. I saw something on LinkedIn, uh, recently from you all about Sibber phase three.

you want to talk Sibber phase three? 

[00:24:56] Jonathan Mostowski: Yeah, sure. you know, do you remember like, since like 2017 to like 2022? Yeah. The biggest thing everybody wanted to talk about was OTA, right? Other transaction authority. It was like the hot topic. and then we started transitioning somehow into like Sibber is the hot topic.

And they both were the hot topics for the same reason. they gave you the ability to direct award the follow on. So it solved that one problem of like, Hey, it's pretty easy for me to bring you in on a relatively low dollar, like exploit exploration of capability. It is really difficult, even appropriation set aside.

It is really difficult to bring you back. You specifically to deploy the thing you developed. We've got to run a competition, which I'm not knocking, right. A competition and contracting act. We should, when it makes sense, run competitions. And it should be our default, but OTA and sever give us the tool in our toolbox.

When running a competition is not in the best interest of the government to get directly to that vendor. And so it's like addictive.and then OTA was addictive because not only did it give you that, but it kind of gave you this blue sky approach to contracting, there were no rules. So you could actually.

Stop for a second and say, how would I do this best if I could do it my way? And then of course, what do we do? The organization developed an immune response and now there are policies and rules that govern OTA. And it looks a lot like far contracting. It looks a lot like the best part of far contracting the commercial contracting far parts, but it looks a lot like far contracting.

So then we say, okay, well, what makes Sivir so special? Well, Sivir does give you not only the direct authority, It gives you a statutory preference for director. So now it's not even like I should, or I shouldn't, it's. You're supposed to direct award the follow on to these people because Congress invested in the early research.

That was the whole purpose of the program. So you have that. The second thing you have, other people's money, right? Because who's got enough couch cushion money to invest in all the cool ideas out there? Nobody does. So Congress is like, okay, great. We'll create this fund. We will give you non program dollars To go out there and experiment customer or industry and requirement owners.

And then you have air force who like really turned it into a machine, right? Like, I won't say there's not room for improvement, but like, they developed a process around it that rolls these things out like a factory quite literally. And so now it's like, Oh, wait a minute. I can get this idea that nobody really has money for into the system and it becomes addictive and it becomes addictive, not only to Because it's a way to get some traction, some, investment and ability to hunt and go talk to people.

But it gives the program offices free money. And so what you start to see is entire organizations that are kind of running off SIPR funds. And they're doing cool stuff and companies are getting money and they're doing cool stuff. So it's like, it's not a bad thing, but is it sustainable? Is it scalable?

At what point do you say, how do we go from these like 750 K or 1. 5 million? One to two year long tranches to real scalability, which especially in the Department of Defense is a lot more than 1. 5 million. I mean, that's like maybe one team if you're lucky. So that's kind of where we're at. I mean, Sibber phase three, like I, I encourage all my clients pretty much to get at least one Sibber, right?

Like it is a tool in the toolbox. So yeah, let's go after it. Let's get one, but don't build your business around it. 

[00:28:47] Ryan Connell: I'm curious, you know, maybe we're on the brink of this. Maybe I'm, I don't have the best, uh, data, but I'm thinking we could be getting to a point where the popularity of Ciber has led to, an abundance of Ciber awardees, abundance of similar solutions, that have been awarded using the Ciber, you know, at least phase one and phase two.

Um, you talked about Sika a bit and. Uh, I'm curious if you have any thoughts on like the, future, I guess I'll call it that way, but giving the statutory preference, like if someone told me to go build, I don't know, AI for data labeling, I'm going to guess that there's multiple, if not, you know, over 30 sever companies that do something or several solutions that have been awarded in that space.

so I've inherently like, not only have I.removed Sibber, but sorry, remove Sika, but the statutory preference now applies to a lot of companies. and I'm curious how we navigate that as that scales. 

[00:29:43] Jonathan Mostowski: that's a really interesting question. well, I will, I will say a caveat, you're not circumventing Sika, right?

The reason this preference exists is because Sika was met in the earlier phases. So just like, you know, it's too upset about it, but it doesn't change your point. I just, you know, for the, concerned rule followers that listen to your show, I just want to be clear on that. but it does have that implication, right?

If you have 30 companies that all have now a habit. fulfilled Sika, and now can and should receive direct awards, what do we do? Well, that's an okay problem to have, right? I mean, it's, the DoD for a while has been kind of obsessed with this idea of like, how can the DoD be like a VC? And, the answer is you can't, and you shouldn't be.

There is plenty of VCs out there. There's plenty of money to invest in early stage companies. What the DOD needs to do is lower the barriers. So those investments actually pan out. But in your example, it is kind of like the VC situation. You fund a lot of companies, a very small percentage of them will be successful.

And when they are kind of covers your costs on all the other ones. So, you know, we do 30 sivers for AI data labeling, and one of them. really works. That's a win for everybody. And I think what you'll find is there will be situations where at some point, two or three or 30 vendors are going to say, wait, I have the statutory.

There's a lot of, deference given to CEOs. To say like, this is the one that's closest, or if you both have the prioritization, then, you know, I'm going to make a choice. Right. So it's, I think that's an interesting, it'll be an interesting GAO case at some point when I read it, I'm going to be like, Oh man, Ryan called this 

[00:31:34] Ryan Connell: and as you drew the VC analogy, all I'm thinking of is.

Is the Valley of Death just not a problem? It's the VC, like, it's that economy. it's that you've invested a bunch of things and some are going to be successful and most will fail and that's purposeful. 

[00:31:54] Jonathan Mostowski: Oh, touche. I'm going to say, I'm going to stick to my, original position and say, No, that is not what is happening.

There is a very real valley of death in government transitioning from innovation to operational deployment. And that valley of death is built on or within ATOs or FedRAMP, depending on where you're operating, uh, appropriation and funding is the real thing, right? Like. let's play the Siber concept out, right?

Let's just walk through it. I'm a new company. I'm a little wet behind the ears. I got some seed money. I have a cool idea. I talked to you. You're like, yeah, I'll be your sponsor. Go do this Siber thing and we can work together. And I'm like, great. And I get a Siber phase one, which the requirement is to deliver a report to you for about 750, 000.

So that's like one, one and a half people on my team to actually do that work for a year. 750, 000. You get your report and you're like, man, you guys at Agile Acquisition, you're on to something. I want to do a phase two with you. I'll be your sponsor again. Go to phase two. I get my phase two. Now you have one and a half million dollars.

Well, better yet, I got matching funds. I got two and a half million dollars. Maybe I have a full team dedicated. What's the requirement to deliver you an MVP, which we know in Agile two years, in addition to the one first year, and I haven't even built an MVP, like I'm not Agile already. 

[00:33:24] Jonathan Mostowski: I actually, I do better, right?

I give you that MVP like in month one and I'm just iterating on it and about a year and a half into it, you're like, you guys are awesome. I want to deploy this across all of CDAO, but I didn't know you were awesome until now. So I'm going to put it in the budget request this year. And in two years, when I get that money, you're going to be a program of record.

What do I do for the next two years? Who's paying? Do you, okay, do you have any money to pay me? No, no, no, no. I've been funding this out of sever. That's the valley of death. And if my investors are like, well, we believe in you, we're going to give you more money to help you get through this. I still have to get through the security requirements, all of these things that are just very, very difficult for small companies or new companies to the space.

And you burn cash. And so like in the private sector, You know, it's a lot easier to test market demand and get meaningful feedback back to investors In the government, it's very difficult. Like I can get a thousand people in DoD to say, I love your product. I want to work with you, but I don't have money.

That is useless information that does not help me or my investors make decisions at all. Because it happens a lot. I can't tell you how many meetings I have been in where we have sat across the tables from generals and colonels and people who are like, they can make decisions. And they're like, we love you.

We want to work with you. And it just dies on the vine because it's hard for everyone, even the most empowered people in federal government, maybe even harder for the most empowered people in the federal government to spend money. And even if they wanted to, and they had the money, they then have to get a contracting officer that'll do it in a way that gets the money.

That company in OTA and separate. We're right back to the beginning of the conversation. 

[00:35:09] Ryan Connell: Yeah. I appreciate that. That was, that was well said. Um, Hey, we're at time. So we got to wrap, this was an absolutely incredible, conversation. Jonathan. Appreciate your time. 

[00:35:18] Jonathan Mostowski: Yeah. Likewise. This was fun. Anytime.