why don't you two introduce yourself? I'm Jeremiah Sanders, a senior federal strategist at VMware. And I came out of the federal government, particularly the Department of Defense. I was a Navy nuclear power plant operator and then turned into an Air Force acquisitions officer. I did program management in the IT and software domain for close to 20 years, most of that time working in a way, a system development way that we're going to talk about here that wasn't very fruitful from a system development and outcome perspective. But the last opportunity, the last four years I served in the military, I went to Silicon Valley and learned a new way of work and started achieving outcomes with software in my organization called Kessel Run. And now I'm excited to be able to share those lessons learned with other government customers. My background is higher education and state government, most recently coming to VMware from the state of Wisconsin Department of Justice, where I was BIO. My role at VMware is staff solutions architect, meaning that I help our customers maximize the value that they get and ensure that they accomplish their business objectives with their investments with us. Given the background that you two have, right, it'll be fun to discuss what's happening in the kind of, let's call it the not federal government, right? Like the state, local education, like all of these areas here. Cause I think when I was talking, we were talking ahead of time, like, just like we see in all sorts of other industries and domains, like there's a really nice and for us nice, but good chance and a pretty big opportunity to really start to change how the business functions and change in the case of government, like how services are delivered to citizens, right? Like how you enact what your mission or however you want to call it by actually being able to do a lot more custom software that was possible. That's, I don't know about y'all, but that's how I interact with most of the rest of my life is through software and doing that through government is always nice. So now it can feel like sometimes like government stuff is on its own Island lagging behind or doing something differently, which is not always the case.
2:05I think Jeremiah, you mentioned a few things where that's not the case at all, right? That people in the Tanzu world are aware of, but anyhow, like, why don't we start with first of all, explaining like why there is a almost urgent interest in doing software better, like really like in looking at how services and government are like delivered differently, maybe even more agile than they currently are. Like what's driving that? I think what's driving that are the expectations of citizenry and the expectations of the elected officials that are trying to the needs of the citizenry. And if we look back at this really started with a whale before the pandemic, but the pandemic accelerated our expectations that we will get digital service. And, and so agencies, whether they like it or not have to modernize their services and they're dealing with a lot of, there are a lot of old applications that are supporting the business of government. And now we're faced with the challenge of modernizing it. And how do we do that cost effectively? How do we do that quickly meeting the expectations of the citizenry? There's a lot of technical that. And, and like, can you, can, so I, there's this blank space in my head, many of them, but this one that I'm thinking of is if I'm in a for-profit organization, the urgency to change is more or less easy to understand. It's often just money related. Right. And I think in government that's, there's certainly cost savings and being efficient, or as, as someone put it recently, responsibly spending citizens money, which is spot on. And I think one of the things not having really worked in government myself that I always want to appreciate more is what you're saying is just, we should do things better. Right. Because in, in a commercial organization, the desire to do things better
4:06is not always the best decision, right? Like it's not always the best, it's not always the best business decision. Whereas I feel like in government, it almost is always the best reason to do something right. Like it's a different, it's a different motivation than you have in the commercial sector. As long as that, that responsibility, or I do fundamentally believe people that are involved in government are there by and large for altruistic purposes to, to make lives better for the sake of the citizenry. And as Igor was saying, software has changed everybody's life in the last 30 years. You interact with the world through a digital modicum. And that experience is just as nascent for the government workers themselves. Their own personal lives are affected by better software. And they, they want to do that in terms of what they're doing at work as well. The cautionary aspect of what you were bringing up that perhaps in, in the private sector, doing the right thing, isn't always the right thing from a business perspective. That is true in public sector to the point where the public sector officials have, you know, obviated or outsourced the capacities to make decisions and know what to do through the implement of technology. Because at the end of the day, there, there is a business incentive to, to some degree to, to retain legacy capabilities and legacy means of work that are less efficient and more manual that, and providing that public service. So I think the impetus for change in how we digitize delivery of goods for goods or goods and services for the citizenry is one we have to be more efficient with the taxpayers resources. Of course, the cybersecurity aspects and threats environments that our legacy systems
6:09don't hold up to is another aspect. And the ability to leverage capabilities, the barrier to entry for for building and delivering modern software has been significantly reduced. And that opportunity is why the world around us is changing so drastically with software. And the opportunity is right and there for all of government to catch up. I couldn't agree more with what Jeremiah just said about the barrier to entry being reduced. And that in conjunction with the need and expectations of citizenry makes this an opportune time for government to reexamine fundamentally how it builds software. There's a great opportunity today. We have seen exposed the limitations of existing applications. There are many states that have had challenged with critical public assistance systems, unemployment insurance, renter's assistance, so on and so forth. All of those things that came under extreme pressure during the pandemic. And they are not the list of systems that need to improve the tip of the iceberg that we saw because of the pressure. And so I think it's important if we take what Jeremiah said about costs are now much lower barrier to entry and recognize that we were looking at the tip of the iceberg. The question is, how do we affect and how do we address as much of the ice as is feasible within state budgets? Now's the time to create a cost effective site. Yeah, it is the, there is a, there's an urgency like to essentially learn from, right? I think the iceberg, the metaphor is good because it's also, as you're saying that to go back further in the metaphor, it's the iceberg was way under the water and just a little bit of it peaks up and you realize there's something underneath there. And I think, I think finding that urgency is often the hardest thing
8:13to kicking off change. Because if there's no problem, we have an idiom for it. If it ain't broke, don't fix it. And so that's, you got to figure out the broke part. Now, but that said, y'all, y'all have alluded to it a little bit. What is, what's going on with the rest of that iceberg? What is the current state? Obviously to generalize that we're talking many hundreds of organizations and all sorts of states of no pun intended, all sorts of states of affairs, but what is like, how would you describe what the average, maybe even the best, what, what would I expect if I went into kind of a government organization? What, how are things run? What does it look like? I think in many ways, what's happening in government is mirroring what's happening in, it just takes a little longer for government to get there because there are certain processes that because of regulation don't allow government to, to react quickly. But what is consistent? What is consistent is the businesses, the agencies where people are serving their constituents. And as Jeremiah said, there, there's tremendous commitment to purpose and value and purpose that people get who are working in government. They are, I think, working mostly to improve their own business processes. And you're starting to see more and more business technologists, more and more, I'll call them, bureaus and programs that are making their own investments in improving their systems. And, and so you're seeing this, it's called business technology. And there's a higher and higher percentage of technology investment that's being made directly by agencies. They're hiring their own technologists and they are using innovative ways. They're using advanced tools in the cloud to directly solve their business issues. And they're getting a lot of value from that. But they're not getting anywhere near as much value as they could with, I'll call it a little bit of, I'll use the term
10:16machinery and the machinery is structure process that permit their work to be done with a high degree of autonomy and focused on their business. But with certainty around security and certainty regarding, I'll just say deployment monitoring operations, a lot of those things that they learn the hard way that they have to attend to when they build their own tools or build their own services. Yeah. What I hear you saying is that there is on, on the will side, the human side, there's actually a pretty big will to change. And even like you're saying hiring and things going into motion. And now what's left is to get the technology stack in order to, to essentially modernize the machinery. I, and by tech, by, as you're alluding to, I don't only mean like software and bits and hardware, but also the way that people work, the practices that they go through these motions, but the people process culture. Exactly. Exactly. And that, that machinery is now what one could predict that it's going to become the bottleneck. And it is the bottleneck, right? And it is somewhat useful to look at why do we have the quote unquote machinery that we do the people process and technology that has been applied in a way of system development that I spent an entire career in the air force learning to be beholden to a system development process. And that, and the faith in the process and that process would produce the outcomes we were wanting to achieve is because for close to a hundred years, a systems management process that Frederick Taylor came up with has been infused in, in every aspect of our lives. And through the industrial era and building of hardware centric items, it was a way of work that optimized factories for building pieces of hardware in a very, a deterministic and repeatable way.
12:21But software changed the world in that software and the cybersecurity environment and the needs of people interacting with software are defined by a reality of constant change. And so institutionally, then the way of work necessary to deal with constant change is bumping up into an institutionalized way of work that is stuck trying to live in a world of certainty. And where Igor was going, the desire and even some examples of islands of innovation, where people are starting to leverage technology and do things different, still run into both cultural policy process and organizational structure impediments at the large across the government landscape that are still beholden to this more institutionalized hardware centric system development process where that, that I'll just use what I'm familiar with out of Department of Defense, our system development process where you would define requirements, do a design, a build a system, test the system, accredit the system, field the system, on average was taking nine plus years in the Department of Defense. And in a world of technology, technology that some people say Moore's law is even outdated, that the change is even faster than every 18 months. How can you plan for what you need to have 10 years from? There is an opportunity to essentially work in a way that is ever evolving and ever malleable, but institutionally, we have to overcome people process and culture aspects that are baked into government writ large and the typical industry partners that think that they work think that it would be easy to watch what Jeremiah just said and say, cynically, how can
14:23government ever become this nimble? We have procurement requirements and our requirements in government aren't just suggestions. They're the law. And and so we have a lot of behaviors that are rooted in law. But at the same time, I think it's important that listeners realize that it is possible to be completely compliant with the law and set up structures that permit government to be more agile. And it just requires, I think it requires a vision and it requires determination to go address some of the structural impediments that are in a way that is consistent with with laws and regulations. So it doesn't have to be that way is what I'm trying to say. And and I think that's hard to appreciate until you see where it has been successful, where it's been successful in public. Yeah, no, I think you're absolutely right. Like once once you have read through or talk with someone about a couple of these experiences where there is whatever sector it's in, there's some policy or regulation, there's some rules, we'll put it that way. And and for years and years, you hear that we can't do something because of the rules. And then there's I don't know, entrepreneuring, overly curious person with too much spare time on their hands, probably. And they're like, Oh, could I read those rules? They often go through and read them. And they're like, Oh, these are great. Let me tell you how we could do this. And it takes that kind of I'm not one of those kind of people who would want to read through a phone book or rules and regulations. But it often when I've seen people go through that with a fresh set of eyes, they come out the other end with different things very commonly. Yeah, you're absolutely right, Michael. And our experience in the Air Force was very much that way. I mentioned systems development processes taking eight years and even for making changes to fielded systems, it was taking on average about three years
16:23just to get a new piece of software accredited was taking about 14 months. But at the end of the day, we dug deep into federal acquisition regulations, what are the laws around the procurement activities that I was responsible for the cybersecurity team dug into the policies for cybersecurity. And without any policy waivers, what we found was it was really how the policies or laws had been interpreted and put into practice. And when people say, Oh, it's the rules, it's really just the way that the rules had been interpreted and implemented. So when we were able to really fundamentally get to what actually is there in black and white, and how can we meet those equities, but perhaps in a more automated and repeatable way that looks and aligns with private sector best practice for implementing, you know, software in a more modern way, we did find ways to write software and have that software be accredited and in front of users on the other side of the world in the same day. And this is software that is being used to plan and execute air campaigns in Afghanistan and Iran and Syria. So we did all of that without changing laws or without changing policy. And it was really about having an open mindset and going at the heart of what do you think, what do these rules actually say, not how have they been implemented in the culture around them. Jeremiah, I think it's important to restate of what you just accomplished, because it's so dramatic that I'm not sure that it's believable until you say, no, we really accomplished this, you went from what was your cycle time before these processes were implemented to deliver new
18:26capability to what was your cycle time after? Just say that. Yeah, even sustainment updates, the cycle time was six years, but for building new systems, it was on the order of about 10 years. And now the cycle time is any one of a thousand software developers that we had that we, we started with less than 50 people, but after three years, we had a thousand software developers that could come to work and have the reasonable expectation that they could hear a need for change in software from a user on the other side of the world, that piece of software and have it operational on classified government networks on the other side of the world in the same day, often within the same. It's truly mind boggling. And how many IT operators were needed to support those thousand developers? We had about 90 IT operators that were responsible for a worldwide hybrid cloud implementation across five different networks in classification level. And that's another part of the journey. We, we referenced this a little bit ago in the discussion that the barrier to entry has been reduced by the advancements in technology that are there for the taking. And so by and large, this is not a technology problem. It is a people in process challenge. And as you overcome the people in process barriers, get all of the equities of whether it's the cyber security community, the test community, the infrastructure operations community, all invested, achieving better citizenry or mission or user outcomes. However, you want to look at that. When everybody's focus is there, the technology makes it so much easier, the technology available today to write software and have it delivered
20:29on any number of cloud-based infrastructures, on-premise infrastructures, and really obfuscating that it's a complexity away from the application developers so that they don't have to think about how many CPU cycles is my piece of software going to use. They just write the functional code and the automation built into the underlying tooling handles so much of the rest to the point that we had 90 people providing capabilities for software development and security and operations at worldwide scale for over 1,000 developers and tens of, over 10,000 users. Yeah, it was like you were saying. I've, I've, I followed these, the, especially the, the Air Force story over the years. And yeah, it is all often unbelievable, but obviously it occurs. And I think it's astonishing. And I think to, to pile the stack up that we have so far, I think, I think you two, first of all, y'all hit on something that I think is the, the impetus for it, right? Is that there actually are people who recognize that things should and could be better, right? There's this willingness to change and do things in a better way. And then two, I haven't thought about it in the way that y'all laid it out exactly, but when it comes, the next barrier that you often have is policy and regulations and rules and the way we do things. And in, in the discussion that y'all are having around that, it's almost like the problem is that people are always stymied by the interpretation of rules, not really the rules themselves. Now, obviously there will sometimes be rules, metaphorically speaking are physically limiting, but more, more often than not, it's just the interpretation that people have of the rules. So that's the next barrier to get through. And then as you were alluding to Jeremiah, it'd be interesting to hear how this happens in other government organizations. The people like to do the rhetorical trick of dismissing technology because it's easy. It actually is vital to introduce once you've eliminated those bottlenecks
22:33that you can, you do have some of the things that you were alluding to. And also in the machinery, the practices that people follow with it, that actually make it possible to have those ratios of 90 to a thousand developers and deploy things in a day instead of 10 years, or a day instead of six months. That may be so as well. And like, I think it would be interesting to hear from the perspectives y'all have what the, what that new machinery is and how it's changing the way that people can work once they've gone through these bottlenecks. Yeah. I like the way you just described it as a new way of work because that's absolutely what it was coming from a typical government system development program office. We had zero software developers, no software designers, the practice and understanding of how to apply entrepreneurial management frameworks into what had been our, our Tayloristic systems development process for decades. We didn't know that either to your point of how do you scale from not having any of these competencies, not understanding the practices, not being able to buy technology, but frankly, not being able to know how to use it to achieve the outcomes that we wanted to see for our users or the citizenry. That is a journey that there are some repeatable patterns that I saw and we deployed in the public sector, but it had come out of private sector. Everything that we were doing was a replication of what had worked in private sector. And so some of the, you know, things you always hear about agile, start small and scale fast. That's how we implement it. We started very small with achievable outcomes and it was the achievement of outcomes gave us the momentum, I would say the kind of built-in momentum that energized our internal workforce that started to attract a talent pool that we had been unable to access. And it wasn't
24:35that we were replacing everybody that we had always had in our organization, but we were using an external set of talent to upskill our internal staff as well. And evolving this way of work was brought about by a relationship with enablers in building a digital workforce. So for us, that was going to South Bend Valley, specifically Pivotal Labs, now part of VMware as the Tanzu Labs, and inculcating the right practices and know-how competencies into our organization and scaling it deliberately, along with imbuing a culture that was so focused on the mission outcome or the business outcome or the citizenry outcome. That piece and then deliberately scaling that too, so that it didn't get lost as we grew the organization. So I say start small and leverage the been there, done that on the job training that can come from digital workforce enable through a partner like a Tanzu Labs is a great way to start that large scale transformation journey. As I think about mapping the experience Jeremiah has with the Air Force to most state governments, I see you've got a challenge of the scale and structure of state and you need to start small, but the small team needs to be cross-functional. And the cross-functional team in most state governments would span organizations to really let it scale. Because one of the challenges, if we think about an individual agency as a business, and within each of the agencies you have different bureaus and those bureaus are serving space-specific programs to citizenry. Also within state government, we tend to have the central IT infrastructure team. And so there's this structural friction, a structural inhibitor to
26:43creating a small but cross-functional team that spans everything from business to applications development to infrastructure management. It doesn't need to be big, but those people are in different places in state government. So I see the organizational change management challenge as finding that cross-functional kernel, cross-agencies, and with appropriate sponsorship in two agencies at a minimum together creating the experiment from which you can then demonstrate success and scale. So I think that's how I see the organizational change management. The technology exists, but it's not about buying and deploying and consuming it. It's about seeding the culture and what are the unique challenges in state government to getting it seeded. You can't just seed it in one place because of the current division of responsibilities and accountabilities, in my opinion, for most states. You know, y'all, especially in what you were just saying, but both of y'all hit on something I'm always curious about, not always, like I'm walking around the block curious about this, but that comes up every now and then. And I think, which is, it's like this in the private sector as well, right? And I think, as I'm sure y'all experience, the more large organizations you talk with, the more you realize how much the same all of them are, despite them thinking that they're special or whatever. They have similar challenges for sure. Exactly. There you go. Everyone faces similar challenges, but you know what you're outlining, like even within state government and each level of government is there's, there are, there are so many opportunities to have an independent IT department to have for every single agency and and to have not maybe even more than one, instead of having one kind of monolithic IT department,
28:43you might think of in a mid-sized private sector company that kind of controls everything. And so I wonder a lot of the advantages in doing a cloud native approach to things is that in my view, like if you're installing, whether you're standing up Kubernetes or something like the Tanzu application service is that instead of having 40 different ways of doing it, you now have one or three, right? There's a lot of centralization going on that where you get a lot of efficiencies. And is that, how does that pan out in these huge, like, whether it's state governments or agencies where like there are multiple IT departments often self-sufficient rather than coordinating with each other? I was going to say, I think the way it's really panning out is it's not just multiple IT departments, Michael, multiple product teams. So we think of moving to digital products, right? So we now have these product teams and their product teams in, in a reasonably sized, reasonable sized agency and government, you're going to have different bureaus with different services, each with their own product teams and each with their own sets of tools and processes. And so this is what has allowed them to be faster than they used. And if we think of, you know, the old fireside and two guys in the woods and they see a bear and the other one, one stops to put on his shoes, his running shoes is that you can't outrun that bear. Why are you doing that? All I have to do is outrun you. What they're really doing right now in those agencies and in those DevOps teams is they're out running the old way. They're faster than the old way, but they're not as fast as same day cycle times. They're not as efficient as a thousand developers to 90 operators. And to get to that level of efficiency and output, there needs to be coordination across the
30:48teams. They can't be their own product team silos. And so this is what has to be seeded is at small scale, a cross-commerce, a cross-functional group. And then once teams deliver the kinds of results that Jeremiah was describing at Kessel Run in the Air Force, then that will perpetuate itself. It will draw in and help, frankly, scale just because of the business success of the model. Yeah, our journey started with four sysadmins or platform operations team of four people because we were only sufficing two software application teams at the time. And to your point about looking at the organizational construct that there's institutional friction naturally, that has a parallel to or is consequential. The traditional system development process where most of what happens, you have the business or application owner who is trying to build an application to meet the needs of a citizenry, but is relying on somebody else owning the system development tools that they have to use and somebody else owning the data center that the application is going to run in and another organization that has to accredit the software and these siloed activities that are often serialized stage gates for building a piece of software and getting it to the ultimate consumer. That system development process, that deterministic and serialistic process, you're absolutely right that you have to start small with a cross-functional team to do it. But if you're a visual person thinking about all of these functional equities and silos in that
32:53serialistic process, you have to pick all of those silos up and turn them on their side and be able to start with a need of software and delivery of that software continuously and repeatedly on a cadence of every few hours. So how do you do that institutionally? It is all about organizational design and change. And of course, then all of the cultural aspects that come into driving the human behaviors to be more accountable and more accountable and responsible for achieving that outcome of starting with a need of software and delivering them. It is not in the mindset of sysadmin sitting in the data center owner organization to think about their life being responsible for the delivery of that user outcome. So how do you make them want to be involved in continually delivering and be motivated by the fact that they are supporting that? Or that the cybersecurity team, who is often a barrier to progressing of software through this process, how do you get them to be an owner of and shift left, frankly, on the way that they're working so that it's inculcated in continuous and they feel like an owner of understanding a need for software and helping the broader set of equity of functions in this process deliver that software securely. It's a different mindset and that is a significant part of the journey as well. So what y'all are just saying is making me think of another, I don't know what to call it, string of words. Let me run past y'all, which is, I think you definitely, you went over a pretty high level concept that I think in the software world, we're almost at the tail end of not realizing is a big
34:56concept anymore, which is the, I am a person who has responsibility for the end-to-end life of this software or put another way that like, someone's going to be using the software and they need to do something. So I should be interested in that. Like now I might be serving a little part of that chain, but I always know that it's like, it results in someone doing something. I'm not just obsessed with, oh, I turned in the, the report. And so now my work is done. You're trying to get over local optimization. And it seems like with the way for decades, if not since the dawning of time, maybe even back to an abacus when it comes to computers, like a limitation has been that like, it's very fiddly and it's expensive and prone to breaking. And when something goes wrong, it can be very hard to troubleshoot. It's not necessarily reliable or easy to recover from. So in a situation like that, the best thing to do is to be slow and steady and have a specialization in what you do. And, and the issue is, of course, we always want people to be outcome focused and paying attention to end. But like, until recently, we haven't really had to use the word of the episode here, the machinery in place that would actually empower someone to do something about that, that you bring up like the sysadmin who like in a traditional setting, they don't really have that many tools. And so they want to make sure the tools that you're giving them, they can do their, what that they can, they only want to be accountable for what they can accomplish with their tools. Like they don't want expectations outside of what they're empowered to do. And it seems like a weird abstract concept, but it seems like that's the key thing with technology nowadays is what you can do with a good cloud native stack and changing the practices is you can actually empower people to have that end to end perspective and do a lot more than just like that narrow slice that they had. But until you convince people that they actually will be able to accomplish the task you've given
36:57them, of course, they don't want to change what they're doing. Right. That, that legacy way of work and that, you know, the beholdenness to process is because of what you referred to it. And I call it a risk aversion. I'm going to deliberately take my time and make sure that the outcome is. And the aha moment that happens is when people realize that all of the layers of institutional checking of the checker and being deliberate and slow in the process that has inculcated for decades. Now, all of that is not eliminating risk. It is actually driving and adding to risk. And there's been some studies that looked at this. I'll reference in the Department of Defense, 94% of federal IT projects over $10 million end up over cost, over schedule or deliver broken and 40% get canceled outright. They never deliver. I had a $430 million mistake that didn't deliver. I was one of those in that project management process that just doesn't deliver. And even the software that gets delivered, then some studies have shown this, that to your point about somebody actually has to use the software to do something. Studies have shown that over two-thirds of software that's delivered in this deliberate legacy way actually has no utility to the end users. So think about the number of lines of code and the amount of money that we're spending to retain this legacy software and the cybersecurity vulnerabilities that it perpetuates. And two-thirds of it is actually useless. That's another big aspect. So realizing that the way of work is actually driving risk, not eliminating it is an aha moment that'll sometimes get people to start to think about, okay, I actually need to consider changing the way of work and utilizing technology in a new way.
38:58So y'all have hit on like the, when people ask me about bootstrapping or kicking off change, right? I think the, the starting small and seeding thing, I don't know. It seems like I don't, I normally I would say only, but I'm trying to be more responsible than hyperbolic all the time. But it seems like primarily the best way to get started. And it has another benefit that, that I don't know if we touched on directly, which is like, it allows you to learn what will work in your organization rather than just doing everything at once. As you like incrementally do one thing and another thing and another thing, like you're, you're in that uncertainty environment y'all are talking about, but you're learning what, how to fit these general practices to your own, which is great as well. So we've got that pattern, if you will, to apply. But okay. So if the, if you have people management and executive types who do want to change over how the organization is, is doing tech, like what you're going to go to the meeting on Monday, hopefully not have worked on this over the weekend and instead of relaxed, but like, how do you like kick this off? What's, how do you put together the strategy to actually put these changes in place? What do you see people doing in government to do that? So I've seen a pattern repeated now over 200 times in public sector over the last four years across all of the branches of the military and several federal agencies as well. That harken back to conversation a little bit ago. It starts small with cross-functional team that is empowered. That's another big aspect that there needs to be some senior leader champion in the organization that empowers an island of innovation to apply best of breed practices, technologies, and building up of competency and culture in an organization that is given the autonomy to apply these practices and achieve outcomes very quickly. But the key that I've seen in organizations
40:59that try to do this on their own by reading books or going to a website and learning about how to be agile often struggle. And some are maybe marginally successful, but by and large, when you look at those organizations that have started small and actually scaled and have been successful now in public sector for some number of years in continuously delivering modern software to their user groups, are those that paired with a partner that can help them digitally enable their workforce and leverage technology in a new way. And so that would be the primary pattern that I've seen repeated and working. I would just add one thing to what Jeremiah said, and because I think he said it extremely well, and that is that cross-functional team. It's important to get the structure because that's what you're going to scale. Start with an expectation of, and the leader should, the sponsor should in terms of what does this scale to be if we're successful, so that you have a, I don't want to say complete, but you've really ensured that you have all of the functions, the necessary functions represented. You've got all the, you have the tools and the capabilities you need, essentially. I'm actually more thinking about the people in the organization because that's really where you move from what Jeremiah was calling these sequential gates to, okay, we're now going to work and have this integrated process that addresses the process requirements, all of the process requirements, because that's what permits. Acceleration of, or reduction in cycle types. Yeah, those cross-functional equities extend beyond the people who are physically touching and delivering the technology. In government in particular, those equities extend to cost estimating,
42:59and the people and the people who handle budget and the contracting officers and the test organizations and the users or the organization responsible for defining requirements for systems. All of those additional equities are part of this environment too. And it can't be understated that often the way that they are working is going to change as well by looking at the need to be adaptive and responsive to change and the needs of the citizenry and continually evolving technology. Yes, of course, the people that are doing system administration and software development are going to change the way they're working. But all of those other equities involved in how funding gets allocated and put on contract. There's a new way of working for them as well. Yeah, it's interesting. We also work at a large company. We're always talking about changing and improving and working on our culture. And when you're naming off all the other parts of the system, and we experience this ourselves and other people do, but it highlights the importance of having everyone involved in that change. Understanding it's easy for us in IT and in tech to obsess about the software or the tech part and think that we've solved the problem when we can deploy the software to production in a day and make sure that it's secure. But to your point, right? You have to think of the entire rest of the organization is there also to service someone actually doing something, right? Like the whole organization is about citizen or a person like clicking on a button and doing a transaction, right? Like it all comes down to whatever you're trying to fulfill there. So there's an equal need to go back to them and make sure that they're on board with those things. I have all sorts of other abstract rambly questions I wanted to get around. In particular, I'm not going to ask them,
45:00but at some point we talked a lot about shifting from deterministic certainty to an area of uncertainty. And that's always a fun area to sort out how you make people comfortable with that. Comfortable with the notion of what we're preparing for is to not really know what we're doing or to know what it is we should be doing. And instead of exploring that rather than just locking down exactly what it is, which I think in every different domain is something interesting to explore, but maybe we'll figure that out some other time. If people are interested in digging into this a little bit more, do you have anything y'all would want to point them to? Have you started a Facebook group to discuss this stuff, some threads in Twitter? Where are y'all finding people talking about this stuff and talking about it yourselves? Our VMware public sector pages and the Tanzu public page have examples of success stories of implementation in government, certainly reaching out on LinkedIn. And then there's a great community of thought on LinkedIn around public sector transformation. And I'm pretty active on there, sharing the availability of these success stories and how to think different and come up with new ideas. I would just say contact VMware and we'll be happy to talk to you about how we can help your organization and listen to your specific challenges and goals and help you get there as consulting. And to use the word one more time, I think what's great is we have all the machinery, not just the technology, but the practices as well, which- The people and process and culture. And we will focus on that. Exactly. All right. Great. I really appreciate y'all talking so long about this. It was fascinating. It was good stuff. And this has been Tanzu Talk. If you want to get the show notes for this episode, you can go to tanzutalk.com and find the episode here. There's archives, videos, all sorts of other exciting, thrilling things there as well. And with that, we'll see everyone next time. Bye-bye.