1 00:00:00,000 --> 00:00:04,000 why don't you two introduce yourself? I'm Jeremiah Sanders, a senior federal 2 00:00:04,000 --> 00:00:09,500 strategist at VMware. And I came out of the federal government, particularly the Department 3 00:00:09,500 --> 00:00:14,720 of Defense. I was a Navy nuclear power plant operator and then turned into an Air Force 4 00:00:14,720 --> 00:00:19,740 acquisitions officer. I did program management in the IT and software domain for close to 5 00:00:19,740 --> 00:00:25,360 20 years, most of that time working in a way, a system development way that we're going to talk 6 00:00:25,360 --> 00:00:30,840 about here that wasn't very fruitful from a system development and outcome perspective. 7 00:00:31,100 --> 00:00:36,320 But the last opportunity, the last four years I served in the military, I went to Silicon 8 00:00:36,320 --> 00:00:41,860 Valley and learned a new way of work and started achieving outcomes with software in my organization 9 00:00:41,860 --> 00:00:46,700 called Kessel Run. And now I'm excited to be able to share those lessons learned with other 10 00:00:46,700 --> 00:00:52,480 government customers. My background is higher education and state government, most recently 11 00:00:52,480 --> 00:00:58,000 coming to VMware from the state of Wisconsin Department of Justice, where I was BIO. My 12 00:00:58,000 --> 00:01:03,000 role at VMware is staff solutions architect, meaning that I help our customers maximize the value 13 00:01:03,000 --> 00:01:07,460 that they get and ensure that they accomplish their business objectives with their investments 14 00:01:07,460 --> 00:01:07,840 with us. 15 00:01:08,040 --> 00:01:11,720 Given the background that you two have, right, it'll be fun to discuss what's happening in 16 00:01:11,720 --> 00:01:18,080 the kind of, let's call it the not federal government, right? Like the state, local education, like 17 00:01:18,080 --> 00:01:22,320 all of these areas here. Cause I think when I was talking, we were talking ahead of time, 18 00:01:22,320 --> 00:01:27,100 like, just like we see in all sorts of other industries and domains, like there's a really 19 00:01:27,100 --> 00:01:33,380 nice and for us nice, but good chance and a pretty big opportunity to really start to change how the 20 00:01:33,380 --> 00:01:39,300 business functions and change in the case of government, like how services are delivered to 21 00:01:39,300 --> 00:01:44,800 citizens, right? Like how you enact what your mission or however you want to call it by actually 22 00:01:44,800 --> 00:01:49,720 being able to do a lot more custom software that was possible. That's, I don't know about y'all, 23 00:01:49,780 --> 00:01:54,360 but that's how I interact with most of the rest of my life is through software and doing that 24 00:01:54,360 --> 00:01:59,400 through government is always nice. So now it can feel like sometimes like government stuff is 25 00:01:59,400 --> 00:02:05,320 on its own Island lagging behind or doing something differently, which is not always the case. 26 00:02:05,320 --> 00:02:09,300 I think Jeremiah, you mentioned a few things where that's not the case at all, right? That 27 00:02:09,300 --> 00:02:16,500 people in the Tanzu world are aware of, but anyhow, like, why don't we start with first of all, 28 00:02:16,560 --> 00:02:22,900 explaining like why there is a almost urgent interest in doing software better, like really 29 00:02:22,900 --> 00:02:30,300 like in looking at how services and government are like delivered differently, maybe even more agile 30 00:02:30,300 --> 00:02:32,500 than they currently are. Like what's driving that? 31 00:02:32,500 --> 00:02:40,040 I think what's driving that are the expectations of citizenry and the expectations of the elected 32 00:02:40,040 --> 00:02:45,740 officials that are trying to the needs of the citizenry. And if we look back at this really 33 00:02:45,740 --> 00:02:52,120 started with a whale before the pandemic, but the pandemic accelerated our expectations that we will 34 00:02:52,120 --> 00:03:00,780 get digital service. And, and so agencies, whether they like it or not have to modernize their services 35 00:03:00,780 --> 00:03:08,120 and they're dealing with a lot of, there are a lot of old applications that are supporting the 36 00:03:08,120 --> 00:03:14,120 business of government. And now we're faced with the challenge of modernizing it. And how do we do that 37 00:03:14,120 --> 00:03:21,980 cost effectively? How do we do that quickly meeting the expectations of the citizenry? There's a lot of 38 00:03:21,980 --> 00:03:22,580 technical that. 39 00:03:22,580 --> 00:03:29,180 And, and like, can you, can, so I, there's this blank space in my head, many of them, but this one that 40 00:03:29,180 --> 00:03:37,220 I'm thinking of is if I'm in a for-profit organization, the urgency to change is more or less easy to 41 00:03:37,220 --> 00:03:44,620 understand. It's often just money related. Right. And I think in government that's, there's certainly 42 00:03:44,620 --> 00:03:49,480 cost savings and being efficient, or as, as someone put it recently, responsibly spending 43 00:03:49,480 --> 00:03:54,820 citizens money, which is spot on. And I think one of the things not having really worked in government 44 00:03:54,820 --> 00:03:59,180 myself that I always want to appreciate more is what you're saying is just, we should do things 45 00:03:59,180 --> 00:04:06,140 better. Right. Because in, in a commercial organization, the desire to do things better 46 00:04:06,140 --> 00:04:11,600 is not always the best decision, right? Like it's not always the best, it's not always the best 47 00:04:11,600 --> 00:04:17,940 business decision. Whereas I feel like in government, it almost is always the best reason to do something 48 00:04:17,940 --> 00:04:22,660 right. Like it's a different, it's a different motivation than you have in the commercial sector. 49 00:04:23,140 --> 00:04:28,700 As long as that, that responsibility, or I do fundamentally believe people that are involved in 50 00:04:28,700 --> 00:04:35,660 government are there by and large for altruistic purposes to, to make lives better for the sake 51 00:04:35,660 --> 00:04:42,340 of the citizenry. And as Igor was saying, software has changed everybody's life in the last 30 years. 52 00:04:42,460 --> 00:04:50,700 You interact with the world through a digital modicum. And that experience is just as nascent for 53 00:04:50,700 --> 00:04:57,000 the government workers themselves. Their own personal lives are affected by better software. And they, 54 00:04:57,000 --> 00:05:03,120 they want to do that in terms of what they're doing at work as well. The cautionary aspect of what you 55 00:05:03,120 --> 00:05:09,440 were bringing up that perhaps in, in the private sector, doing the right thing, isn't always the 56 00:05:09,440 --> 00:05:17,960 right thing from a business perspective. That is true in public sector to the point where the public sector 57 00:05:17,960 --> 00:05:27,160 officials have, you know, obviated or outsourced the capacities to make decisions and know what to do 58 00:05:27,160 --> 00:05:35,240 through the implement of technology. Because at the end of the day, there, there is a business incentive 59 00:05:35,240 --> 00:05:45,640 to, to some degree to, to retain legacy capabilities and legacy means of work that are less efficient and 60 00:05:45,640 --> 00:05:53,240 more manual that, and providing that public service. So I think the impetus for change in how we digitize 61 00:05:53,240 --> 00:06:00,360 delivery of goods for goods or goods and services for the citizenry is one we have to be more efficient with 62 00:06:00,360 --> 00:06:09,400 the taxpayers resources. Of course, the cybersecurity aspects and threats environments that our legacy systems 63 00:06:09,400 --> 00:06:19,160 don't hold up to is another aspect. And the ability to leverage capabilities, the barrier to entry for 64 00:06:19,160 --> 00:06:27,720 for building and delivering modern software has been significantly reduced. And that opportunity 65 00:06:27,720 --> 00:06:36,280 is why the world around us is changing so drastically with software. And the opportunity is right and there 66 00:06:36,280 --> 00:06:43,880 for all of government to catch up. I couldn't agree more with what Jeremiah just said about the barrier to 67 00:06:43,880 --> 00:06:51,240 entry being reduced. And that in conjunction with the need and expectations of citizenry makes this an 68 00:06:51,240 --> 00:07:00,040 opportune time for government to reexamine fundamentally how it builds software. There's a great opportunity 69 00:07:00,040 --> 00:07:07,000 today. We have seen exposed the limitations of existing applications. There are many states that have had 70 00:07:07,800 --> 00:07:14,360 challenged with critical public assistance systems, unemployment insurance, renter's assistance, so on and so forth. 71 00:07:14,360 --> 00:07:20,280 All of those things that came under extreme pressure during the pandemic. And they 72 00:07:21,080 --> 00:07:27,400 are not the list of systems that need to improve the tip of the iceberg that we saw because of the pressure. 73 00:07:28,040 --> 00:07:36,680 And so I think it's important if we take what Jeremiah said about costs are now much lower barrier to entry 74 00:07:37,560 --> 00:07:42,680 and recognize that we were looking at the tip of the iceberg. The question is, how do we affect 75 00:07:42,680 --> 00:07:49,240 and how do we address as much of the ice as is feasible within state budgets? Now's the time 76 00:07:49,880 --> 00:07:52,040 to create a cost effective site. 77 00:07:52,040 --> 00:07:59,240 Yeah, it is the, there is a, there's an urgency like to essentially learn from, right? I think the 78 00:07:59,240 --> 00:08:04,120 iceberg, the metaphor is good because it's also, as you're saying that to go back further in the 79 00:08:04,120 --> 00:08:08,200 metaphor, it's the iceberg was way under the water and just a little bit of it peaks up and you realize 80 00:08:08,200 --> 00:08:13,000 there's something underneath there. And I think, I think finding that urgency is often the hardest thing 81 00:08:13,720 --> 00:08:17,960 to kicking off change. Because if there's no problem, we have an idiom for it. If it ain't broke, 82 00:08:17,960 --> 00:08:22,040 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 83 00:08:23,240 --> 00:08:28,680 alluded to it a little bit. What is, what's going on with the rest of that iceberg? What is the current 84 00:08:28,680 --> 00:08:33,240 state? Obviously to generalize that we're talking many hundreds of organizations and all sorts of 85 00:08:33,240 --> 00:08:39,480 states of no pun intended, all sorts of states of affairs, but what is like, how would you describe 86 00:08:40,200 --> 00:08:46,120 what the average, maybe even the best, what, what would I expect if I went into kind of a 87 00:08:46,120 --> 00:08:48,920 government organization? What, how are things run? What does it look like? 88 00:08:48,920 --> 00:08:54,280 I think in many ways, what's happening in government is mirroring what's happening in, 89 00:08:54,280 --> 00:08:59,160 it just takes a little longer for government to get there because there are certain processes 90 00:08:59,160 --> 00:09:05,400 that because of regulation don't allow government to, to react quickly. But what is consistent? What 91 00:09:05,400 --> 00:09:14,120 is consistent is the businesses, the agencies where people are serving their constituents. 92 00:09:14,680 --> 00:09:21,400 And as Jeremiah said, there, there's tremendous commitment to purpose and value and purpose that 93 00:09:21,400 --> 00:09:27,240 people get who are working in government. They are, I think, working mostly to improve their own 94 00:09:27,240 --> 00:09:32,280 business processes. And you're starting to see more and more business technologists, more and more, 95 00:09:32,280 --> 00:09:38,520 I'll call them, bureaus and programs that are making their own investments in improving their systems. 96 00:09:39,320 --> 00:09:46,120 And, and so you're seeing this, it's called business technology. And there's a higher and higher 97 00:09:46,120 --> 00:09:53,320 percentage of technology investment that's being made directly by agencies. They're hiring their own 98 00:09:53,320 --> 00:09:59,720 technologists and they are using innovative ways. They're using advanced tools in the cloud to 99 00:09:59,720 --> 00:10:08,360 directly solve their business issues. And they're getting a lot of value from that. But they're not 100 00:10:08,360 --> 00:10:16,920 getting anywhere near as much value as they could with, I'll call it a little bit of, I'll use the term 101 00:10:16,920 --> 00:10:24,840 machinery and the machinery is structure process that permit their work to be done with a high degree of 102 00:10:24,840 --> 00:10:32,520 autonomy and focused on their business. But with certainty around security and certainty 103 00:10:32,520 --> 00:10:38,920 regarding, I'll just say deployment monitoring operations, a lot of those things that they learn 104 00:10:38,920 --> 00:10:44,280 the hard way that they have to attend to when they build their own tools or build their own services. 105 00:10:44,280 --> 00:10:52,280 Yeah. What I hear you saying is that there is on, on the will side, the human side, there's actually 106 00:10:52,280 --> 00:10:57,320 a pretty big will to change. And even like you're saying hiring and things going into motion. 107 00:10:57,320 --> 00:11:05,400 And now what's left is to get the technology stack in order to, to essentially modernize the machinery. 108 00:11:05,400 --> 00:11:12,120 I, and by tech, by, as you're alluding to, I don't only mean like software and bits and hardware, 109 00:11:12,120 --> 00:11:17,240 but also the way that people work, the practices that they go through these motions, but 110 00:11:17,240 --> 00:11:22,280 the people process culture. Exactly. Exactly. And that, that machinery is now 111 00:11:22,280 --> 00:11:25,880 what one could predict that it's going to become the bottleneck. 112 00:11:25,880 --> 00:11:31,480 And it is the bottleneck, right? And it is somewhat useful to look at why do we have the 113 00:11:31,480 --> 00:11:39,560 quote unquote machinery that we do the people process and technology that has been applied in a way of 114 00:11:39,560 --> 00:11:45,960 system development that I spent an entire career in the air force learning to be beholden to a system 115 00:11:45,960 --> 00:11:52,760 development process. And that, and the faith in the process and that process would produce the 116 00:11:52,760 --> 00:12:01,080 outcomes we were wanting to achieve is because for close to a hundred years, a systems management 117 00:12:01,080 --> 00:12:07,880 process that Frederick Taylor came up with has been infused in, in every aspect of our lives. 118 00:12:07,880 --> 00:12:13,880 And through the industrial era and building of hardware centric items, it was a way of work that 119 00:12:13,880 --> 00:12:20,680 optimized factories for building pieces of hardware in a very, a deterministic and repeatable way. 120 00:12:21,480 --> 00:12:29,000 But software changed the world in that software and the cybersecurity environment and the needs of 121 00:12:29,000 --> 00:12:37,080 people interacting with software are defined by a reality of constant change. And so institutionally, 122 00:12:37,080 --> 00:12:47,080 then the way of work necessary to deal with constant change is bumping up into an institutionalized 123 00:12:47,080 --> 00:12:51,480 way of work that is stuck trying to live in a world of certainty. 124 00:12:52,280 --> 00:13:01,320 And where Igor was going, the desire and even some examples of islands of innovation, where people are 125 00:13:01,320 --> 00:13:09,080 starting to leverage technology and do things different, still run into both cultural policy 126 00:13:09,080 --> 00:13:17,720 process and organizational structure impediments at the large across the government landscape that are still 127 00:13:17,720 --> 00:13:27,080 beholden to this more institutionalized hardware centric system development process where that, that I'll just use 128 00:13:27,640 --> 00:13:33,480 what I'm familiar with out of Department of Defense, our system development process where you would define 129 00:13:33,480 --> 00:13:41,640 requirements, do a design, a build a system, test the system, accredit the system, field the system, on average was 130 00:13:41,640 --> 00:13:47,640 taking nine plus years in the Department of Defense. And in a world of technology, 131 00:13:47,640 --> 00:13:53,320 technology that some people say Moore's law is even outdated, that the change is even faster than 132 00:13:53,320 --> 00:14:00,200 every 18 months. How can you plan for what you need to have 10 years from? There is an opportunity to 133 00:14:00,200 --> 00:14:07,960 essentially work in a way that is ever evolving and ever malleable, but institutionally, we have to overcome 134 00:14:07,960 --> 00:14:17,560 people process and culture aspects that are baked into government writ large and the typical industry partners that 135 00:14:17,560 --> 00:14:23,240 think that they work think that it would be easy to watch what Jeremiah just said and say, cynically, how can 136 00:14:23,240 --> 00:14:25,240 government ever become 137 00:14:25,240 --> 00:14:27,240 this nimble? We have 138 00:14:27,240 --> 00:14:35,000 procurement requirements and our requirements in government aren't just suggestions. They're the law. 139 00:14:35,000 --> 00:14:42,120 And and so we have a lot of behaviors that are rooted in law. But at the same time, 140 00:14:42,120 --> 00:14:51,000 I think it's important that listeners realize that it is possible to be completely compliant with the law 141 00:14:51,000 --> 00:14:57,800 and set up structures that permit government to be more agile. And it just requires, I think it requires 142 00:14:57,800 --> 00:15:07,960 a vision and it requires determination to go address some of the structural impediments that are in a way 143 00:15:07,960 --> 00:15:12,680 that is consistent with with laws and regulations. So it doesn't have to be that way is what I'm 144 00:15:12,680 --> 00:15:20,680 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. 145 00:15:20,680 --> 00:15:24,120 Yeah, no, I think you're absolutely right. Like once once you have 146 00:15:25,800 --> 00:15:29,240 read through or talk with someone about a couple of these experiences where 147 00:15:29,640 --> 00:15:35,320 there is whatever sector it's in, there's some policy or regulation, there's some rules, we'll put 148 00:15:35,320 --> 00:15:39,720 it that way. And and for years and years, you hear that we can't do something because of the rules. 149 00:15:39,720 --> 00:15:44,520 And then there's I don't know, entrepreneuring, overly curious person with too much spare time on 150 00:15:44,520 --> 00:15:49,320 their hands, probably. And they're like, Oh, could I read those rules? They often go through and read 151 00:15:49,320 --> 00:15:54,760 them. And they're like, Oh, these are great. Let me tell you how we could do this. And it takes that 152 00:15:54,760 --> 00:15:58,520 kind of I'm not one of those kind of people who would want to read through a phone book or rules and 153 00:15:58,520 --> 00:16:03,880 regulations. But it often when I've seen people go through that with a fresh set of eyes, they come out 154 00:16:03,880 --> 00:16:10,040 the other end with different things very commonly. Yeah, you're absolutely right, Michael. And our 155 00:16:10,040 --> 00:16:16,040 experience in the Air Force was very much that way. I mentioned systems development processes taking 156 00:16:16,040 --> 00:16:23,480 eight years and even for making changes to fielded systems, it was taking on average about three years 157 00:16:23,480 --> 00:16:29,400 just to get a new piece of software accredited was taking about 14 months. But at the end of the day, 158 00:16:29,400 --> 00:16:36,360 we dug deep into federal acquisition regulations, what are the laws around the procurement activities 159 00:16:36,360 --> 00:16:46,680 that I was responsible for the cybersecurity team dug into the policies for cybersecurity. And without any 160 00:16:46,680 --> 00:16:55,720 policy waivers, what we found was it was really how the policies or laws had been interpreted and put 161 00:16:55,720 --> 00:17:01,720 into practice. And when people say, Oh, it's the rules, it's really just the way that the rules had 162 00:17:01,720 --> 00:17:09,320 been interpreted and implemented. So when we were able to really fundamentally get to what actually 163 00:17:09,320 --> 00:17:15,880 is there in black and white, and how can we meet those equities, but perhaps in a more automated and 164 00:17:15,880 --> 00:17:23,720 repeatable way that looks and aligns with private sector best practice for implementing, you know, 165 00:17:23,720 --> 00:17:33,560 software in a more modern way, we did find ways to write software and have that software be accredited 166 00:17:33,560 --> 00:17:39,320 and in front of users on the other side of the world in the same day. And this is software that is being 167 00:17:39,320 --> 00:17:48,200 used to plan and execute air campaigns in Afghanistan and Iran and Syria. So we did all of that without 168 00:17:48,200 --> 00:17:55,880 changing laws or without changing policy. And it was really about having an open mindset and going at the 169 00:17:55,880 --> 00:18:02,120 heart of what do you think, what do these rules actually say, not how have they been implemented in 170 00:18:02,120 --> 00:18:07,640 the culture around them. Jeremiah, I think it's important to restate of what you just accomplished, 171 00:18:07,640 --> 00:18:17,480 because it's so dramatic that I'm not sure that it's believable until you say, no, we really accomplished 172 00:18:17,480 --> 00:18:26,760 this, you went from what was your cycle time before these processes were implemented to deliver new 173 00:18:26,760 --> 00:18:34,920 capability to what was your cycle time after? Just say that. Yeah, even sustainment updates, 174 00:18:34,920 --> 00:18:41,320 the cycle time was six years, but for building new systems, it was on the order of about 10 years. 175 00:18:41,320 --> 00:18:48,120 And now the cycle time is any one of a thousand software developers that we had that we, we started 176 00:18:48,120 --> 00:18:53,240 with less than 50 people, but after three years, we had a thousand software developers that could come 177 00:18:53,240 --> 00:18:59,480 to work and have the reasonable expectation that they could hear a need for change in software from 178 00:18:59,480 --> 00:19:05,880 a user on the other side of the world, that piece of software and have it operational on classified 179 00:19:05,880 --> 00:19:10,840 government networks on the other side of the world in the same day, often within the same. 180 00:19:10,840 --> 00:19:18,600 It's truly mind boggling. And how many IT operators were needed to support those thousand developers? 181 00:19:18,600 --> 00:19:31,720 We had about 90 IT operators that were responsible for a worldwide hybrid cloud implementation across five 182 00:19:31,720 --> 00:19:37,480 different networks in classification level. And that's another part of the journey. We, we referenced this 183 00:19:37,480 --> 00:19:47,160 a little bit ago in the discussion that the barrier to entry has been reduced by the advancements in technology 184 00:19:47,160 --> 00:19:55,240 that are there for the taking. And so by and large, this is not a technology problem. It is a people in process challenge. 185 00:19:55,240 --> 00:20:04,600 And as you overcome the people in process barriers, get all of the equities of whether it's the cyber security 186 00:20:04,600 --> 00:20:13,000 community, the test community, the infrastructure operations community, all invested, achieving better 187 00:20:13,000 --> 00:20:19,560 citizenry or mission or user outcomes. However, you want to look at that. When everybody's focus is there, 188 00:20:19,640 --> 00:20:29,320 the technology makes it so much easier, the technology available today to write software and have it delivered 189 00:20:29,320 --> 00:20:38,840 on any number of cloud-based infrastructures, on-premise infrastructures, and really obfuscating that 190 00:20:39,400 --> 00:20:47,560 it's a complexity away from the application developers so that they don't have to think about how many CPU cycles 191 00:20:47,560 --> 00:20:55,880 is my piece of software going to use. They just write the functional code and the automation built into the 192 00:20:55,880 --> 00:21:03,880 underlying tooling handles so much of the rest to the point that we had 90 people providing capabilities 193 00:21:03,880 --> 00:21:12,040 for software development and security and operations at worldwide scale for over 1,000 developers and tens of, 194 00:21:12,040 --> 00:21:13,320 over 10,000 users. 195 00:21:13,320 --> 00:21:18,680 Yeah, it was like you were saying. I've, I've, I followed these, the, especially the, the Air Force 196 00:21:18,680 --> 00:21:24,280 story over the years. And yeah, it is all often unbelievable, but obviously it occurs. And I think 197 00:21:24,280 --> 00:21:31,160 it's astonishing. And I think to, to pile the stack up that we have so far, I think, I think you two, 198 00:21:31,160 --> 00:21:35,960 first of all, y'all hit on something that I think is the, the impetus for it, right? Is that there 199 00:21:35,960 --> 00:21:41,000 actually are people who recognize that things should and could be better, right? There's this 200 00:21:41,000 --> 00:21:45,560 willingness to change and do things in a better way. And then two, I haven't thought about it in 201 00:21:45,560 --> 00:21:51,640 the way that y'all laid it out exactly, but when it comes, the next barrier that you often have is 202 00:21:52,360 --> 00:21:57,640 policy and regulations and rules and the way we do things. And in, in the discussion that y'all are 203 00:21:57,640 --> 00:22:03,000 having around that, it's almost like the problem is that people are always stymied by the interpretation 204 00:22:03,000 --> 00:22:07,800 of rules, not really the rules themselves. Now, obviously there will sometimes be rules, 205 00:22:07,800 --> 00:22:13,400 metaphorically speaking are physically limiting, but more, more often than not, it's just the 206 00:22:13,400 --> 00:22:17,400 interpretation that people have of the rules. So that's the next barrier to get through. 207 00:22:17,400 --> 00:22:22,200 And then as you were alluding to Jeremiah, it'd be interesting to hear how this happens in other 208 00:22:22,200 --> 00:22:27,640 government organizations. The people like to do the rhetorical trick of dismissing technology 209 00:22:27,640 --> 00:22:33,320 because it's easy. It actually is vital to introduce once you've eliminated those bottlenecks 210 00:22:33,320 --> 00:22:38,120 that you can, you do have some of the things that you were alluding to. And also in the machinery, 211 00:22:38,120 --> 00:22:43,960 the practices that people follow with it, that actually make it possible to have those ratios of 212 00:22:43,960 --> 00:22:49,400 90 to a thousand developers and deploy things in a day instead of 10 years, or a day instead of six 213 00:22:49,400 --> 00:22:54,040 months. That may be so as well. And like, I think it would be interesting to hear from the perspectives 214 00:22:54,040 --> 00:23:02,040 y'all have what the, what that new machinery is and how it's changing the way that people can work 215 00:23:02,040 --> 00:23:06,600 once they've gone through these bottlenecks. Yeah. I like the way you just described it as a new way 216 00:23:06,600 --> 00:23:12,600 of work because that's absolutely what it was coming from a typical government system development program 217 00:23:12,600 --> 00:23:19,960 office. We had zero software developers, no software designers, the practice and understanding of how to 218 00:23:19,960 --> 00:23:26,760 apply entrepreneurial management frameworks into what had been our, our Tayloristic systems development 219 00:23:26,760 --> 00:23:33,880 process for decades. We didn't know that either to your point of how do you scale from not having any of 220 00:23:33,880 --> 00:23:41,560 these competencies, not understanding the practices, not being able to buy technology, but frankly, not 221 00:23:41,560 --> 00:23:47,160 being able to know how to use it to achieve the outcomes that we wanted to see for our users or the 222 00:23:47,160 --> 00:23:57,160 citizenry. That is a journey that there are some repeatable patterns that I saw and we deployed in the 223 00:23:57,160 --> 00:24:03,560 public sector, but it had come out of private sector. Everything that we were doing was a replication of 224 00:24:03,560 --> 00:24:09,640 what had worked in private sector. And so some of the, you know, things you always hear about agile, start 225 00:24:09,640 --> 00:24:18,680 small and scale fast. That's how we implement it. We started very small with achievable outcomes and it was 226 00:24:18,680 --> 00:24:27,880 the achievement of outcomes gave us the momentum, I would say the kind of built-in momentum that energized our 227 00:24:27,880 --> 00:24:35,720 internal workforce that started to attract a talent pool that we had been unable to access. And it wasn't 228 00:24:35,720 --> 00:24:42,280 that we were replacing everybody that we had always had in our organization, but we were using an external 229 00:24:42,280 --> 00:24:51,560 set of talent to upskill our internal staff as well. And evolving this way of work was brought about by a 230 00:24:51,560 --> 00:24:58,920 relationship with enablers in building a digital workforce. So for us, that was going to South Bend Valley, 231 00:24:58,920 --> 00:25:07,240 specifically Pivotal Labs, now part of VMware as the Tanzu Labs, and inculcating the right 232 00:25:08,200 --> 00:25:15,320 practices and know-how competencies into our organization and scaling it deliberately, along with 233 00:25:17,000 --> 00:25:25,400 imbuing a culture that was so focused on the mission outcome or the business outcome or the citizenry 234 00:25:25,400 --> 00:25:31,720 outcome. That piece and then deliberately scaling that too, so that it didn't get lost as we grew the 235 00:25:31,720 --> 00:25:41,400 organization. So I say start small and leverage the been there, done that on the job training that can 236 00:25:41,400 --> 00:25:48,520 come from digital workforce enable through a partner like a Tanzu Labs is a great way to start that large 237 00:25:48,520 --> 00:25:55,960 scale transformation journey. As I think about mapping the experience Jeremiah has with the Air Force to 238 00:25:56,840 --> 00:26:04,840 most state governments, I see you've got a challenge of the scale and structure of state and you need to 239 00:26:04,840 --> 00:26:13,640 start small, but the small team needs to be cross-functional. And the cross-functional team in most state 240 00:26:13,640 --> 00:26:20,280 governments would span organizations to really let it scale. Because one of the challenges, if we think 241 00:26:20,280 --> 00:26:26,520 about an individual agency as a business, and within each of the agencies you have different bureaus and 242 00:26:26,520 --> 00:26:33,400 those bureaus are serving space-specific programs to citizenry. Also within state government, we tend to 243 00:26:33,400 --> 00:26:43,000 have the central IT infrastructure team. And so there's this structural friction, a structural inhibitor to 244 00:26:43,000 --> 00:26:53,160 creating a small but cross-functional team that spans everything from business to applications development 245 00:26:53,160 --> 00:27:00,120 to infrastructure management. It doesn't need to be big, but those people are in different places in state 246 00:27:00,120 --> 00:27:10,040 government. So I see the organizational change management challenge as finding that cross-functional 247 00:27:10,040 --> 00:27:17,880 kernel, cross-agencies, and with appropriate sponsorship in two agencies at a minimum together 248 00:27:18,840 --> 00:27:26,120 creating the experiment from which you can then demonstrate success and scale. So I think that's how I 249 00:27:26,120 --> 00:27:33,320 see the organizational change management. The technology exists, but it's not about buying and deploying and 250 00:27:33,320 --> 00:27:39,640 consuming it. It's about seeding the culture and what are the unique challenges in state government to 251 00:27:39,640 --> 00:27:46,120 getting it seeded. You can't just seed it in one place because of the current division of responsibilities and 252 00:27:46,120 --> 00:27:48,600 accountabilities, in my opinion, for most states. 253 00:27:48,600 --> 00:27:53,320 You know, y'all, especially in what you were just saying, but both of y'all hit on something I'm 254 00:27:53,320 --> 00:27:58,040 always curious about, not always, like I'm walking around the block curious about this, but that comes 255 00:27:58,040 --> 00:28:02,200 up every now and then. And I think, which is, it's like this in the private sector as well, right? 256 00:28:02,200 --> 00:28:06,920 And I think, as I'm sure y'all experience, the more large organizations you talk with, the more you 257 00:28:06,920 --> 00:28:13,800 realize how much the same all of them are, despite them thinking that they're special or whatever. 258 00:28:13,800 --> 00:28:16,680 They have similar challenges for sure. 259 00:28:16,680 --> 00:28:22,840 Exactly. There you go. Everyone faces similar challenges, but you know what you're outlining, 260 00:28:22,840 --> 00:28:28,040 like even within state government and each level of government is there's, there are, 261 00:28:28,040 --> 00:28:36,040 there are so many opportunities to have an independent IT department to have for every single agency and 262 00:28:36,040 --> 00:28:43,160 and to have not maybe even more than one, instead of having one kind of monolithic IT department, 263 00:28:43,160 --> 00:28:49,160 you might think of in a mid-sized private sector company that kind of controls everything. 264 00:28:49,160 --> 00:28:55,640 And so I wonder a lot of the advantages in doing a cloud native approach to things is that in my 265 00:28:55,640 --> 00:28:59,720 view, like if you're installing, whether you're standing up Kubernetes or something like the Tanzu 266 00:28:59,720 --> 00:29:06,040 application service is that instead of having 40 different ways of doing it, you now have one or 267 00:29:06,040 --> 00:29:10,680 three, right? There's a lot of centralization going on that where you get a lot of efficiencies. 268 00:29:10,680 --> 00:29:17,560 And is that, how does that pan out in these huge, like, whether it's state governments or agencies 269 00:29:17,560 --> 00:29:24,040 where like there are multiple IT departments often self-sufficient rather than coordinating with each other? 270 00:29:24,040 --> 00:29:33,320 I was going to say, I think the way it's really panning out is it's not just multiple IT departments, 271 00:29:33,320 --> 00:29:39,720 Michael, multiple product teams. So we think of moving to digital products, right? 272 00:29:39,720 --> 00:29:46,280 So we now have these product teams and their product teams in, in a reasonably sized, 273 00:29:46,280 --> 00:29:49,960 reasonable sized agency and government, you're going to have different bureaus with different services, 274 00:29:49,960 --> 00:29:54,920 each with their own product teams and each with their own sets of tools and processes. 275 00:29:54,920 --> 00:30:03,880 And so this is what has allowed them to be faster than they used. And if we think of, 276 00:30:03,880 --> 00:30:10,120 you know, the old fireside and two guys in the woods and they see a bear and the other one, 277 00:30:10,120 --> 00:30:13,800 one stops to put on his shoes, his running shoes is that you can't outrun that bear. 278 00:30:13,800 --> 00:30:18,200 Why are you doing that? All I have to do is outrun you. What they're really doing right now in those 279 00:30:18,200 --> 00:30:24,440 agencies and in those DevOps teams is they're out running the old way. They're faster than the old way, 280 00:30:25,320 --> 00:30:37,000 but they're not as fast as same day cycle times. They're not as efficient as a thousand developers to 90 281 00:30:37,800 --> 00:30:48,760 operators. And to get to that level of efficiency and output, there needs to be coordination across the 282 00:30:48,760 --> 00:30:59,640 teams. They can't be their own product team silos. And so this is what has to be seeded is at small scale, 283 00:31:00,520 --> 00:31:08,760 a cross-commerce, a cross-functional group. And then once teams deliver the kinds of results that Jeremiah was 284 00:31:08,760 --> 00:31:19,400 describing at Kessel Run in the Air Force, then that will perpetuate itself. It will draw in and help, 285 00:31:19,960 --> 00:31:24,600 frankly, scale just because of the business success of the model. 286 00:31:24,600 --> 00:31:33,000 Yeah, our journey started with four sysadmins or platform operations team of four people because we 287 00:31:33,000 --> 00:31:41,480 were only sufficing two software application teams at the time. And to your point about looking at the 288 00:31:41,480 --> 00:31:50,920 organizational construct that there's institutional friction naturally, that has a parallel to or is 289 00:31:50,920 --> 00:31:58,200 consequential. The traditional system development process where most of what happens, you have the 290 00:31:58,200 --> 00:32:04,920 business or application owner who is trying to build an application to meet the needs of a citizenry, 291 00:32:04,920 --> 00:32:15,080 but is relying on somebody else owning the system development tools that they have to use and somebody else 292 00:32:15,080 --> 00:32:21,560 owning the data center that the application is going to run in and another organization that has to 293 00:32:21,560 --> 00:32:32,600 accredit the software and these siloed activities that are often serialized stage gates for building a piece 294 00:32:32,600 --> 00:32:39,240 of software and getting it to the ultimate consumer. That system development process, that deterministic and 295 00:32:39,240 --> 00:32:44,680 serialistic process, you're absolutely right that you have to start small with a cross-functional team 296 00:32:44,680 --> 00:32:52,840 to do it. But if you're a visual person thinking about all of these functional equities and silos in that 297 00:32:53,480 --> 00:33:02,120 serialistic process, you have to pick all of those silos up and turn them on their side and be able to start 298 00:33:02,120 --> 00:33:11,480 with a need of software and delivery of that software continuously and repeatedly on a cadence of every few 299 00:33:11,480 --> 00:33:20,600 hours. So how do you do that institutionally? It is all about organizational design and change. And of course, 300 00:33:20,600 --> 00:33:28,120 then all of the cultural aspects that come into driving the human behaviors to be more accountable and 301 00:33:28,120 --> 00:33:35,000 more accountable and responsible for achieving that outcome of starting with a need of software and 302 00:33:35,000 --> 00:33:45,560 delivering them. It is not in the mindset of sysadmin sitting in the data center owner organization to 303 00:33:45,560 --> 00:33:54,280 think about their life being responsible for the delivery of that user outcome. So how do you make them want to 304 00:33:55,240 --> 00:34:02,520 be involved in continually delivering and be motivated by the fact that they are supporting that? Or that 305 00:34:02,520 --> 00:34:11,720 the cybersecurity team, who is often a barrier to progressing of software through this process, 306 00:34:12,360 --> 00:34:18,600 how do you get them to be an owner of and shift left, frankly, on the way that they're working so that 307 00:34:18,600 --> 00:34:26,280 it's inculcated in continuous and they feel like an owner of understanding a need for software and 308 00:34:26,280 --> 00:34:33,960 helping the broader set of equity of functions in this process deliver that software securely. 309 00:34:34,520 --> 00:34:39,400 It's a different mindset and that is a significant part of the journey as well. 310 00:34:39,400 --> 00:34:43,640 So what y'all are just saying is making me think of another, I don't know what to call it, string of 311 00:34:43,640 --> 00:34:49,800 words. Let me run past y'all, which is, I think you definitely, you went over a pretty high level 312 00:34:49,800 --> 00:34:56,040 concept that I think in the software world, we're almost at the tail end of not realizing is a big 313 00:34:56,040 --> 00:35:04,920 concept anymore, which is the, I am a person who has responsibility for the end-to-end life of this 314 00:35:04,920 --> 00:35:09,720 software or put another way that like, someone's going to be using the software and they need to 315 00:35:09,720 --> 00:35:15,240 do something. So I should be interested in that. Like now I might be serving a little part of that 316 00:35:15,240 --> 00:35:22,280 chain, but I always know that it's like, it results in someone doing something. I'm not just obsessed 317 00:35:22,280 --> 00:35:27,240 with, oh, I turned in the, the report. And so now my work is done. You're trying to get over local 318 00:35:27,240 --> 00:35:34,360 optimization. And it seems like with the way for decades, if not since the dawning of time, 319 00:35:34,360 --> 00:35:41,640 maybe even back to an abacus when it comes to computers, like a limitation has been that like, 320 00:35:41,640 --> 00:35:46,840 it's very fiddly and it's expensive and prone to breaking. And when something goes wrong, 321 00:35:46,840 --> 00:35:51,960 it can be very hard to troubleshoot. It's not necessarily reliable or easy to recover from. 322 00:35:52,840 --> 00:35:59,480 So in a situation like that, the best thing to do is to be slow and steady and have a specialization in 323 00:35:59,480 --> 00:36:04,680 what you do. And, and the issue is, of course, we always want people to be outcome focused and paying 324 00:36:04,680 --> 00:36:10,920 attention to end. But like, until recently, we haven't really had to use the word of the episode 325 00:36:10,920 --> 00:36:16,440 here, the machinery in place that would actually empower someone to do something about that, that 326 00:36:16,440 --> 00:36:21,160 you bring up like the sysadmin who like in a traditional setting, they don't really have that 327 00:36:21,160 --> 00:36:26,200 many tools. And so they want to make sure the tools that you're giving them, they can do their, 328 00:36:26,200 --> 00:36:31,720 what that they can, they only want to be accountable for what they can accomplish with their tools. 329 00:36:31,720 --> 00:36:37,240 Like they don't want expectations outside of what they're empowered to do. And it seems like a weird 330 00:36:37,240 --> 00:36:42,120 abstract concept, but it seems like that's the key thing with technology nowadays is what you can do 331 00:36:42,120 --> 00:36:47,240 with a good cloud native stack and changing the practices is you can actually empower people to 332 00:36:47,800 --> 00:36:52,520 have that end to end perspective and do a lot more than just like that narrow slice that they had. 333 00:36:53,160 --> 00:36:57,960 But until you convince people that they actually will be able to accomplish the task you've given 334 00:36:57,960 --> 00:37:00,680 them, of course, they don't want to change what they're doing. 335 00:37:00,680 --> 00:37:07,560 Right. That, that legacy way of work and that, you know, the beholdenness to process is because of 336 00:37:07,560 --> 00:37:12,600 what you referred to it. And I call it a risk aversion. I'm going to deliberately 337 00:37:12,600 --> 00:37:20,440 take my time and make sure that the outcome is. And the aha moment that happens is when people realize 338 00:37:20,440 --> 00:37:26,600 that all of the layers of institutional checking of the checker and being deliberate and slow in the 339 00:37:26,600 --> 00:37:36,120 process that has inculcated for decades. Now, all of that is not eliminating risk. It is actually 340 00:37:36,120 --> 00:37:42,280 driving and adding to risk. And there's been some studies that looked at this. I'll reference 341 00:37:42,280 --> 00:37:49,400 in the Department of Defense, 94% of federal IT projects over $10 million end up over cost, 342 00:37:49,400 --> 00:37:57,880 over schedule or deliver broken and 40% get canceled outright. They never deliver. I had a $430 million 343 00:37:57,880 --> 00:38:07,400 mistake that didn't deliver. I was one of those in that project management process that just doesn't 344 00:38:07,400 --> 00:38:12,840 deliver. And even the software that gets delivered, then some studies have shown this, that to your point 345 00:38:12,840 --> 00:38:18,600 about somebody actually has to use the software to do something. Studies have shown that over two-thirds 346 00:38:19,160 --> 00:38:22,360 of software that's delivered in this deliberate legacy 347 00:38:22,360 --> 00:38:28,520 way actually has no utility to the end users. So think about the number of lines of code and the 348 00:38:28,520 --> 00:38:35,720 amount of money that we're spending to retain this legacy software and the cybersecurity vulnerabilities that 349 00:38:35,720 --> 00:38:44,200 it perpetuates. And two-thirds of it is actually useless. That's another big aspect. So realizing that the 350 00:38:44,200 --> 00:38:51,080 way of work is actually driving risk, not eliminating it is an aha moment that'll sometimes get people to 351 00:38:51,080 --> 00:38:58,040 start to think about, okay, I actually need to consider changing the way of work and utilizing technology in a new way. 352 00:38:58,040 --> 00:39:02,520 So y'all have hit on like the, when people ask me about bootstrapping or kicking off change, 353 00:39:02,520 --> 00:39:07,080 right? I think the, the starting small and seeding thing, I don't know. It seems like I don't, 354 00:39:07,080 --> 00:39:13,240 I normally I would say only, but I'm trying to be more responsible than hyperbolic all the time. 355 00:39:13,240 --> 00:39:18,520 But it seems like primarily the best way to get started. And it has another benefit 356 00:39:18,520 --> 00:39:23,640 that, that I don't know if we touched on directly, which is like, it allows you to learn what will 357 00:39:23,640 --> 00:39:29,800 work in your organization rather than just doing everything at once. As you like incrementally 358 00:39:29,800 --> 00:39:33,720 do one thing and another thing and another thing, like you're, you're in that uncertainty environment 359 00:39:33,720 --> 00:39:38,120 y'all are talking about, but you're learning what, how to fit these general practices to your own, 360 00:39:38,120 --> 00:39:43,080 which is great as well. So we've got that pattern, if you will, to apply. 361 00:39:43,080 --> 00:39:49,560 But okay. So if the, if you have people management and executive types who do want to change over how 362 00:39:49,560 --> 00:39:53,560 the organization is, is doing tech, like what you're going to go to the meeting on Monday, 363 00:39:53,560 --> 00:39:57,160 hopefully not have worked on this over the weekend and instead of relaxed, but like, 364 00:39:57,640 --> 00:40:01,480 how do you like kick this off? What's, how do you put together the strategy to actually 365 00:40:01,960 --> 00:40:05,640 put these changes in place? What do you see people doing in government to do that? 366 00:40:05,640 --> 00:40:12,120 So I've seen a pattern repeated now over 200 times in public sector over the last four 367 00:40:12,120 --> 00:40:17,640 years across all of the branches of the military and several federal agencies as well. 368 00:40:18,520 --> 00:40:24,520 That harken back to conversation a little bit ago. It starts small with cross-functional team that is 369 00:40:24,520 --> 00:40:30,120 empowered. That's another big aspect that there needs to be some senior leader champion in the 370 00:40:30,120 --> 00:40:40,760 organization that empowers an island of innovation to apply best of breed practices, technologies, 371 00:40:40,760 --> 00:40:48,600 and building up of competency and culture in an organization that is given the autonomy to 372 00:40:48,600 --> 00:40:59,000 apply these practices and achieve outcomes very quickly. But the key that I've seen in organizations 373 00:40:59,000 --> 00:41:04,920 that try to do this on their own by reading books or going to a website and learning about how to be 374 00:41:04,920 --> 00:41:11,080 agile often struggle. And some are maybe marginally successful, but by and large, when you look at 375 00:41:11,640 --> 00:41:17,960 those organizations that have started small and actually scaled and have been successful now in public 376 00:41:17,960 --> 00:41:25,800 sector for some number of years in continuously delivering modern software to their user groups, 377 00:41:26,520 --> 00:41:34,840 are those that paired with a partner that can help them digitally enable their workforce and leverage 378 00:41:34,840 --> 00:41:43,640 technology in a new way. And so that would be the primary pattern that I've seen repeated and working. 379 00:41:43,640 --> 00:41:50,200 I would just add one thing to what Jeremiah said, and because I think he said it extremely well, 380 00:41:50,200 --> 00:41:56,200 and that is that cross-functional team. It's important to get the structure because that's what you're going 381 00:41:56,200 --> 00:42:03,320 to scale. Start with an expectation of, and the leader should, the sponsor should in terms of what does this 382 00:42:03,320 --> 00:42:10,360 scale to be if we're successful, so that you have a, I don't want to say complete, but you've really 383 00:42:10,360 --> 00:42:14,280 ensured that you have all of the functions, the necessary functions represented. 384 00:42:14,280 --> 00:42:18,200 You've got all the, you have the tools and the capabilities you need, essentially. 385 00:42:18,200 --> 00:42:25,400 I'm actually more thinking about the people in the organization because that's really where you move 386 00:42:25,400 --> 00:42:31,240 from what Jeremiah was calling these sequential gates to, okay, we're now going to work and have 387 00:42:32,120 --> 00:42:38,840 this integrated process that addresses the process requirements, all of the process requirements, 388 00:42:38,840 --> 00:42:40,320 because that's what permits. 389 00:42:40,360 --> 00:42:43,320 Acceleration of, or reduction in cycle types. 390 00:42:43,320 --> 00:42:51,320 Yeah, those cross-functional equities extend beyond the people who are physically touching and 391 00:42:51,320 --> 00:42:59,880 delivering the technology. In government in particular, those equities extend to cost estimating, 392 00:42:59,880 --> 00:43:07,640 and the people and the people who handle budget and the contracting officers and the test organizations 393 00:43:07,640 --> 00:43:16,840 and the users or the organization responsible for defining requirements for systems. All of those 394 00:43:16,840 --> 00:43:24,360 additional equities are part of this environment too. And it can't be understated that often the way that they are 395 00:43:24,360 --> 00:43:35,320 working is going to change as well by looking at the need to be adaptive and responsive to change and 396 00:43:35,320 --> 00:43:37,320 the needs of the citizenry and 397 00:43:37,320 --> 00:43:39,320 continually evolving technology. 398 00:43:39,320 --> 00:43:46,280 Yes, of course, the people that are doing system administration and software development are 399 00:43:46,280 --> 00:43:52,280 going to change the way they're working. But all of those other equities involved in 400 00:43:52,280 --> 00:43:59,240 how funding gets allocated and put on contract. There's a new way of working for them as well. 401 00:43:59,240 --> 00:44:04,840 Yeah, it's interesting. We also work at a large company. We're always talking about changing and 402 00:44:04,840 --> 00:44:10,120 improving and working on our culture. And when you're naming off all the other parts of the system, 403 00:44:10,120 --> 00:44:15,160 and we experience this ourselves and other people do, but it highlights the importance of having 404 00:44:15,160 --> 00:44:23,080 everyone involved in that change. Understanding it's easy for us in IT and in tech to obsess about the 405 00:44:23,080 --> 00:44:28,200 software or the tech part and think that we've solved the problem when we can deploy the software to 406 00:44:28,200 --> 00:44:34,840 production in a day and make sure that it's secure. But to your point, right? You have to think of 407 00:44:34,840 --> 00:44:40,520 the entire rest of the organization is there also to service someone actually doing something, right? 408 00:44:40,520 --> 00:44:46,840 Like the whole organization is about citizen or a person like clicking on a button and doing a transaction, 409 00:44:46,840 --> 00:44:51,160 right? Like it all comes down to whatever you're trying to fulfill there. So there's an equal need to 410 00:44:51,160 --> 00:44:55,080 go back to them and make sure that they're on board with those things. I have all sorts of 411 00:44:55,080 --> 00:45:00,760 other abstract rambly questions I wanted to get around. In particular, I'm not going to ask them, 412 00:45:00,760 --> 00:45:08,200 but at some point we talked a lot about shifting from deterministic certainty to an area of uncertainty. 413 00:45:08,200 --> 00:45:14,520 And that's always a fun area to sort out how you make people comfortable with that. Comfortable with 414 00:45:14,520 --> 00:45:20,600 the notion of what we're preparing for is to not really know what we're doing or to know what it is 415 00:45:20,600 --> 00:45:25,160 we should be doing. And instead of exploring that rather than just locking down exactly what it is, 416 00:45:25,160 --> 00:45:29,560 which I think in every different domain is something interesting to explore, but maybe we'll figure 417 00:45:29,560 --> 00:45:33,480 that out some other time. If people are interested in digging into this a little bit more, do you have 418 00:45:33,480 --> 00:45:38,360 anything y'all would want to point them to? Have you started a Facebook group to discuss this stuff, 419 00:45:38,360 --> 00:45:43,480 some threads in Twitter? Where are y'all finding people talking about this stuff and talking about it 420 00:45:43,480 --> 00:45:44,360 yourselves? 421 00:45:44,360 --> 00:45:54,440 Our VMware public sector pages and the Tanzu public page have examples of success stories of 422 00:45:54,440 --> 00:46:01,240 implementation in government, certainly reaching out on LinkedIn. And then there's a great community of 423 00:46:01,240 --> 00:46:06,600 thought on LinkedIn around public sector transformation. And I'm pretty active on there, 424 00:46:06,600 --> 00:46:12,520 sharing the availability of these success stories and how to think different and come up with new ideas. 425 00:46:13,160 --> 00:46:19,480 I would just say contact VMware and we'll be happy to talk to you about how we can help your 426 00:46:19,480 --> 00:46:26,440 organization and listen to your specific challenges and goals and help you get there as consulting. 427 00:46:26,440 --> 00:46:30,040 And to use the word one more time, I think what's great is we have all the machinery, 428 00:46:30,920 --> 00:46:34,680 not just the technology, but the practices as well, which- 429 00:46:34,680 --> 00:46:38,600 The people and process and culture. And we will focus on that. 430 00:46:38,600 --> 00:46:42,760 Exactly. All right. Great. I really appreciate y'all talking so long about this. It was fascinating. 431 00:46:42,760 --> 00:46:47,400 It was good stuff. And this has been Tanzu Talk. If you want to get the show notes for this episode, 432 00:46:47,400 --> 00:46:51,480 you can go to tanzutalk.com and find the episode here. There's archives, 433 00:46:51,480 --> 00:46:55,000 videos, all sorts of other exciting, thrilling things there as well. 434 00:46:55,000 --> 00:46:56,760 And with that, we'll see everyone next time. 435 00:46:56,960 --> 00:46:57,380 Bye-bye.