Max Reele (00:14):
I am Max Reele. I'm a Air Force Lieutenant Colonel on Active Duty still, and I'm here to talk to you about where do software delivery orgs belong, and I hope by the end of this we have one real clear-cut answer about exactly where they belong. That would be really convenient for all of us who are trying to figure out how to lead software delivery organizations, and set those people up for success. Where I work now is at Defense Innovation Unit. Prior to working at Defense Innovation Unit, I worked at several different software delivery organizations, three of them to be exact, over the course of the last seven years. Prior to that, I was also doing embedded systems with software. So software has been a part of my career experience for about the last seven or eight years. I take that experience with me now into Defense Innovation Unit.
(01:02):
I think most people are familiar with what DIU is since we have mostly a public sector presence here. But if you're not, there's a few stats here on the chart to just show you what we measure ourselves by, which should be a really strong indicator about what we care about achieving, but essentially leveraging commercial technology to meet defense sector needs. That is the primary goal of DIU. We have a fairly new director, Doug Beck, who came to us from Apple. Prior to that he was at DIU. So he has good context in the defense sector, and you can see on the map the locations where we are. Why is that important? That's important because we're also here to do a bit of recruiting. We have a diverse portfolio, so all of you that care about public sector, and potentially defense work, and maybe have served or are currently serving.
(01:49):
If you're interested in DIU and you think your skill sets can match to any one of these portfolios across the range of the tech spectrum, please reach out. And you can do so through a program that we have called GigEagle. GigEagle is a bit of a new platform. The website is up and running. There'll be a link to it at the end of the presentation, but that connects people who have Reserve time or Reserve capacity and want to serve in the Reserves and use their time for a DIU project, or any project actually, across all of the Services. But DIU is the team running this project. So we're posting our first gigs on GigEagle, so it's like gig work for military Reserve capacity. The role that I have at DIU now is as the Air Force Service lead. DIU is an OSD, Office of Secretary of Defense, level organization, so we're represented by all of the Services even to include the Coast Guard.
(02:47):
I don't know how they got in there, but they're in there. And as the Air Force Service lead, I work with all of the Air Force members that are a part of DIU. So if you're an Air Force member and have questions about DIU or any question about DIU really, you can come to me. But most specifically, I'm familiar with the Air Force personnel, care and feeding, as well as the Air Force projects that we work really hard with combatant commands as well as acquisition alignment. We'll talk a lot about that during this pitch to figure out the right transition path for DIU projects to make it into operations. We care very much about transition. Replicator, awesome talk happening later today that I would encourage everybody to tune into about the genesis...fireside chat between Josh and Joy...about the genesis of the Replicator project and how Deputy Secretary of Defense Hicks came to make a very public announcement about what the United States is poising ourselves to do regarding the Replicator program.
(03:39):
That is a DIU-led effort. There's a defense innovation working group that is chaired by the Director of DIU that is leading the Replicator initiative that has been capitalizing most of my time. Any working hours that I have is working on that Replicator project. I'll be in the Pentagon the next few days this week working on that project. So questions about Replicator, happy to talk about that too after the pitch, but that's not what Bryon asked me to come here and talk about. What Bryon wants me to talk about is where do software factory... not software factories, I'll stay away from the term, where do software delivery organizations belong? I have a thesis about this, and most of you have heard me talk on this topic in the past. If you haven't, I'll rehash it just really quickly. But the thesis is, that the software delivery organization should be as close to the mission outcome as you can possibly get it.
(04:33):
Now, that might be through physical proximity. That might be through other means of what you would define closeness to be, but it should be as close to the mission outcome as you can get it. How many of you have seen this map in the past? I don't ask for a ton of audience participation, but I just want to see how many people still pay attention to something so ridiculous. This map is a good depiction of where the software organizations exist, but it doesn't help us understand, are there enough software delivery organizations, software factories, are there too few? So what we really strive to do is evolve off of this map to a mission area mapping so that we can understand of all the software delivery organizations that exist, do they encompass the most important missions? Are they delivering software against the most important missions that we need?
(05:20):
I can't answer that by looking at this map. I have no idea scale, quantity, or mission for any of these software delivery orgs. So I typically make fun of the map itself. It's a good depiction so that we can understand exactly what works out there, but there's just very little information that you can glean from it. Now, this shows where a lot of the Air Force and Space Force-aligned software delivery organizations are, specifically the ones who do modernized software delivery. That's no knock against legacy systems that are still trying to modernize off mainframes and all of the things that exist out there. But this is specific to organizations that execute Agile as a premise, regardless of the framework. If you look at this, in one of the major boxes is all of the ones that are aligned outside of Air Force Materiel Command. If you're unfamiliar with what Air Force Materiel Command is, it's this massive command that's built around business operations.
(06:11):
The entire command structure, the entirety of...all the way up to a three-star general... I'm sorry, four-star general...clear-cutis built around acquisition. It's Air Force Materiel Command. What they do is materiel purchase and procurement. So let's just capture that for a second and recognize that there's an entire four-star command around acquisitions and that many of the software factories fall up underneath that four-star command. The other box depicts the ones that are outside of Air Force Materiel Command. So what you can see is that we have several software delivery organizations within the acquisition alignment. They literally report up to acquisition officers through their chain of command. We have another set of software delivery organizations that report up through other types of command, more mission-oriented or operationally-oriented commands at the unit or wing level. So what's the answer? Which one is better off? Are they better off in the acquisition alignment or are they better off in the unit level or operationally aligned?
(07:18):
I wish that there was a clear-cut answer for that. The bottom line is it doesn't matter. We need to care about all of it, and that's what this diagram depicts. I've been working on this diagram for so many years. I've been wanting to do it much better for so many years, but this is what has resonated over the course of the last four or five years that I've been presenting this topic. The reason I suggest that your acquisition alignment and your operational alignment are both really important, and I know that's a really dissatisfying answer because we want to know exactly where should the organization exist to have the best chance of success - the answer is it doesn't actually matter where it exists. What matters is that you have to manage all of these relationships collectively. Why? Because at the core, what we care about is being able to execute healthy DevOps, not just DevOps as structurally, we have this written into how we do business in this organization, but we need our teams to be empowered to execute healthy DevOps.
(08:11):
So in order to do that, you need acquisition alignment with your governance cell because your governance teams, stakeholders if you will, they're the ones that truly empower continuous delivery. Continuous compliance leads to continuous delivery, not just in a cybersecurity realm, but in all things with testing with procurement. So your governance cell is the one that helps the product center or the development teams get to a true CI/CD methodology. So if you're close in acquisition alignment, you probably have an easier time working with that governance cell because the governance all happens out of the same places, as does the budgetary process necessarily, staff organizations, and a lot of them out of the Pentagon. Now in the relationship from the product center or the development teams to the users on the other side, that's what gets you to a place where you can develop truly user-centered design.
(09:06):
It's through that powerful relationship. So if all of this holds to be true, then you can have a tighter alignment to the user bubble as a product center, or you can have a tighter alignment to the governance bubble as a product center. But regardless of which one you're closer to, if you remember from this chart, whether you live in the acquisition alignment or you live external to the acquisition alignment, both of them are really important because you can't get to DevOps unless you manage both of those relationships appropriately, at least as has been our experience. And the reason I suggest this is because we've learned these lessons the hard way many times over. More to come on that in a bit. But if you remember in the backdrop of this slide was my talk from last year, and forgive me for anybody who hasn't seen that, a couple of different places that it's been presented, but this body of work was a loose data gathering.
(09:59):
It wasn't empirical data, but it was a loose data gathering that drove us to a conclusion that along that vertical axis, your proximity to mission outcomes is really important to getting your teams in a place where they can execute that healthy DevOps that we've been talking about striving for. So the least number of steps you can put between that team and the outcome that they're trying to achieve in terms of a mission outcome, the better off that team is going to have at being able to work with their users to develop the trust that's necessary to actually be building what the users need for greater mission effectiveness, and the further away they are from that, the more abstracted the way they are from that, then the harder time they'll have interpreting through this game of translation, this game of telephone between the users and their user proxies that exist on some sort of functional staff to give you the requirements.
(10:51):
So why do we care so much about the proximity to mission outcomes? It's because we have to establish that user trust. We loosely gathered the data last year and we said that after that loose gathering of data, we believe this to be true. But now I want to extrapolate on the "why" and I think this falls into learning. Not to take us down a massive rabbit hole about this, but there's formal knowledge. Quick example of this, formal knowledge, all of us feel really good about how good a driver we are, right? Everybody in here is an excellent driver. I've never met anybody who thinks that they're a bad driver. Everyone really prides themselves on how good a driver they are. I hope that that's done by the time my kids have to drive. I hope autonomy has taken over the roads, but nonetheless, like we're still in this position now, every single one of us went through some sort of driver's ed to learn how to be the driver that we are.
(11:48):
And in driver's ed, you learned academically like traffic laws and how the vehicle operates, these types of things. The basics of being a driver. That's your formal knowledge on being a driver. But as you get past that, that doesn't make you a really good driver. You can ace every driver's ed test that exists, and as soon as we put you on the road, you could be freaking out behind the wheel because you don't actually understand the context and the environment of what's around you and how dynamic that situation can be. So if you remember back to your high school days when you first started driving on the freeways and probably thought you were indestructible, but nonetheless, do you feel you're a better driver now than you were then? That should probably go without saying. That's because of tacit knowledge. The tacit knowledge is you can only gain tacit knowledge by being in the environment, and doing, and feeling, and being a part of it.
(12:40):
Out of driver's ed and getting onto the freeway, you can't at that moment in your life as a driver, you can't feel what you can feel now, when you kind of get this sense that somebody's creeping up in your blind spot, or you hear noises so you recognize that there's a big truck coming up behind you, or a motorcycle coming really quickly and to pass you on the right, those types of things you would never know on day one as a driver, even if you were the smartest, most educated person with the formal knowledge out of your driver's ed class. You can only gain that through tacit knowledge. That tacit knowledge is experiential. Why does this matter for software delivery teams? Well, the formal knowledge and the tacit knowledge drive us to a place where we know we have to do enablement for everybody on the software delivery teams. And the enablement that we do for them is formal knowledge, right?
(13:32):
We get them the ability to understand DevOps frameworks, to understand test-driven development, to understand user-centered design, to even practice at it and get in the code base and understand what good security hygiene looks like, code quality scans, how to interpret what comes out of the pipelines, all the things excellent formal knowledge that everybody needs, but you're not really complete until you also have the tacit knowledge to go along with it. How do you gain the tacit knowledge for understanding the operational experience? You've got to be in the operator's environment. So dev teams have to get to a place where they can start to anticipate user behaviors. This is how you start formulating around the user trust model. This is how you start building user trust, meaning you have to insert yourself into the operator's environment for whatever mission outcome you're trying to achieve. That takes a lot of work to manage those relationships, to get to a place where your dev teams can then feel good about inserting themselves in the user's environment.
(14:27):
And once they do, this really magical thing starts to happen. It takes a lot of work, it takes a lot of investment and consistency, but a magical thing really starts to happen. Your dev teams get the ability to start to anticipate user behavior. If they feel like they've been in the operational environment enough times, they also now believe they're a part of the mission. If there's people who have embedded themselves into where the operational mission is occurring, and they start to understand the noises and the smells of that operational environment, they feel like an operator. It's like when you're watching Rocky and the movie's over and you feel like you can get in the ring like, "Let me pull something off here." You start to feel it. You start to feel like you are part of the mission. You are no longer a supporting entity to the mission.
(15:12):
Your dev teams feel like they are a part of the mission. Really important. What clicks on the other side is that your users really start to trust that the software development teams care about their best interest and about their mission effectiveness. So they start to anticipate engagement with the development teams. They start to bank user stories so that they know they can unload them when the dev team comes back next. They start to trust that you will be back in the environment. All of these things is that maturation of tacit knowledge growing through your development team to go along with the formal knowledge that comes from the enablement. We build all of that together to really encompass from the dev side and the user side, what is going to be this user trust model. Establish consistency first, always showing up in the user environment with the full balanced team so that the operators start to understand what a balanced team means.
(16:08):
They know what the things that they're most appropriate to be saying and asking of the PM most appropriate to be saying and asking of the UX designers, they start to understand the process better through the consistency of showing up with the balanced team. Transparency, maybe this should be number one. You guys can help me out if you think this is out of order or if you think there's better ways to do this, but for the transparency aspect of it, this is wildly important. The operators need to understand how is your development teams prioritizing the work that they're doing? Because if I'm an operator, and I asked you for something that's so critical to me, but I don't see it, and you've showed up three times and you've never actually implemented the change that I asked you for, I'm going to start to feel alienated by your process.
(16:50):
So transparency of the process, show them what an IPM looks like or sprint planning, whichever framework you use, but show them how you prioritize the user stories that come in, how those user stories turn into actual prototypes, and then hard-coded effectiveness for them. And transparency is really important. Lastly is the frequency. Making sure that you're touching base with those users on enough of a revisit rate that they can feel very confident that you'll be back, and they can feel very confident that you've heard what they have to say. And if they feel like you haven't, they get an opportunity to say it again, because sometimes that repetition is important. This is the user trust model that is built up through your consistency of the formal knowledge and tacit knowledge with your dev teams and your user community. So what is... Sorry, I'll go back for a second.
(17:41):
So all of this drives us to a place that shows your dev teams being really embedded in the operational environment. So naturally this drives us to where does the software delivery organization belong? As close to the user environment as possible. At least from all the data and explanation that I'm doing, you would suspect that that has to be it. But then we'd be neglecting that whole other bubble that was in the Venn diagram about needing to be really tightly aligned to our governance. Because in our governance model, they're equally as empowered as stakeholders to have equity in what's happening out of the product center and out of the development teams. And I say all that in the framing of what is the importance of a program of record. Growing up in grade school, you all heard all these definitions of haves and have-nots when it comes to economic development and world order and all these things, and that's not necessarily the context of how we need to talk about it here.
(18:33):
But in terms of a program of record, and forgive me, I know this isn't the acquisition talk, so this is about to get really acquisition on you. "Haves" are people that are aligned to a direct program of record. If you're aligned to a direct program of record, that very specifically means that you have access to investment funds. Investment funds out of congressional appropriation is either RDT&E money or procurement money, but it's money that you have on a consistent basis because it comes out every year programmed for that program of record. There's a level of consistency there that cannot be met if you don't have a program of record that is backing your software delivery organization. And so, if you don't have a program of record backing your delivery organization, you're then working off of operations dollars. Operations dollars are really difficult to be working off of because not only is it just one-year money, but kind of all money is one-year money at this point, but the reason is because all operations every single year is reprioritized, and when you're working off of operations dollars, you're competing at the unit and wing level with all other operations. So if they need to buy more fuel to be able to fly more flight hours, or they need to be able to buy more equipment, or more training, or more ammo, it's probably the software delivery organization that's going to take a bit of a lower priority to equipment, ammo, training, and fuel, especially times of heightened conflict.
(19:57):
So this describes the importance of the program of record. If I ask people to guess what software delivery organizations they know exist within the "haves" and the "have-nots," I'm pretty sure even if you knew nothing about acquisitions, you knew nothing about what a program of record was, you'd get really close in the "haves" bucket, Kessel Run, two programs of record associated to it, Kobayashi Maru, LevelUP, Platform One, Lauren talked about yesterday, finally made it into the congressional budget, three-year process to get that underway.
(20:29):
So credit to the foresight that it takes to get a program of record associated to your software delivery organization. All of those software factories that I just mentioned, debatable about how successful they are at whatever their delivery mission is, but undebatable, that they are very substantiated and they exist. They exist because of the consistency of their investment funds. The "have-nots:" what software factories do we think exist that are fighting every year for prioritization and operations dollars? I'm not trying to call anybody out or make anybody feel foolish about it, but there are software factories that don't have a program of record that are associated to them. BESPIN, I'll take the hit on that one myself. I hand that torch to Matt. BESPIN exists here. Wavelength exists here. Corsair Ranch exists here. Those software factories, you hear about them pretty often when they're doing great things, but man, it's a struggle to hear about them as a really solid and sustaining organization that has a roadmap trajectory into years in the future.
(21:29):
"Haves" and "have-nots" are directly tied to your access to investment funds through a program of record. Okay? Ah, I told you it's not the acquisition track, but you'd get hit with a ton of acquisition in a minute. This is ugly. Acquisition process is complicated. It doesn't have to be. We can fight about that in the other room with Jonathan, but it is. The bottom line is it is. And when you're working with your stakeholders, you have to understand that this is their job, and they want to be really good at their job. So they have a really complex job, and for them to be really good at it, they got to understand all of this crap just to get you a program of record. So the importance of having a program of record means that you have to really trust and work really closely with your budgetary stakeholders to be able to accomplish this.
(22:23):
If it was easy to reduce this down, like we all believe that it should absolutely be, we wouldn't be stuck in 30 years of acquisition reform, with still having this as our process. Now, we have evolved actually [DoDI] 5000.87 for software organizations. I'll give credit to that where it's due. This is the job. Is anybody familiar with what this is? A few people? Okay, cool. If you work in the Pentagon as a program element monitor, a bean counter, you care about this thing, and you look at it every month because every month Office of Secretary of Defense comes a' knocking. And when they try... And yesterday when Lauren said up in the panel that like, "sometimes in August money falls from the sky, and sometimes that's our plan for how we're going to be able to afford our year," this is what they're talking about. If you're not meeting your OSD goals for the amount of money that you spend by a certain date in the calendar year, they'll just take away all the excess money because you're not meeting the amount of money that you've spent.
(23:16):
Where in here does it ask what you've achieved or what outcomes you've actually produced for anybody? Nowhere, like expletive, nowhere. All it says is how much money have you spent? And if you haven't spent enough money, you're doing a really bad job. What? That's backwards, isn't it? Shouldn't I be incentivized to be efficient with the resource expenditure? No, it's not that way at all. And you just have to understand that this is the job that your stakeholders are up against when they're in the building. Here's another example. This is fresh off the books, fiscal year 2023. We're still in calendar year 2023, but what closed fiscal year 2023, Air Force Material Command. I'm not knocking them as a command. They do their job and they do it well, this proves it. This shows how well they do their job. On this closeout, you can see that they had a record year: $9.7 billion in small business awards.
(24:06):
That sounds pretty impressive. $17.8 billion in working capital fund, expended, money spent. To do what? Nowhere on this chart does it say to do what. And again, I'm not knocking people in Air Force Material Command. They're doing their job. They're clearly doing it really well, but this is entirely outputs driven. Entirely outputs driven. So you just have to understand that that's what your stakeholders are coming from. This is a hard lesson learned over and over and over again. Your stakeholders are a primary user. They're absolutely a primary user. So whether your delivery org is aligned more closely to the acquisition because you report up through Air Force Material Command or aligned more closely to your wing operations, you must recognize that your investors are people in the Pentagon who have to do a really good job at balancing those spreadsheets. Otherwise, they're going to be seen as a failure within their specific job.
(24:59):
As a stakeholder, you need to empower your stakeholder to be really good at their job. You have to understand their job. Back to the premise that Bryon talked about on Day 1 and the definition of DevOps. So to be successful at Mission Subordination, even though you're acquisition aligned, you have to work really closely and manage with your stakeholders on a daily basis. This gets back to the transparency with the user community. This means bringing your stakeholders into the fold on the process. So I know this sounds awful, but when you go visit your users, you need to be able to bring some of your stakeholders with you. That's a little bit weird. I want to introduce you to a balanced team. Here's a PM. Here's a UX designer. Here are our software engineers. Oh, by the way, here's our guy from the Pentagon who balances the spreadsheet month in and month out to make sure that we don't get money stolen from us.
(25:46):
Yeah, that's going to be a little weird when you bring them out to the flight line or you're bringing them into the SOF community, but it will pay dividends as long as you're upfront with the user community to explain to them that we are acquisition aligned, we have to serve this, but the more they understand about what we're doing, the better we can make them at doing their job. Because for them to be really good at their job, they're trying to save money every single day, which means they're trying to figure out how to do what capability you are delivering. They're trying to figure out how to do that faster and cheaper, which probably means without you if you're not actually making them aware of the process that you're following and the successful mission effectiveness that you're going to be delivering against. So how do we accomplish that?
(26:25):
Use the bureaucracy to your advantage. I alluded to 5000.87 earlier, that's a fairly new DODI. It's only a couple years old. Most of them are decades old. For software delivery, I'm sure most people, if you work in software delivery organizations, are familiar that this is the DOD Instruction that you're following. What's important about it is it stipulates that you must have a requirement sponsor. Be a demanding customer of that DODI, force your lead commands to do their doctrinal job. Which means if they're going to hound you about your expenditure rates like we saw in the previous sheet, and you have to report through your stakeholder community to be good at that, you've got to hold them accountable for having a really active requirement sponsor as well. Take it a step further. Push them to have an operational mission sponsor too, so that you have a true SES or General Officer signed into your statutory documentation that says, this person is responsible for my proximity to mission outcomes.
(27:23):
It's not just that they hand me something and tell me to deliver something that works right. They're responsible for making sure I have access to the operational environment so I know that it works right. Use the bureaucracy to your advantage. You can do that. So sorry, I didn't keep up with the build on the slide, but you can also do this when you have those users in your environment by demonstrating for them what the process is so that they can see that you are delivering against the exact requirements that they've set forward for your program. If they don't believe you're delivering against those requirements, and they believe, sometimes people will believe that innovation is just tinkering. And so if they paint you in that box and they think you're just doing UCD, you're just making things look really pretty for the end user, but we need to deliver against a hard capability requirement, bring them.
(28:08):
Bring them to show that you are delivering against the hard capability requirement, and it's okay to do so in a way where the software looks a lot better too, by the way. It just doesn't have to look like an awful database system just to prove that it's truly a government system. So with all that said, we didn't get to any definitive answer, right? I am sorry. I know that's super dissatisfying. I don't know if the software delivery organization works better in an operational wing or if it works better with acquisition alignment. What I know is you need both. You need to be able to respect both of those relationships, and you need to be able to foster and build against both of those relationships regardless of exactly where your software delivery organization fits.
(28:47):
If there's anything I can do to be any helpful to any of you that are on this journey, please reach out to me. You can collaborate with me in any of these spaces. If you're interested in what I said about serving in Reserve capacity, the GigEagle link is here as well if you're looking for gigs that are posted about doing great reserve work in the tech sector. I appreciate everyone packing into this room. I know it's hot. I know I'm a little over on time. So thank you for your attention.
