Pumping the Digital Transformation Bunny at the US Air Force, with Bryon Kroger

Episode 108 · 54:06 · SRT · archive.org · all Tanzu Talk

Yesterday and today here in Amsterdam, there's been a rare occurrence, and that is the sun. I was sitting here at my desk and my wife said, oh, look, the sun's out. And I was a little confused about what she was talking about. And I looked up and sure enough, there it was, the sun. And I can kind of see it now. It's still obscured by clouds, but I have a feeling it's going to be there. It might not be cloud covered. So Richard and guest, if you have any tips, can you give me some tips on avoiding being depressed about not seeing the sun? Do I need lamps? What do I do? Yeah, I mean, sheesh, I live in Seattle now, so I feel for you. It's actually been a really nice winter here, though. We've actually had the sun out a few days, like this week. It's like 40 and cold, but bright and sunny. So yeah, the one thing they do up here, I don't know if they do in Amsterdam, is they give all the kids here a midwinter break, which what the heck is that? But it's a week off in February to go get some sun, so you actually get some vitamin D. So I don't know if they're, do they try to kick you out of Amsterdam to get some sun? Yeah, there is like this break between, in February, it's like the pre-spring break. I don't know what you would call that, midwinter break. How about yourself, guest? Do you have any tips for coping with the sun or without the sun? Yeah, actually, don't judge me, but I moved from Tampa, Florida, to Boston, which is quite a change. So I actually started going to tanning beds, not because I'm vain and I want to look good in a bathing suit, but it actually helps. So like twice a week during the wintertime, I'll go to tanning beds. That's interesting. And then it has that intended side effect, I guess, of looking good. Just, you know, unintentional. Just in case. For the famous Boston swimsuit scene, when you're hanging out on the docks? I don't even know what you would do. All right. Well, you want to give yourself more of an introduction, guest?

Yeah, Captain Brian Kroger, I'm an active duty Air Force officer, started out in intelligence, did that for about seven years. And then I was tired of my software not working for me. I applied for a career change, became an acquisitions officer and started working on software projects. Now, what's acquisitions officer mean? Yeah, so we approach our building software the same way that we do building ships, planes and tanks, which is going out and acquiring them through massive muscle movements that involve the acts of Congress to get a budget. So that entire process is called the defense acquisition system. And it's pretty, pretty extensive. And they train officers for their whole careers to be able to navigate that system. I see. So it's like the whole panoply of like buying software. And I assume also buying people who would make software for you, buying contractors. Well, not, you don't buy the contractors, but dealing with all that from, I'm guessing, figuring out what you want, how to specify it, figuring out who the people you would talk with, evaluating what they have to offer, and then procurement as well, like paying for it. Yes. All right. Well, we'll, we'll have to, we'll have to come back to that, give you some time to figure out what docs you would go to in Boston for your new, but first there's a little bit of news. So I think, I don't think we've talked until, and not until, talk since the beginning of December and correct me if I'm wrong, but I think we had a Pivotal Cloud Foundry release 2.4 in the meantime, right? We did. We stopped the press. Yeah, it was a fifth release in 12 months. That was good to see that come out. Big highlights just mainly on app deployment, things like no downtime app deployment and simplified stack updates and updating Ubuntu and all these kind of fun things as well. And then, you know, the usual catalog of features that show up in that post about, you know, individual

things that pop up. But there's a lot of, how are you updating the platform? How are you updating apps? How are you staying secure? And how are you not impacting applications when you make things like network changes? So all those things are part of PCF 2.4. That's right. And as usual, Jared and friends have a comprehensive Roundup blog post on it. We'll put a link to it. It's very exciting. No doubt. Now, also, I, there's a couple of other like broad industry things and then some little things here and there. I think, uh, there's, there's been some like licensing changes that, uh, open source software companies have done to, uh, I don't know, cope with a public cloud world more. And, uh, there's been a couple of interesting posts about like how that's, I don't know. I don't, I don't know if people are being judge mill or not, or if it's just the peanut gallery that's forcing that perspective, but there's, you know, discussion of that. And I think our very own, uh, Andrew Clay Schaefer, or it looks like Drew Schaefer as he might, you know, he's always trying to do some of that, uh, culture jamming, I think is what the kids are calling it nowadays. Uh, but he has a nice post that, uh, in, in his succinct way kind of summarizes of like, uh, you know, these aren't the droids you're looking for that there's, there's more important things to worry about. And then community doesn't matter if it's open or whatever, there's just a community of use around things. And there's plenty of other, uh, there's some other good, uh, roundups that we'll link to about, uh, I mean, I guess essentially like the big scary thing for, for the community, whatever that may be is, uh, so our public cloud providers, namely Amazon going to come in and, um, I forget the like economic cultural term for this, but like basically coast off other people's work and, and then it's, yeah, I'm deplete the commercial, uh, viability of the companies doing these things. Right. The term I see that I, for some reason I like is strip mining. Strip mining. Yes. Yeah. So the cloud strip mining open source by simply taking those products, selling them as a service, making a lot of money on them and putting nothing back into the project.

Yes. Does that more or less destroy the viability of that thing in any other fashion is the question for things like Redis and Kafka and MongoDB. The other things that have popped up is, you know, has that changed the kind of dynamics of these things when someone can offer that massive scale as a service? How can that other company that maybe spends all their time making it for everyone else actually monetize it? So, I mean, that's the interesting debate is it has that change and, and Schaefer's posts call that well, that, you know, open source is not a business model. Like that's, it's a way you might do part of the software you're selling, but by itself, there is no open source sort of business model. But what does it mean when these companies that are changing their license to, you know, specifically discourage cloud providers from selling their stuff? So in the case of Mongo and Redis and, and Kafka, so at our confluence. So it's, but yeah, it's interesting to see this, this sort of bubbling up tension. And that's what kind of bubbled up recently, even with Amazon's new database, which is Mongo and, but doesn't run any Mongo software. So it really just tries to fake it. And so at Microsoft does it too, but it's just, it's like, it's trying to suck in those workloads. Get you off an existing Mongo, even though it doesn't run Mongo itself. So kind of what does that do to projects like that? We're just in this weird zone right now, which is, I guess, good for consumers because they have all these great options, but weird for people who might be building the software that they can't make any money off of. Yeah, definitely true. Well, uh, also there's, I'll put a link to it. There's a, I was on a new stack or I'm sorry, the new stack podcast with, uh, with, with Rachel from red monk and, uh, and a couple of the new stack people, uh, kind of going over like, I guess, coincidentally or, or relative, like, uh, kind of how open source was last year. And, uh, and, and, and I, I, in a very, in a very disciplined way, even made myself say some nice things about IBM and red hat. So you can, you can, uh, go put my thing to the fire for that. Anyways, uh, not, not you, the theoretic one, I guess, but are there any other items that, uh, caught your fancy since last time?

Uh, no, my fancy is pretty easily caught, but the, uh, one I threw on here was, uh, you know, Hey, GitHub offering private repos for everybody is interesting. That was always something they held back to people who were paying customers. So just, you know, if you were worried that being acquired by Microsoft was going to turn them maybe more evil or something, it seems like they're giving more stuff away, which that can't be, that's gotta be good news. There's no nefarious thing that's going to happen a year now. Everyone should just plow all their repos. I think, I think, I think, I think as a belated prediction, I think 2019 is, is the year that we stopped, uh, what's, what's the word that we stopped saying, uh, Oh, it's not your dad's Microsoft. Everyone's just like, yep, they're fine. They're fine. No more dollar sign for the S it's all you can't do anymore. There's, there's no more footnote required. If you're some sort of like a software industry hipster. And if you say like, you actually like Microsoft, you don't have to have a footnote that says, I know that we all used to hate them. Like, it's just, it's totally cool. No, no more disclaiming needed. Well, uh, so guest, I remember, I think, uh, you've, you've given a couple of talks in the, uh, I don't know, okay. It's SpringOne platform and I think CF summit and, and, uh, all sorts of people, how, how, uh, the, you know, the team you've worked on the, the broader area of stuff, uh, people has basically, uh, I don't know, you've got a set of software in the, uh, the air operations command. And like you were saying, uh, you want a better software. Maybe that was in a different domain, but I think over the course of the last couple of years, if I remember y'all have, uh, changed over, I would say dramatically the, the way that software is created, uh, in the U S air force. But I could, I could, as I've done many times, I could summarize your story a lot, but why don't you, why don't you give us, uh, your kind of like take on a, on a brief version of what that, what that story of, uh, pardon the word use of the phrase transformation is. It's a good term. Uh, so, I mean, our story gets told a lot in the news, um, as kind of the serendipitous

moment where there's like Eric Schmidt out in Qatar of all places, he sees the tanker whiteboard says, this is the craziest thing I've ever seen. Uh, and then all of a sudden people start building really great software. Um, there's a ton of contributions that had to come together to make this happen. Kessel Run isn't building apps as much as reforming the, uh, the air force acquisition system that I mentioned before. Yeah. So I'll tell them my, my side of that story, uh, which is very different. It starts way before that tanker planner project. I was actually a targeteer, uh, and I spent most of my time doing collateral damage estimation, uh, in theater. So Afghanistan, Iraq, Syria, uh, and I had, uh, it's just crazy. If you could see how these things are done where we're tracking fast moving targets going, you know, 60 miles an hour down a road. Um, and I've got out an Excel spreadsheet to calculate ground speed of a moving target and project where it's going to be during the weapon time of flight and then predict at that point of impact, uh, making sure that there's no collateral damage. Um, and it was just wild to me to see that and incredibly frustrating. Everything that I just mentioned about that entire process is really simple math, uh, that can be performed using just the metadata coming in off of the sensors from those aircraft. Hey, I wanted to jump in here and tell you about our, uh, SpringOne tour series of little conferences we have going on this year. Now I'm not going to rattle off all the dates that we have. If you really want to check out the cities and the dates, go to SpringOne tour.io, but at the end of this month in January, we'll be in Charlotte, then there's St. Louis, Washington, DC, Columbus, London, Amsterdam, Johannesburg, Cape town, Istanbul, Paris, San Francisco, and Atlanta. And that those run all the way through June. Now these are two day, uh, many conferences, people like myself come to give a talk. And then there's a tremendous amount as the name would imply about software development with spring, various programming things, doing things like reactive and architecture, but also you'll learn about, uh, Kubernetes and pivotal cloud foundry and all those other

things. So if you're interested in that, uh, go over to SpringOne tour.io and, uh, check out the dates and the cities, sign up for it. And hopefully I'll see you there. So let's go back to Brian where he, uh, picks up talking about the first day he, uh, moved over to being, uh, working in acquisitions and how he started sorting through improving software at the air force. Um, I showed up at, uh, Hanscom air force base as a new acquisitions officer. And the first thing I did was called DIUX, uh, who hadn't quite started that, uh, tanker planner project. And so we started talking about all the things we would need to do, uh, not just to, to build apps a different way. Uh, but how can we get after the budgeting process, uh, which is literally an act of Congress, uh, to get a budget, uh, all the way down to, you know, you're, you finish your application. How do you get it out in the field today? If you anywhere else in the air force, you build an application, you have to go through developmental testing. It's going to take you about a year operational testing, take you another year, uh, getting your authority to operate from a cybersecurity perspective, probably another year. Some of it can be done in parallel, but you're looking at a two to three year lead time after you're done with development. Yeah. Uh, and then, and then most of our fielding is manual because we don't have any infrastructure cloud-based infrastructure, right? So we're shipping CDs and fielding teams out to every site in remote locations. So fielding an AOC weapon system, for instance, uh, the one you mentioned that takes a three years to get through all the sites. Yeah. And I remember if I remember the timelines that, uh, y'all have gone over, I mean, you're, you're talking from, from, um, what would you call it? The lead time to, to use the, the, like lean, lean, uh, lean terms for like the full cycle from idea to, uh, someone using it is like, I don't know, like, isn't it like eight or 10 years or something like to thinking about something and then, you know, specifying it, coding it, testing it. And then of course you have to get budget for it as well. And then, uh, verifying and then fielding it, right. Like can be, uh, pretty long. Yes. That's for the air operations center specifically, but yes.

So, and so Kessel Run then, uh, you know, we addressed all of those things. And, uh, that's the often untold part of the story is it's not fun stuff to talk about is, uh, uh, you know, how do you go about the budgeting process, the contracting process? Uh, there's a lot of air force bureaucracy all the way up to congressional bureaucracy tied in there. But I mean, at the end of the day, what we were able to do is pretty incredible. So, uh, we're up to 18 application teams. Now, um, we still can't ship on day one. That's one of my goals, uh, before my time is up here. Um, we have some initial hurdles we have to get through, but usually we can deploy an application, you know, whiteboard to deploy it into our operational environment, which is on a classified network, by the way, a secret network. Um, we can do that on average of 120 days. And then after that we can establish continuous delivery. So, uh, usually most teams are on a one week or a two week, uh, deployment frequency, uh, usually up to them. Um, but we have teams, you know, we'll go through, uh, you know, high period times where we're pushing two or three times a day. So, uh, quite a change. Yeah. That's it. That's a figure I didn't, if it didn't, I kind of was guessing at, but didn't know that like, cause you hear the sort of, um, what would you call it? There's a lot of, of dates with stories like yourself of how long it took us for that initial version. But, uh, it's always interesting to hear then that sets you up for like, you're saying a one or two, uh, uh, cadence after that. So, so that like, like to go back just a little bit, I'm always, I always try to be a little sympathetic to, uh, the current, uh, enemy of a story. Yeah. I guess cause I've seen lots of star Wars movies. So you figure at one point they were fine. Uh, but like, why is the process like that? Like at some point that was probably helpful to have like such a long cycle, I guess. And sometimes maybe it is still helpful, but like, how did, how did that come about that it took so long? Yeah, I, I think the, you know, these things grow over time, but the intent is right. And in fact, I wouldn't advocate doing what we do in most of the systems that are being

built in the air force right now, the way they're being built. Um, it just goes back to your classic waterfall. If you're going to deliver everything at once, uh, that's your only option and everything has to work together. You have to do a lot of your risk mitigation before you deploy, uh, where, you know, today you can do a lot of your risk mitigation and products, right? If my things don't work together, when I deploy them together, I make a change and redeploy and it takes me a few seconds. It was a low risk activity. But if you look at the system I'm talking about, if it takes three years for a fielding team to go around the globe with discs, uh, if you get it wrong, uh, you have to start over at minimum, just a three-year fielding cycle for everybody to go refield up things. So, uh, I think it's actually appropriate. I'm glad you said that. I think one of the keys, at least me personally, uh, successfully being able to champion this across the air force is, is not making them the enemy and really empathizing. And I often say if I were in your shoes, I would do this the exact same way, especially the testers. When I go talk to the test community, I'm like, you're absolutely right. You should test the way that you do. And given the track record that these offices have of delivering software to you, that doesn't work. Um, I think what you do is absolutely appropriate, but let's talk about how we can do it differently now, uh, given the, the changing environment. Yeah. I mean, you hit up on two things or, or so far there's, there's two things, uh, sort of on the whiteboard of, of topics that I think of like, what there's two things. The first thing that most, whenever I talk to, whether it's military or government people, I think, uh, I don't know, their procurement cycle is, is like their number one issue, right? Uh, basically just like, how do I deal with existing contracts that I have and, uh, just speed things, speed is the wrong word, but how do I make it easier to do things more frequently or to, to work on a different cadence than a big upfront design and things like that. And then, and then associated with that is, I think, I think in government work, they're the people who most frequently ask me, when is waterfall good?

Like, like, like very, very few other types of industries ask me that question, but like, it comes up pretty much every time in government work. And I think, you know, I don't know, I don't know if the forest service has the same concerns, for example, but there's definitely like, there definitely are more areas. It feels like in government and military areas where it's kind of okay to take the time to make sure stuff works really well versus, I don't know, insurance, they're probably cool. Well, I, I actually, I'm a huge proponent that, that everybody should do this. I think my caveat is, uh, you have to go full agile. Um, but really like you, you, you can't, you can't do some, you know, the classic water scrum fall, um, that ends really poorly in DOD. Um, because the, you know, I don't think it ever works well, to be honest, but, um, in DOD, that fuzzy front end and that last mile are drastically larger than they are in even the commercial space. Right. I mean, I just mentioned our fuzzy front end getting congressional budgets that can be like a five-year process. Two years is the minimum. Um, and it really depends on what you're working on. And then three years to five years on that last mile. Uh, so you build up a lot of risk in that time. And so everything that you see in the DOD is an effort to buy down the risk from those two things. So I would say if you're not going to tackle those two things, which is most program offices aren't, uh, you know, they're not addressing the requirements and design process and they're not addressing their fielding process, then yeah, keep, keep doing what you're doing. Um, don't try to change the small little part. You actually introduce more risk. Um, and, uh, anyways, yeah, I think that everybody could benefit from going this direction, but they have to tackle it across the board and not just focus on the software development use. Yeah. Well, I asked you, you, uh, when you were first kicking off, you were, you're talking about DIUX and Kessel Run and some of these groups.

And I wanted to quick back you up and ask you like, Kip, tell me what Kessel Run is because you kind of named your change, right? You didn't just say like, there's going to be some few rogue people in the group who just kind of built things better, requisition stuff better. There was a group set up for this, right? Yeah. Kind of, uh, a group of, uh, volunteers, rebels maybe. Uh, so we had a defense innovation unit experimental, a group at Silicon Valley, uh, defense outpost there that tries to develop relationships in the community. Um, and they let out some unique contracts that help, uh, you know, non-traditional, uh, organizations such as Pivotal, uh, be able to work with the government more easily because going through that contracting process is such a bear. So there was Colonel Enrique Odee was there, um, innovative guy spoke at SpringOne, actually there's a really good talk out there on YouTube. Um, and he was working on this jigsaw project. Uh, you had myself and the AOC program office, uh, so it was, uh, Colonel Sanders. I love saying his name, uh, makes me chuckle every time. Um, and then a few people from the Pentagon, actually the years, uh, the defense digital service is not a well-known group, um, but really great if you have like civic interest, uh, us digital service and the defense digital service are great places to go, uh, do a tour of duty anyways. So a group of us got together out in, uh, San Francisco and decided we were going to, or we were going to do things differently. Um, and yeah, we, we whiteboarded a name in classic fashion. We dot vote did it. Uh, we recently just framed this. So somebody still had it as an artifact and we put it up in our new office, uh, Kessel Run won the dot votes, but, um, it was a joke that we were going to smuggle this into the VOD. A lot of people think it's a parsecs reference, but it was more of a smuggling reference. Um, and yeah, so, uh, the, the project that we decided to take on was the air operations center, uh, which is where all missions all across the globe for the air force. Um, they are planned, uh, and tasked out of these air operation centers and the software

in them is, is terrible. So we took on the project of fixing this. Awesome. So do you think that branding makes a difference? I mean, we've seen a few pivotal customers and just industry people who kind of say, look, here's a change unit. Let's actually something around it. I mean, I have my agile AF shirt that I wear every other week. And, you know, people, you know, I, I think people have kind of captured, you know, kind of glom to just your, your vibe, your thing, your, Hey, there's, this group has a thing on your door. There's a logo when you show pictures of it. So do you think branding the change helps? Do you think that helps it get some traction and also help stick? Uh, absolutely. Uh, it was one of the, uh, early lessons. So we weren't getting traction. Um, there's always a revisionist history of the story where all of the now champions pretend like they are champions all along. Uh, but early on, we had almost nothing but naysayers to be honest. And then just a lot of people ignoring us were a blip on the radar in terms of the defense, you know, budget. Um, and so a few of us, uh, it was really at first it started as Adam Pertato and I, um, we just sat down and said, like, we got to get our own message out there. Like our own leadership wasn't even paying attention to us, actively ignoring us in some cases. And so we started our own branding campaign, reaching out to news agencies, which is something, uh, a lot of people in defense don't do or kind of frown on. Um, some people don't like that we do it, but, uh, yeah, we started a branding campaign. We actually went back and watched this old, uh, Steve jobs video. Um, one of the early ones when he starts remarketing Apple, uh, and so like, how can we make a branding campaign, um, that people believe in? Right. And kind of corny, but, uh, you know, Simon Sinek, start with why people don't buy what you do. They buy why you do it. There's a ton of people going around saying what they do. Uh, you know, everybody in the DOD is doing agile in some form, but we really started with this, Hey, we're going to revelation, revolutionize the way the air force builds and deliver software. Uh, and then even when we talk about our mission, right, we included something in there that

I think is very foreign to the military, but, uh, that we're building software that our airmen love. Uh, and so those two things, I think really started to change the narrative around what we were doing and just started to believe in why we were doing it, uh, and then started paying attention to what we do. Right. That's inspiring stuff. I'll ask you a quick follow-up because one thing I, uh, I observed you. What I was tweeting about a couple of weeks ago was some of the, uh, I don't know. I think you said it more artfully, but it's not just about sprinkling some pivotal. Like there's a lot of work to scale this stuff. Like, even though you all just got started and got rolling, there was, you know, maybe the 10,000 hours sort of Gladwell thing you had to kind of get better at software. So what's some of the, what's some of that work that sometimes people might think like, yeah, just buying a product or, you know, doing some trust falls in the parking lot. We all love each other enough. Why is it more than that? And like, maybe I'm being a little cheeky, but like, what's that work that maybe it's not the glory work, but it's what's necessary for your team. Do you feel like they're actually getting in the rhythm of doing things the right way? Yeah. Uh, well, I will say, um, and not just cause I'm on the phone with pivots, but, uh, the pivotal model does this really well at the team level. Uh, it's, it's, it's essentially forced deliberate practice, uh, for 40 hours a week, uh, for as long as your engagements are. And, you know, our, some of our engagements early on, because we didn't have our own lab to move into, got into like the eight month mark. So, you know, that, that's just work. We're all work that the teams are doing, but that happens organically. I think that, that tweet storm that you mentioned was kind of a shot across the bow of, uh, hey, leadership. Why aren't you doing this and following suit of your people? Um, I, I think that, uh, leadership is also a practice, but we don't usually treat it as such. Um, we talk about leadership experience a lot, but you don't really call leaders practitioners. Uh, and I think that's a shame. I, I, the one thing that you'll see with, uh, some of the early people, and we were like

very junior young people as well, um, with no backgrounds in any of this, but Adam, myself, uh, Torrey cuff, uh, we spent a lot of time with pivotal leadership. I would just go sit at labs. I wasn't on a team and I would shadow, uh, Hedy Stern, the associate director, uh, at pivotal labs Cambridge. Um, and I would identify a lot of weaknesses, uh, and then go set up systems of practice to, to help myself, uh, address those weaknesses. Um, I think that fundamentally, you know, if you're going to use pivotal and go to pivotal labs, your teams are going to get the deliberate practice they need. Um, I think the real work has to be done is coming in at a leadership level. Uh, and it's, uh, it's, it's something that I overlooked, I think early on too, like the small group of us, we did it implicitly. Um, but I don't think in one of my biggest regrets is not early on establishing a practice for leadership, uh, and growing other people into those roles. So I would say by and large, the thing people overlook the most is well, number one platform. I kind of made a comment about that at SpringOne. Um, you get distracted by shiny apps, you forget about the platform. We definitely did that. Uh, but we corrected that and, uh, and then the, the final thing that people overlook in their journeys, their leadership's transformation. So, so tell me, most, most people don't bring up the idea of like, uh, I, I didn't know anything about the topic, so I took the time to learn about it to put it one way. And, and like, like you, you use this phrase like, uh, systems of practice. And, um, I, I mean, I imagine that is not only learning what the topic is, but sort of coming up with, um, a process for getting better at it and continuing to like understand how to manage it and do it. But like, what was that, what, what did you sort of, uh, what's the word intentionally do to sort of like build up the capability of yourself and other people to be able to do

all this stuff and understand it? Uh, I mean, people are your, your mechanism to do that. Right. Uh, and feedback, and we talk a lot about feedback culture, but again, something that gets ignored a lot at the leadership level. So, um, as this was all going on, there were a lot of people who were spending their times going out to stakeholders and going to the Pentagon and doing those things. I spent all my time with the team, uh, and the teams gave me a lot of feedback, which quickly identifies a lot of your weaknesses. And then, as I mentioned, uh, you know, it's a humbling experience. I, I think, uh, for most people, if they sat in a room with some of these, you know, in my case, I was with pivotal. So associate directors, directors being in a room with people like the two of you, uh, you know, Edward, um, there's a lot of people, uh, James Watters where I'm just sitting in a room realizing, Oh my God, like, if I really want to do this, like if we want to build something like this, we need to build people like that. Uh, and so, yeah, identifying your weaknesses. I think, uh, deliberate practice is something that people don't understand that well. I think a lot of people hear the 10,000 hours and they, they, I think it's a Malcolm Gladwell reference. Um, but actually, uh, one of my favorite books is talent is overrated, uh, where they talk about, it's not just 10,000 hours of anything. Uh, it's, it's a certain number of hours. Maybe it's 10,000, maybe it's five of something called deliberate practice. And that's very different. Um, that's identifying things that you can't do, uh, setting stretch goals, uh, and practicing until you can make those hard things really easy. Um, that's very different. And, uh, yeah, so starts with feedback, uh, and then it's just a lot of hard work. It's not fun work at all. It's kind of like, you know, if you're in athletics drills. Yeah. Yeah. I just finished reading that, uh, a related book, uh, peak, I think, which is by a journalist and one of the academics of deliberate practice stuff. And yeah, is it, is it interesting? Like, uh, well, it's being, it's not just interesting.

It's a much more actionable and pragmatic idea of how to get good at something than sort of just like, I don't know, memorize a times table. Uh, but, uh, yeah, like, like you're saying, there's this idea of, uh, well, one, you need the basic skills and, but then two, you have to build up this, uh, what does it call it? Like a model that kind of represents what it is you're doing. And I think in software, uh, I don't know, you could pick something like lean product design and the model being like, we have a theory of how to do software. We want to validate the theory by having people use it. And then if it worked or not, we'll come up with a new way of solving that problem. I mean, that's a very high level model, but you know, it's almost like a system, if you will. And, and then, and then, and then the third thing, other than, you know, putting in your thousands of hours of practices, like actually having a teacher or a coach to similarly give you feedback about that part could be improved. And that part is better, but to kind of have a third party that's giving you some guidance on something instead of being like, you know, a castaway trying to improve on your own. Yeah. And, uh, this is something you guys might know. I'm, I'm always curious. Uh, one thing that as you're dealing with a lot of people that are going through transformations, um, and as you're going through the transformation, you're often the person that, uh, probably most, if you're leading one of these, you, you most need a coach, but at the same time, you don't have one. Um, yeah. And so, you know, like it's one thing to have mentors and coaches that are outside of your context. Uh, and I say context, I mean like very fine grained context, like pivotal has a lot of context over digital transformation, but no context over the DOD space, for instance. Um, is that's where it gets really hard is now you have to, you know, a mentor is only as good as the context you provide them. And we're all really biased about providing context over the decisions we made. Uh, we kind of like lead the witness that we made the right decision. Um, but I think that, uh, coming up with something around that, how to identify that, um, and it's

something that I think pivotal and all of their clients would benefit really gratefully, great from, it's, it's like a nut that I haven't cracked. Uh, I think it's really poses a problem for transforming leadership themselves. Yeah. Yeah. We, we need some sort of, uh, they used to call them special interest groups or SIGs of just like, uh, industry people. And there's always, uh, there's always, I guess to be all fancy, you always, you, you, you, it's, you could call it the in problem when there's just the first person or, you know, problem they, they, you know, there has to be a bit of bootstrapping, but then once you get a, you, once you get a one additional person, you have two and so forth and so on. But yeah, it, uh, it w it would be nice to have more solid sort of like industry practice, like, uh, people talking with each other and to, to share that knowledge. But yeah, you're right. Like, like, uh, I, I see this a lot happen across industries of, of people I talk with and they, the best you can do if there's not peers who understand your context, so to speak is try really hard to find analogous things to sort of learn from and build. And I think, I think the broad topic of like compliance and just, and security, like those are kind of good, right? Like the, um, like often the, the stories, uh, that, that y'all tell that had to do with compliance, like ETO things and stuff like that are analogously and applicable to other people who have compliance and, you know, they're, they're different and they might have different words and things going on, but basically the model of what you do there, uh, namely, if you're just deploying one line of code, not certifying everything down to the dirt and figuring out how to get to that point, like is helpful over there as a kind of search for other people to help, help you out with. Yeah. You think, uh, I remember Rob Mays said that pair program. Kind of was the first real time we had empathy or this idea of empathy. Cause you'd actually understood the pair sitting next to you. You wonder if there, we should be doing a little more pairing at the leader level. Cause that should be bi-directional, right? You shouldn't be on your own, just trying to figure stuff out. You find a pair who may not even know your domain, but they know their domain.

And you're trying to do some cross knowledge share. But I don't know if we don't do that enough at a leadership level. We just expect that people quote unquote doing the work to pair, but are the leaders pairing as well with somebody maybe outside industry or somebody with less, maybe overall experience, but the experience they need to transfer. So I don't know. Do you ever see that? Do you see leadership doing that sort of coaching with people outside industry, Brian? Uh, not, uh, not so much. I actually, I say all the people that I've seen be successful in this have, um, so Adam Purtado, I mentioned him, he actually set us up with other pivotal clients, but, uh, all state and HDSC. Uh, and we went out and visited them. Uh, and then like myself personally, I've reached out to Mark Garavito at HDSC, uh, here and there, uh, when I need advice or just like somebody to, we have this phrase, it's going to take some explaining, uh, pump your bunny. Uh, sure. I want that t-shirt next. Yeah. So, uh, I don't know if you guys have heard the story of this, but, uh, Josh Marcus, he's a defense innovation board, so that group that Eric Schmidt's a part of, um, he had this phrase from, uh, somebody at Darden, he went to Darden, uh, told the story of his kids going out to the beach and he said, government innovation is a lot like this experience I had at the beach with my kids where, you know, there's waves out there and they've got this big inflatable bunny, uh, and I pumped that thing up, you know, uh, blowing into it. I send them out onto the waves and, uh, pretty soon they come in and they're all sad and their bunnies deflated, uh, from all the waves. And I have to pump that bunny up again, like four or five times, uh, they come in and I got to keep pumping up their bunny. And he said, that's government innovation. It's like, you don't have somebody to pump your bunny. Uh, you're not going back out on the waves. So it's like a kind of lewd, uh, so it's fun and it's funny and it's something that we say a lot. So anyways, yes, uh, Mark Cardido is somebody that helped, uh, I think pump our bunnies. He pumps your bunny. No, that's, that's good. What is the, uh, so I mean, you figured out a lot of these, uh, the hard things as you've,

you've kind of gotten started. What's the, uh, I mean, what's the next hard thing you're trying to figure out, especially within Kessel Run? Like that you feel like, okay, we've, we've solved some, some areas. We're going to keep getting better. We've got to keep funding up, but where's, where are those, what's that next thing that the team has set their eye on? Yeah. Uh, you know, how do you do a PIV net upgrade over dial-up speed? Um, no, we, we actually had that. We had a 56k switch that we found, um, that was throttling all of our traffic. Uh, I would say that's, that's one area is, uh, the networking challenges that we have are, are fairly interesting and unique, um, because we don't operate on commercial internet. Um, we have a lot of really legacy, uh, infrastructure, uh, around, uh, our internet connection speeds and how they're managed at the base level and they're managed differently at every base. So, um, that's one big thing that Colonel Odie has taken on in his champion. Uh, and then the other one is, uh, I mentioned it earlier, shipping on day one. So I want to be able to ship our hello world off all the way to our operating environment. Um, it's challenging for two reasons. Of course, there's a lot of people that I have to convince that that's even valuable to accept the risk. Um, and then, uh, the other aspect of it is, is the cybersecurity. You know, we have that continuous authority to operate that's become so famous. Um, but it's only continuous after, uh, a lot of the initial upfront work is met. And so I, again, that's that process I mentioned seeking about 120 days right now. Uh, so I have to reduce that by 120 X, but I feel pretty good about, about being able to do that. So, so then like you were saying, there's, uh, like, like in this, in, in the domain of, of Kessel stuff, you've got like 18 teams or so. And as you, uh, I don't know, as you, as you sort of daydream about like one day having, let's say a hundred or 200 teams, like how, I don't know, how are you starting to think about how you would like scale the change up to that amount?

Like, is there a ceiling you'll reach or like, what kind of challenges do you think you would have and how would you get around it? Yeah. I, uh, I, I try not to think about those things. Honestly, I, I'm a firm follower of the guidance, uh, do things that don't scale. Um, if you're thinking about scale and you start doing things that will scale, it means that you're over engineering or over, uh, complexifying your, your current situation. And so I'm always focused on doing what works now and, uh, just focused on being able to learn and react quickly. So thing that I have, uh, big thing that I've had to focus on personally, and one of my weaknesses as well as developing this in my leadership team is, uh, being able to learn fast and react, uh, quickly to our learnings. And if you focus on those two things, the rest just follows. I mean, people, people solve problems, um, invest in your people and they'll figure out how to solve your problems when they arise. Um, we've proven that over and over again, you know, every time there's this seemingly insurmountable challenge, uh, we're able to get over it. There are, I say all that, but of course I can't stop myself like anybody else from, uh, you know, thinking about those things. And, uh, we've learned a lot of lessons about, you know, how flat is too flat when it comes to munition structures and how do you scale, um, I say leadership, but, you know, we, we still want it to be flat. So we're really talking about servants, uh, people that serve the product teams, uh, to get them the things they need to unblock things. Uh, so we've invested a lot in practices around kind of similar to the, uh, pivotal, uh, client liaison role, but more for focus internally, uh, is how do we serve our product teams as we scale? And I think when we crack that nut, the, the ability to scale becomes boundless. It's just a matter of scaling your people first. And to your point, like the word scale is always, well, by now it's extremely loaded term

or whatever loaded means, but, but it's, uh, it's almost a, uh, a shipwreck before you can finish pronouncing it in the context of changing how organizations work. And I don't know, maybe a more helpful word is sort of like spread or something like that. Right. Like to have more people benefit from these things, but it is, it is like, I think I go going back a little bit, but to the point of chain, I don't know, fixing up people or, or, or figuring out how you can make people like the, uh, the source of changing things for the better. Like when you're, one thing that strikes me is as you were going over, you were saying one of the things you need to do is focus people on why you're doing something. And I would add kind of like the full outcome of doing something versus like, uh, the siloed approach of like my little part of the process. I do really well and I don't really care what happens before or after that. And so that, that's like, that's like one of these almost mystical things of like lean and agile software is that if we have people focus end to end, instead of doing their little part, the software will improve. Uh, but it's, it's, uh, it's more of like an intuitive argument you make on that before people actually try it. So it's a difficult thing to get across to people that we don't want people just, uh, focused on like their database part or their operations part or making sure their tests run correctly. And instead, as, as I guess, sort of like a leader or a manager, we should try to put together teams and the, the, the weekly workflow so that they actually do get a chance to focus on that bigger end to end thing. Or as you say, the why of doing things, which I don't know, I'm trying to construct a possible truism to, to apply to like scaling up change like this. But it seems like there's an evolving, like maybe there's like five principles like that, that aren't just a rephrasing of the agile software development principles from way back when, but there's a few little things like that, that I see people struggling with in

large organizations that are sort of, um, what would you call them? They're like structural issues that have to change. Otherwise it's the old, uh, you know, square peg in a round hole situation that you get. And someone's got to bore out that, uh, that, that round hole. I guess you wouldn't bore it. You cut it into a square, but anyways, that's, that's my soliloquy for the podcast. Um, yeah. Yeah. Alignment is, uh, is always a challenge. We struggled with that early on. I think the, the, the danger and where most people get stuck is, uh, leadership starts to view that as a people or a team problem, uh, instead of a leadership failure. So, um, the people that, I think there's a natural evolution that when you start with one or two product teams, uh, they develop a product team identity. There's, there's nothing else at that point. Um, their goal, uh, in fact, you know, in your, uh, book on strategy, you know, it's pick that quick win, that thing that's going to get you, uh, the visibility you need jigsaw was that for us that naturally produces, and we shouldn't fight it. Uh, it naturally produces kind of a hero mentality in that team and a very individualistic, uh, like team identity. Um, and there comes an inflection point and I don't know when that is, uh, that you need all the things to start working together to produce those, those higher level of portfolio or, you know, line of business outcomes that you're looking for. And that's fundamentally a leadership problem if that's not happening. Uh, and you have to evolve the teams out of that. The only way you can do that is by getting them to believe in the higher level outcomes. Uh, and, you know, getting people to believe is, again, it's, it's a leadership, it's a leadership function. It's not your people that are the problem. And so, uh, yeah, we, we struggled with that. Uh, I think we're just turning a corner with that. We're using OKR framework. It's one way to do it. A lot of people use different frameworks to produce alignment, but, um, yeah, this is definitely a challenge. But as long as you realize that it's you that needs to do the work there and it's not

your team, uh, I think it's a lot easier to focus in on the real issue. Um, that, that would be a good word to do the, uh, what does this actually mean treat mean treatment on the word alignment? Like that's, that's like a word in a, um, organizational context that is kind of vacuous and laughable now, but, but just, just like my original favorite word in this bucket, the word synergy, uh, like can be extremely meaningless, but if, if used properly, it's, it's extremely precise and, uh, tactical or whatever, but alignment, I'll, we'll sort that one out. Well, uh, but as, before we wrap up, I think, um, one of the, one of the things I, I've, I've seen you talk about a little bit and, and I'm, it seems not unique, but you're, you're the only group of people who's really kind of talked about this challenge in so much detail and in, and in a unique way is, is the staffing issues that you have just getting people who you could say who have the skills to do it, but even before that, who are good for learning the skills to do it, I don't know, just having staffing and retention. And, um, like what, what are the challenges you've had there and like, how are you making it work despite those challenges? Yeah. Uh, oh, government hiring is very difficult. Um, it's, even if I just threw away who the people are just getting butts in seats is, is hard. Um, I can't even hire the wrong people. Uh, it's, it's crazy. Just getting anybody in the door is really difficult. Uh, I have one person that I recently recruited is in, um, month six now, uh, of the process still hasn't been onboarded as a government civilian. So, and we've had, you know, crazy timelines like that across the board. Most people leave. These are the only people that I can get are the people that really, uh, this is what they want to do and they're willing to wait for it. They've got a current job and they're just, they'll wait for the process to play out.

So, um, some interesting things, you know, we're governed by, uh, OPM, uh, Office of Personnel Management and all of their laws and regulations. Uh, and then there's crazy regulations that come into play, like, you know, the not so aptly named paperwork reduction act, um, that increases a lot of paperwork that has to be done. Um, and you know, it's just a whole bunch of jumping through hoops. I think two things though, that I've learned is that initially we did focus on like, oh my gosh, we need to hire talent, whatever talent is. Uh, and instead I think we should have focused a lot more on hiring, uh, people that we can grow. And I think there's this myth that, you know, I, I really like the, uh, on the DevOps side of the house, there's this, always this sentiment of, uh, it's changing now cause you're getting a lot more of them, but it was DevOps isn't like a competency that really exists in the community. Um, stop hiring DevOps and start growing them. If we say DevOps is a noun. Um, but it's very similar, right? Is we're in a position in the DOD where, uh, I think we can afford to take the time to grow this organically rather than hiring it in. Then I also have come to realize that going back to that issue on context, uh, deliberate practice is usually in that a context. We use the example. A lot of times it's like a chess player can memorize all the chess pieces on a board. Uh, but if you threw checkers out, up there, you think like same board, um, you know, same number and they can't, they can't remember the positions, you know, in those memory tests. Uh, likewise, there's a lot of context that, uh, our people have that is actually, I think harder to build than some of the raw skills. Um, so my big thing is let's take the people we have, find the ones that have growth mindsets and can grow really quickly. And we found a lot of them. And in fact, I would say that, um, the air force civilian and the air force military and

the military in general, uh, tends to have people, uh, with those qualities. They're often, you think about it, they're often thrown into situations where every assignment that I had was something new. We move every three years. It's an entirely new context. And I have to go in and lead a group of 20, 30, 40 people doing something I've never done before. Um, and so we're maybe unique in that sense. And so, uh, I guess it started out with a negative, but I'm really hopeful looking forward that we've, we've learned a lot in our hiring practices. And I think in doing so, we've opened the door to a lot more real talent. Um, versus kind of the stagnant or fixed talent that we were looking for in the past. I mean, speaking of growth, you're, uh, you're experiencing a little growth yourself here. So, I mean, what's next for you, Brian? Yeah. So I just announced that I'm getting out of the military. So, uh, I mentioned moving every three years. It gets pretty hard on the family. I have a wife and three kids. Um, so this was kind of my last hurrah. Uh, so I'll be getting out in, uh, this summer and go on terminal leave in April, actually. So I have no idea what's next. Um, I've got like some interesting offers that have started to roll in, but there's a part of me that also wants to do my own thing. And then going back to what I said earlier, you know, uh, growth is hard when you don't have a coach and I feel like I still have a ton to learn. So there's a part of me that wants to go find a really good coach. Uh, I don't really want to find a company to work for. I want to find a mentor to work with, uh, and so struggling internal struggle right now, no decisions. Uh, I'm really focusing on my team. We have a hiring surge. So they use this opportunity. Kessel Run is hiring. We have a huge hiring fair on the 23rd and 24th. And instead of waiting six months, uh, the system has guaranteed us that we'll be able to hire people on the spot, get them in process, uh, and starting work, uh, on the 23rd and 24th during the hiring fair. So, um, deadline to submit resumes is the 19th, but I'm really focused in with my team on how

do we hire all of these people? We've got authority to hire 50 new people. And, and, uh, once we get them on board, how do we grow them? So that's the focus of my next month. And then I'll start thinking about myself and what's next. No, that's exciting. You have a lot to be proud of. I think Coté charges by the hour for coaching, which is pretty cool. So, uh, it's a lot of barbecue work that happens in there. It's a, it's a full, that's right. That's right. I, I, I have Richard to help me come up with my business plans. That's, that sounds perfect. Well, thanks for being on. We've, we've, uh, you know, we've palled around in Twitter for a while now. So it's nice to finally, uh, get together, record something. And, uh, I think, I think y'all, uh, y'all over there at the air force have, uh, you're, you're like unusual, not just for military, but for any organization, unusually open and sharing about the stuff you've been doing and learning. So I think that's been really helpful for everyone. So, uh, that's great. Thanks for that. Thank you. Thank you. Yeah, it's good. I always, I always, uh, you know, when I, when I, I haven't like talked for 10 or 15 minutes over my allotted time, I always, I always try to like end with some, uh, a slide from the agile manifesto. That's basically like, we're trying to improve software and share how to make it better. And you should do that as well. And so I'm always trying to get organizations to share more, which I think they're getting, you know, by like single percentage digits year over year better, but we could definitely do a lot more. Cause otherwise it's just this enterprise software blowhards who are just telling you why you should buy our stuff instead of, uh, actual financially unbiased best practices out there. Uh, and, and then as always, you know, thanks to our, our occasional special guest star, my dog, uh, who likes to show up sometimes. Uh, but with that, this has been another episode of, uh, Pivotal Conversations. Uh, oh, where should people follow you? Uh, if, if they're interested in following up and seeing more, you got a Twitter handle or anything like that? Yes. At BJ Kroger, K R O G E R. There's a Brian Kroger with an A out in Seattle. That's also a DevOps guy.

So don't follow him. I'm Brian with an O Brian. Yeah. And, uh, yeah, you can follow me on LinkedIn too. I'd be glad to make more connections on there. Yeah. There there's, I, I, there's a, there's a guy whose Twitter handle is like, and name is like Michael Coyote, which is very similar to my name. And then oddly enough, he's like, he's like an it DevOps person. So every now and then there's some, uh, some wires crossed there. I used to also get a lot of, uh, well, not a lot. I used to get confused with the CEO of SecureWorks, Michael Coyote, uh, who not me, but, uh, I mean, he's a friendly person, but he's a much different person than me. Anyhow, as always, this has been Pivotal Conversations. If you want to find this episode, the show notes for him, we posted, uh, every Thursday or so over at, uh, pivotal.io slash podcast. Uh, you can also find all the, uh, the old episodes. If you're really looking for something to do over at soundcloud.com slash Pivotal Conversations. And hopefully you've noticed by now that we've merged our two pivotal, uh, uh, podcast, pivotal insights and Pivotal Conversations. So Richard and I are, uh, every other week, uh, that's usually our plan. And then you'll hear, uh, from Dormain and Jeff, uh, on, on the other week there, but I think we'll have a, uh, nice, broader, more comprehensive collection of stuff for your ear holes and your enjoyment. And, uh, with that, we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.