Keep it small to make big changes, with Betty Junod

Episode 276 · Fri, 20 Oct 2023 14:01:57 +0200 · 45:53 · SRT · archive.org · all Tanzu Talk

0:00

Well, why don't you introduce yourself? Hello, Betty Junod. I am the vice president of product marketing here at VMware, looking after the modern apps and management group. And, you know, you've got a nice background, as we'll get into in working in the tech world, as I have myself for quite some time. And we were talking about, I had run into some people from John Deere. Where was I? In DevOps days, Des Moines, of course. Where else would you run into them just traipsing around? And they had an impressive presentation about their, I want to say, like three or four year, like at least introducing Agile to the way that they were doing software. I think they're cool and they say Deere, right? Instead of John Deere. But over there at John Deere. And so, and then I found out that they were working on some IT revolution stuff that you knew about. They asked, this is the only time this has ever happened where, you know, you, you, you currently and in the past, you know, I used to work at Dell. You work at big companies. You tell people you work somewhere and they're like, do you know this one person out of a hundred thousand people? And you're like, no, normally no. But for once, for once he asked if I knew you. And I was like, I know, I know her. This is the first time that that's happened. It's very exciting. And you wouldn't have thought that that would happen in Iowa of all places. Yeah, yeah, exactly. There's a lot going on in Iowa, apparently. But so, so we, we were just talking about the, the John Deere stuff. And then you, you brought up, you brought up a topic that, that's, I was just talking with someone about this earlier today, which, which is, is it's, it seems like it's, I don't know, maybe it's talked about enough, but not listened to enough. Is that, is that the parent in me coming through? Uh, but, but just the idea of like, especially in our area of like, you know, we're interested in people doing better at software, whether they're building it or running it.

2:03

And, uh, we work with large organizations and boy, they seem ambitious. They, they, they tend to have like really big plans about like the way that I jokingly always put it as like, you know, they're going to, uh, they're going to migrate 80% of their applications, uh, by next year, uh, just, just from a complete standstill. Um, but that doesn't seem wise. And so, you know, you, and everyone's been saying that every year. So we're kind of like how many percentages of apps are there now? Exactly. Yeah. I, I always think it'd be great to, uh, you know, I, I don't know if you saw it, but there was, uh, Benedict Evans put together a, a fun chart of like, let's go to the, let's go to the Goldman Sachs, uh, CIO surveys for the past 10 years and see what percentage of applications CIOs are going to move to the cloud each year. And I think it's, it's pretty much, it's always like, yep, we're going to move like 30% by next year for, for the last however many years. And are we there yet? I don't, not, not, not in all cases. Yeah. Exactly. Funny enough, uh, Coté is that, let's see, three years ago, my first forum, um, IT revolution paper that I worked on, um, was called no app left behind. It was about the, the, how you can get a hundred percent, a hundred percent move to the cloud. But as part of the paper, we said, you know, don't be dogmatic about it. Yeah. The, the secret is time. Time. Yeah. Infinite time. Yes. It's, it's like really reality's proprietary technology that, uh, you can rely on. And, and then, and then you brought up, you know, you brought up the point of, uh, in, in this, this discussion we were having is that people bring up a lot in, in a good way is like, it's good to start small, like, you know, start, start with a, uh, uh, uh, you know, one doesn't want to scale back their expectations of awesomeness, but you do want to, uh, match to reality. And so that's, that's with my lengthy setup there.

4:03

That's, that's the, the first thing is like, I mean, I, I talk about starting small all the time person I was talking to earlier today, you know, and so forth, but like, it does seem like, how do you sort of explain what small is to, especially like these organizations who are like, you know, uh, I've come in here as executive whatnot. And my mission is to, uh, transform everything. Like how, how do you kind of like scope down to like a good smallness? Yeah. And you know, what's funny is like, we've seen this pattern repeat over and over and over again, every time there's kind of a new, new technology thing, right. New abstraction layer, new tooling come out. Um, and I think it's, you know, there's within our, what we are doing today within this kind of like software development space. Um, it's kind of like you start with a application or a type of application pattern, a workload type and kind of solve for that. Um, and then that being, um, you know, kind of how you scope small, like I don't, I, I hear you. I feel like many leaders sometimes will see small as a negative, right? Like maybe they're not paying high enough, but, um, I heard some, um, I remember talking to one, a platform leader at a, uh, at a pretty innovative retail company saying, you know, what they did is they focused on a specific use case and that use case needed to address. Um, it was like a, the use case is a pattern that addressed a certain type of applications and there was enough of them in the organization. So start to see patterns and then you group things, you know, into like buckets of like, and that's the small, um, in that it's, it's, I guess instead of like small from a size, it's more small in like a focus. Right, right. Like, like a slice of things. Yeah. Like very, like, I want to solve for this type of thing. And then once I've done that, then I go to the next thing. Yeah, no, I mean that, that, that, that, that, that's a good version of small, right?

6:03

Like in, in that, especially if like, like when I talk about people with doing things in a small way, it seems like one of the primary reasons to do it is like, and this is another, you know, I always like to put things in these jokey terms, but like, it's also like, well, you kind of don't know what you're doing, so it's good to try it out a little bit at first and, or, or you want to have a, a learning approach to it, right. Where you're kind of like figuring things out as you go along. And it, it is like the, with the idea of, of like, whether it's picking like one or two, just like projects or applications, or like, there's also an idea of a, what did they used to call it in scrum? Like a spike, like, like some kind of thing, like a slice that goes, that goes all the way down from some angle. So you can test out like what happens at like the UI layer and then like the, the kind of ops layer, something that allows you to test all these different things to kind of learn by going through it that way. Cause it's like, you can never plan for all the permeations, deviations, or whatever in like the, the dependencies until you go through the exercise once. Maybe a non-tech example is before you bake like a seven tier wedding cake for like a massive celebrity wedding, maybe we can try it, a birthday cake for baking a birthday cake for your kids. You know what I mean? Sure. Is that, is that from personal experience from your celebrity cake catering company? No, I've never done the celebrity cake pairing, but you know, it's, it's like, we've got to build on our skills, right? Before you can, you know, um, do calculus, you got to like learn algebra or learn addition, like get your tables done. So, um, I think that applies in our tech stuff too. Like you don't know what's missing. If you're going to try something wholly new until you kind of try it out in a, in a, in a smaller scale, like a defined focused scale. Yeah. Kind of like a, uh, uh, some boundaries, uh, a, a sandbox as they used to say. And now, now like, like you, you know, you, you've been in like a, uh, uh, executive role

8:06

for a while. And, and like the, so that's like, you know, the other angle of like digital transformation or just getting better at software is like actually changing the way people work and what the organization looks like. And like, so you, you, I mean, I mean, I've, we've been around to VMware together for long enough that like, you've, you've seen through several like organizational changes, right. And like here and at other places. And so like, when it comes to like managing how you change the work process around, like, is it also a helpful to start small or like what, you know, regardless of what you end up having to do, what, what do you think the ideal way of going about, uh, about it is? Yeah. Because like, as we know, the changing the way people do things is like, that's the hardest part. I mean, the whole agile, like when we talk about agile and DevOps, well, as an example, it's the, there's a bazillion tools out there that do these things, but it's the, it's the way people work. Right. And it's the process, the interaction between humans, um, the processes, that's the biggest thing. And, you know, if we look at VMware, um, even, um, there's been a lot of evolution we've done within the team. Right. Um, and instead of wholly saying like, Hey, everybody in the team, we're going to do this other thing starting tomorrow. And we will all do it this way. Forget how you've been doing everything for, you know, months or years and how you've talked to, you know, your, your, your, your, your teammate on X, Y, Z. Um, it is also, even in that sense, it makes sense to say, pick a project or pick some, here's a, here's a new project or new launch or new, whatever. Yeah. And say like, let's, with this, we now have an opportunity to try it this other way. Let's implement a different system. Let's do our collaboration differently. Let's, you know, do our planning and actual execution on that, on that, um, project in

10:07

a new way to define a new way to work together. And then that, then you take that and say like, now let's try that on the next thing or an existing project. Right. That's, um, yeah. Like evolutions like that, they don't happen, you know, it's, they don't happen overnight. They can't. Right. Right. You can't just go into the factory and, uh, install new machines overnight and then, uh, plug them in and have things running as nice as that would be for some, some things. Uh, but, uh, like, so, so, you know, as you're saying, like you, you, kind of move on to the next one and like, how do you, how do you like, whether you're talking with people, you know, you do a lot of work with, uh, uh, you know, as you were saying, these papers with, uh, with it revolution and stuff, and, and you work on several of the, the groups there, what do they call them? Uh, not, not think tanks or think groups or working groups, or what's the name of like the little clusters of people? Um, they're called the, um, what's called the DevOps enterprise forum. And so those happen, uh, separately, um, uh, in a separate cycle. And typically it's people who've spoken at the summit events, um, which is where like, you know, John Deere and, you know, like Fannie Mae, other U S bank folks have come and spoken about either challenge they have or their transformation. Then those, then they often champion, um, the, uh, paper on that topic. And then the forum meets, uh, forum will meet once a year. And then we have like a multi-day workshop and it's like, you have working groups at each, like there's teams that write these papers. So, um, it's a mix of folks in the industry. It's, it's been a really rewarding, professionally rewarding experience. Cause one year, uh, my team, the team I was on had like someone from, it's like three different vendors. Right. Uh, and we were all, you know, outside of that room, we were all like competitors. So we had three vendors and like two or three like end user companies and we were all sitting writing something, um, to have to, that has like shared value to the industry.

12:09

Like, and we're not sitting there, um, selling our products, but just kind of bringing our collective knowledge together. So that that's, it's, that's kind of a unique and interesting experience. Yeah, exactly. Like I, I, uh, uh, I looked through the platform paper that, that you worked on. I think it was, it was purely about platform marketing, if I remember, or just, uh, yeah, yeah, yeah, yeah. Last year was, um, the developer platform and it was, it was, um, it was not about the tech part. There was another team that worked on the, um, uh, how to like, um, set up from a technical capabilities perspective, like define it. Ours was like, just beyond the technology. How do you make sure it actually works? Yeah. Yeah. And, and getting people to use it, right? Like that's the, uh, that's the conversation I have with platform teams. The most is, uh, like there's, there's one from about a year ago that I always, the one I always remember in my head is there's like a room full of, uh, people at a big, a big organization, infrastructure people. And as always, there was also the mainframe person who was, who was generally delightful because every time some question came up, the mainframe person would be like, yeah, that works and, uh, you know, in, in, in my domain and, and again, like the conversation we had was, it happens over and over again, which is the, the infrastructure people had said, uh, yeah, we like, we, we stood up the Kubernetes cluster and we can't get these developers to use it. Like no one's using it. So you're telling us like all this cloud native stuff is great and we give it to the developers and they don't seem to care. So what's up with that? But you know, that, that, that paper kind of goes over that ongoing problem of the, uh, I mean, I think we even have that, uh, that now, uh, whatever's milder than a cliche, a common saying of like, you know, build it and they won't come or like, you know, you can't assume that you just, you just release it. And so like, uh, I was asking that cause you know, you get to, when, when you work in those working groups and, and, you know, also just people that you talk with, like one of the

14:09

things I'm, I'm always curious to hear stories of is as you were saying, like, or as we've been saying, you kind of start small and then you do, you, you know, duplicated another team. And part of that process is also like, as we keep saying, kind of like learning what works and doesn't work. And like, what's, what's like, what does that look like between the teams? Right? Like, is it just like, I don't know, let's document what didn't work and then tell them not to do that or, or like, you know, do you actually like, do you actually kind of like engineer in experiments to test out ideas? Or is it more just like seeing what happens or it, and this is almost like, it's some variation of like doing lean startup, you think for just like how you're programming an organization, so to speak. But it seems like it could be a lot more squishy when it comes to things you can't compile to, to people. Yeah. Uh, and there was a, there was a, it's interesting cause I, I feel like from that prior paper to like this one, um, there was a, it, they're kind of connected because this year we wrote about business value. So it's like, if you do something like this, how do you define what is big or small, meaningful enough? Right. And then how do you make sure, how do you, you know, experiment and test and prove that it's working? And then how do you, how do you then report back what is value? Because everybody's concerned about ROI, right? So that was an interesting, um, discussion. Um, but if I look back at, um, the, the companies, like the, uh, the technology leaders we talked to like end users, people who we at VM were trying to sell our stuff to, right. And looked at like, um, asked them about what worked well, what didn't work well. If they look back at their experience, the interesting thing about, I think the, the idea of starting small back to, it's not small from size, it's just focus, focus defines the experiment and it helps you understand when things, when things, um, from that experiment, when things, uh, work

16:10

or don't work, they're controlled. You're, you're, you're able to like, understand what those, uh, how you have controlled variables. Right. So, um, like one platform leader was talking about how, you know, they were, they set up a new platform and then they didn't get, it was Kubernetes, Facebook, but nobody was using it. So immediately they were driven by, we just spent a ton of money on this thing and no one's using it. Well, it's only defined for this small scope of app, like only brand new cloud native microservices app. Okay. So what I want you to do is now be able to support legacy apps and COTS and all this stuff. And then before they even understood what, if this could be successful for the apps, they, you know, the target, they then like Frankenstein, the solution to do more. Now this platform has no focus and you're trying to, in many ways, it's like, you're trying to address all from the beginning. And then they were able to address none. Right. Right. Yeah. Focus. Then you can say like, I want to, you know, focus and aligning that focus with what you actually have in your portfolio. Cause the, the big thing that person learned was, um, they want, they built this like 12 factor app, like type of platform and realize, Oh, we have nothing that's suitable for that in our world. Right. Right. Right. Right. Yeah. Whoopsies. Yeah. Yeah. Yeah. Yeah. And, and that gets to that, like that, you know, it's, it seems like with those initial projects, you do need the, uh, the kind of minimal viable product, but, but it's, it's, it's, it's something it's like, it's more like what you were saying is, I mean, it's ridiculous when you say it out loud, but like you need applications that work on the platform you just built that, that actually like, that, that actually fit to that. And, and I think, you know, I mean, you were going over, you know, I was, I was, uh, uh, you know, at the, at, in the beginning, like preamble, they're saying people tend to have

18:11

like too big of a scope of what they want to do. Right. And you were just providing an example of, of that happening kind of not midway through, but like right after the initial success where you're sort of like, oh, this worked now let's do everything. Right. Like we've done, we've done like minimal validation to use the, the minimal word again, which, which it's, it's almost a variation of the same thing is you've got to kind of like what you're saying is you need to figure out, well, how, you know, the business value of the outcome of being successful, but also at some point you have to judge. Now we can take on more, we can widen the focus or the scope to, to use another word. And this goes back to like, you know, um, the whole idea of like IT turning into like platform as product, right. IT needs to run themselves like a business. So to that end, like, yeah, you should totally have like a big audacious goal of like, here's my vision. You know, like you're saying like the big one, I'm going to solve it all. You've got a new CIO. Like, this is amazing. We're going to do all this stuff, but like day one needs to like, that, that might be like a multi-year roadmap. And then you need to say, you need to say like, we will start here first because it's aligned to this, this line of business, this population, they have these needs, they have these problems. So we will do these, whatever, 10 applications as an example, it could be like some existing apps, we're going to solve some problem or like, Hey, we have a new, new business, like new, new product. We have to get out. Great. We'll use that as our target. Then you can say like, what we, they have to do is define like, what are some improvements we want to make in our business or a tech as part of this? So that you have like, how do you know it was to your question on how do we know that we've done it? That we did a good job. That we did a good job. We are, we feel good that we've met our success criteria to then say, are there any more apps

20:11

like this? Are there any more teams that fit this pattern? Let's, then you can, um, then you have like a good, you know, sales pitch to, you know, onboard more people. And then you can say like, okay, we've exhausted all of the ones that fit in this kind of type. Now let's go see like, can this platform fit or can our tool, can what we do fit other, you know, what's the next type of team type of app? Right. It seems, it seems silly when we say it out loud. Cause like, well, you should have like a very measured process. Like, you know, you set some goals, you say, you're going to address some challenges. You hit these milestones, then you go to the next phase and the next phase. It's, it seems a little pedantic for us to say that out loud, but it's amazing how distracted we, we can, we all can get, um, in this industry. Cause there's always a new shiny thing that eats up the like, you know, mental space of everyone. Yeah. Yeah. You know, I, I've, I've, I've, I've realized over the past year or so, as I've talked with, uh, some, some, some people that we've hired from, from industry, like our Tanzu value advisors. And now they help, they help, uh, large organizations we work with. And it's, it's fun to like, see them change over to, let's see, normally, if you work at a large organization, let me try to get this right. You're basically one to many towards, towards like, you know, the outside world and, and vendors and cloud providers, but then they totally reorient that where they're like, they're like one to many, but it's many different organizations they talk with. And so they get to see lots of peers there. And one of the things that we talk about frequently is that you have to, uh, like train yourself, not train yourself, but you have to be aware that like, it's totally good to say commonsensical things because most, most people kind of, as you're saying, like they at least know it, but then they just don't really like always practice it. Right. Like it's, it's, it's hard and you know, it's also, it's fun when you, I don't know

22:12

if, if, if you have done or do this, but it's kind of fun when you're speaking to a large group of people, like giving a talk and you have these little, like, you can have these little probing jokes that you make. Like, you know, one of them is sort of like, Hey, who, uh, who sits down at their, their, their standup meeting? Like, you know, do you actually do this? And like, you know, you can see the little chuckles and like eye rolls and stuff. And you get this anecdotal sense of like, yes, common sense is often the most uncommon one to, to, to, to go over, which, you know, I, I, I think is fair. And, you know, it is, it is like, as a slight variation of that, like you were talking about, um, working on like the, the, like value creation or business value, kind of figuring that out. Right. And I think there's, there's a tying up, like, did you, uh, uh, did you follow all the developer productivity metric nerd fighting over the past month or so is fantastic. There was this article that came out where, where McKinsey was trying to, they were adding four ways of judging developer productivity. And, and the wide range of, uh, you know, like engineering people got very upset about it and, and, you know, and, and rightly so they, they, uh, uh, well, more or less rightly so it was kind of like the argument about bimodal it way back when, if, if you remember that, yeah, yeah, that one was great because I always figured the people who didn't like bimodal it, they probably hadn't spent $5,000 to read the Gartner papers on it, but that's fine. Anyways, to cut myself off here, instead of rambling on and on. to hear myself talk, uh, like what that, what these new metrics are trying to pinpoint was like identifying, trying to come up with a way to show the value that developers were bringing based on the activities that they're doing. Right. Like, uh, uh, but it does get to this thing of like, what we would like, the ideal state is like you, if you have it, uh, and whether it's developers or operations team people, but

24:13

you're judging based on the output, like whatever the outcome or the value is, but then that gets exactly to what I'm, I'm, I'm guessing the working group struggles with is like, yes, good luck measuring that, right. Like how, how do you like, it's, it's almost this ongoing problem of like, how close can you get to like, ah, last week, the development team was responsible for this revenue. Right. Like, and it's, it's, it's hard to tie those things together. So you, you come up with this web of, of causality, but I, I don't know, like what, uh, is, is, is that, is that group going to solve our problems? What's, what's being worked on there? Uh, what's, well, the papers just published, I want to say like maybe two weeks ago. Um, just seeing in our discussions was the, a lot of talk around, oh, this, the gap between what you're going to say in a boardroom or two, where you're reporting into like your C-suite, right, those impact of the different functional teams to like what maybe an engineering manager is actually measuring because the gap is broad. Like, yes, yep. But you're, what do you say? Like, oh, wow. Our, our development team in this one application, which is basically one line of business, we have like a gazillion commits. Exactly. Right. But you're like, what if, and, but we've seen this, we've seen like, you know, when we look at like open source repos or like all these other things, like we, we know that those things can be gained. We know that doesn't always mean quality. We know that it's so like the, one of the big discussion areas within our working group was around like Dora, BSSH, all these things are great, but they're not, they're not like the end all be all. They're all indicators, but they should maybe just that by itself, like that metrics falls flat because it's always balanced against something else. Um, lots of rate of change compared against stability, right? Lots of components, but against quality, like you have to kind of measure those two together.

26:14

And then it's also, um, like I've talked to other, uh, uh, some other industry leaders in the past of like, that's great. We're making a lot of change, but it's not a high generating rate of video generating app. It's a very mature app. Does it need a lot of change? Right. We need more change on this new thing. We're trying to get out. That's in a more highly competitive space. So it's so nuanced. Um, so in talking about delivery value, there's a bit of, hey, line of business. We, there's things that we care about at the highest level. Right. Um, whether it might be like revenue growth or market share or having like customers, like, you know, buy like a new, like complimentary product, you know, whatever, whatever those highest, and to do that, what does that mean? Technology has to do to make that happen. So I think the biggest thing that came out was like, be a little more specific. So then you can walk it back from, you know, walk that back, um, to like the actual, like product engineering teams. Cause then if you say, we need a, we want to like the, one of the examples we had was a, um, uh, was a, uh, travel, like travel, uh, hospitality, like, you know, travel vendor type of, um, customer where they're like, we want to grow, um, direct revenue because they were getting most, most of their revenue. Um, their revenue share was actually coming from like third-party travel sites versus their own properties. Right. They're like, I want to increase my margins. Great. That's a, that's a sizable thing. And then say like, in order to increase my margins, what we need to do is have people buying from our direct sites versus the travel asset or something like that, right? Where they have to pay a royalty. Um, and so then they said, okay, in order to do that, what do we need? Realizing. Oh, wow. Our website is basically unusable. We have no, you know, like we don't have a way for customers to buy direct. Great. So now that, then that facts up, we're like, we need a website that can do these things.

28:17

We need a call center that can do these things. We need a mobile app that does these things. Then that becomes like, well, how quickly can we get that out there? Like, what are the technology things we need to do? Um, and then they can measure like a customer. Then from once it's out, they can start to measure like customer experience. How many abandoned shopping carts do we have? Um, or what's the time from like, I don't know, visit to purchase. The little things like that, that could then be very, that's very like engineering and product centric, but then we know those are, we've already drawn a line on how that is connected to like the, like some of the, uh, uh, uh, higher level business concerns. Yeah. Yeah, no, I, I mean, that's, that's a, that's a, uh, uh, well, it hits upon the, the, the, the, the common sense thing of like, you know, well, if, if, if you want to sell more directly, you should make sure you have direct sales enablement as, as, as you were joking up. But it is like that, that, that is, um, like, like I have, I have this hopeful theory that a lot of the issues that we talk about in like, you know, connecting the, the, your software to the business and all of this area of value stuff at some point will become a little easier because you'll get like a generation of like all the way up to the board of people who are just like, yeah, I, I know how software works. Right. Like, of course the software team is important and what they're doing is important because that's how people buy travel stuff. So like, they should do that. Right. Like we don't, we don't need to necessarily needle about the costs and like, which team did this value and did that. It's just sort of like, as, as long as the business is doing well, it's fine, which, you know, and you want to have that, you want to have those indicators of like health and like that, that things are not, you know, at that point, it seems like it's just a matter of knowing that you're not like wasting, uh, sort of effort that you're kind of hiding in the, in the big balloon of success. Uh, and you know, so that you can help people out as needed, but it does seem like, it does

30:21

seem like we're not quite yet at that point where people who are not in, in, in it, like really understand across the board that like, well, yeah, software is extremely valuable. So we should do that. And like, we don't need, we don't need these complicated spreadsheets of causality about whether it works or not. Like I use the app and I can see it improving done. I mean, not that it's necessarily that simple, but something along those lines. The one question that came up, which is interesting is, uh, it makes a lot of, it's much more clear to, um, everyone when you're starting a big new project, like, we, we don't have the ability to purchase online. We should definitely do that. That makes a ton of sense. Right. And so then there's probably, uh, um, that initial investment of like, oh, we need to get all these things done in order to make this happen, make a new mobile app, make a new backend, like to, to be able to process all this data. The question came up is like, once that's going and there's a run rate. Continuing to justify investment, where things got squirrely, which was interesting. Um, that was a question that came up in some of the discussions with the working group. Like, how do you continue to talk about value? Um, uh, because that one-time investment makes a lot of sense for that initial transformation. But what if it's the, the assumption from non-technical folks is that, well, once it's there and it's fine, I can just start to, we don't, we can reduce the costs. Right, right, right. And that's not always the case. So that, that was an interesting thought on like, it's, it's, it's continually figuring out, um, you know, cause your, your, your, uh, value metrics change. Yeah. More to like over time. Yeah. And, and, well, is this true? I, I've, I've been, I've been a lot of the, the, the financial planning actually does account for, I mean, you know, they got that fancy word, amortization finance people love that

32:23

word, but you know, there's the idea of exactly what you're saying is representing just the, the, the, the finances of, of, of something over time based on how, what you want to do with it, but it does, you know, like, like you're saying, we talk with a lot of people who have gigantic existing portfolios that they, they want to live with or not live with, that they want to modernize or not. And it is, it might just be impossible to kind of think about and quantify like the value of, let's just call it like agility, like, like, because it's, it's not, it's, you know, I, I, I always dislike analogies outside of software about software, cause we should just talk about software. But for lack of a better one, it's sort of like, we kind of understand that you need to pay like for maintenance on a road, cause it's gonna fall apart. So like you do that. And, but then like the idea of like, but this software works. So why do I have to pay people to sit around and do nothing, right? Like, like what, what kind of like, like, why is it important that this thing that I don't think I'm ever going to need to change that I could change it in the future, right? Like, like having that agility to it. And of course, you know, the, the, the, the punchline is like, well, you're probably always going to want to change it. That's why you're talking with us about wanting to modernize your applications. Like, and so that's, I mean, like, like you're saying, that's, that's that area of, for lack of a better phrase, quantification that I, I, it's really hard to figure out what to do about that because it's important in software. Otherwise you're stuck. Yeah. And it's something that you have to make, you have to keep, um, cause it's not like you can just, oh, I'll just hire some people when we need to make a change. It's not that, right? There's like, there has to be a steady state, um, of it. And it also gets more, that gets a little, like, um, at least with the actual application,

34:24

the application maps to a line of business, it's a little more clear. It gets a little, um, squirrelier at, um, platforms because there's now that, cause that will only continue to grow as it takes on more apps. And then it's also like a shared service. So how do you, uh, and we all know how well chargeback generally works, right? Right. Right. Yeah. Mostly doesn't. I think. Yeah. No, the, you know, the analogy or not analogy, this anecdote, I always think about chargebacks is like, you know, uh, uh, well, he, he works with us now, Tony McCauley, who worked at the home Depot a while back. And he had a great story about, uh, they, they had, they had, uh, they had what we call the Tanzu application, uh, service or cloud foundry back then. And they'd installed it and they had these initial teams, uh, that we were talking about. And then all of a sudden they were looking at like usage consumption, as we would say. Uh, and, uh, it flattened out for several months. And then they were like, what's going wrong? You know, we, we, it, it's kind of, this kind of pulls together a lot of the, the things, you know, we've been saying kind of jokingly is like, we're spending all this money to have this platform to be awesome and no one's using it. But then they found out to the chargeback point that like, people didn't want to use it because they didn't want to do the chargebacks. And, and there was this like, which, which is, you know, it's, it is hilarious because like at a certain level, you understand that chargebacks are just like, not real. Like, I mean, you know, things have to get paid for and done, but like more or less, it's sort of just like the same money moving around in some interesting way. Uh, anyways. So, so this was their flash of insight. It was, they were like, what if we didn't charge people? Right. Because like, we're already spending the money and we want them to use it. So maybe we should just make it easy. And then sure enough, you know, usage went up, but it is like, and, and, you know, I think like things like that make a lot of sense to me because at the platform level, it kind of

36:24

is a big agility thing, right? Like, it's hard to say just on its own, you can see the payoff for a platform. It's like, well, you have to do something with it. And, and until you actually get more and more applications on it, there's really nothing to measure. You can measure its efficiency, the uptime it provides for things, but like really you need to have an application to have it, to have any value. So you should make that as easy as possible. Yeah. Cause it's also, the platform is a living, breathing thing in many ways, right? You get it up and running and then you'll continue to add stuff to it. Um, add, uh, more services, technology, what, uh, what have you, as you bring on more applications and it needs to be again, like the road, it has to be maintained. You can't drive cars on it, car, you know, it's not continuously maintained or updated. So, so here's maybe like the, the, the last thing, you know, as I was thinking of things to talk about with you. And I think it's really like, you know, like it's, it's always, it's always good to see, to talk with someone who's kind of not only has their own ideas like you, but they have a conduit to all sorts of other people, right? Like whether, whether it's, it's people we talk with kind of in our, our, uh, VMware capacity or in, in the, uh, you know, the, the, the enterprise forum capacity. And, and that is like, I have this theory that we in the tech I've, I've, is this true? I've only ever like lived professionally in the tech world, basically. And like, I think, I think in the tech world, we get very excited about change and urgency and we're always like chasing, doing something new. Like that's, that's our thing, basically it's, it's, it's what our, our, I wouldn't say it's our product, but it's our, it's our motto. Yeah. It's our industry motto. It's, uh, yeah, I was gonna, I was, yeah, exactly. Exactly. Like it's the ethos, the principles. It's that thing above strategy or even vision, right? Like, but like, and so I, I've, I've been thinking recently, like we've got to like

38:27

be careful about how much of this urgency we let, like drip outside of our crazy world. Right. And, and this, this started coming up again, when I was talking with the John Deere people is like, what I found really impressive about their story is a lot of the things we've talked about, like clearly, you know, I would imagine like definitely at the C-suite level and probably at the board for the kind of changes they would need to do it. Someone had that thing I was joking about earlier where they're like, oh, software, that's really important. Let's do it. And like, you know, that allowed them to actually think about how software was part of the product that they were building and a vital part of it. Anyways, but it took them a long time. And so I wonder with this people, you, you know, all these people that you talk with like, like myself, like how you think about calibrating that urgency and kind of like, do they actually need more urgency or less or like what, how do you kind of push that button as needed? Yeah. I mean, from a business side, there should always be urgency because, you know, it's amazing today how quickly things can spike or decline. Right. Um, every like company, every product is at the mercy of, you know, the social media whims at the, these days. Right. Um, that said technology adoption, um, you know, there is, I mean, you and I see this, it's like shiny new object, like a million shiny new objects every day. What's going to stick, what's not going to stick. Um, the, and some of those require pretty dramatic, you know, technical, like architectural changes as well as like process and other changes and knowledge changes in light of a company. So, um, you know, with that, it's kind of a, they should evaluate, um, there should be an urgency from understanding and evaluating, but they should really measure. To like what they have today, you really need to like level set. It's like the guy who did like, I want this 12 factor, beautiful platform.

40:29

I saw like, he said, Roku and I'm like, I wanted that and realized nothing in their environment could do it. Having a really solid, realistic understanding of like, what do I have? Like actually applications. So then what are my application dependencies to use that as like a filter for, of all these shiny new things? What are the things that could be actually useful? Um, because some things won't, if you have what, you know, like high IO intensive apps or what have you. Right, right, right. Yeah. It's, it's almost like there, there's a couple of different like sliders for calibrating. Here I am using analogies to other things instead of the thing itself. We can build, we can build a little interactive, like big. Exactly. Exactly. And, and like, I mean, I, I like, I like the one you've identified, uh, which is like, would this shiny new thing benefit you? Like, like it might be cool and fun and even a best practice, but if you don't need it, then it's, you're going to spend a lot of effort on it. But there's another one that, that I think, I think you're, you're making me think of is that also there is a mixture of like timeline and risk, whereas us in the tech industry, like, I mean, we, we, we, uh, uh, in our lower, we have a book with the, the kind of like grim title, only the paranoid survive as part of our, like. We live in tomorrow land, right? Exactly. Exactly. Like, like part of our cannon is that like, whatever happened yesterday is old, right? Like, and so we, we're willing to put up with a lot of risk to like do something new. Whereas I think the timeline for most organizations is like, yeah, that's not a problem, right? Like, like we're, we're in manufacturing or banking or whatever. So like we have time, so there's no need to like take a huge risk and like run around, like, like doing things like that, which I think is, uh, that's, that's good to put in the spreadsheet there. They've been around for some of those companies have been around for 150 years.

42:30

You know, they're not trying to mess up like, like those insurance companies that have been around for a hundred plus years. We, we, as consumers really don't want them to mess that up either. Exactly. Yeah. That's, that's, that's a joke I've been using recently when, when I, I talk with a group of people is I'm like, I know you want me to talk about AI. So here's what I'm going to say. It's great. I mess around with it. You should use it. Just, it'll be fantastic. But if you're my bank, don't do it. It's like, if you're my doctor, maybe not. Yeah. If you're not my bank, you should do it. And then report back to my bank of how it went and it'll be fine. Yeah. I think it's again, like, yeah. Measured. Um, yes. I mean, it's exciting living in tomorrow land, but you know, the getting to tomorrow sometimes takes years. Yes. Okay. Yeah. Well, great. Well, I, I appreciate you, uh, giving me the chance just to ask a bunch of, uh, loosely related questions. It's good. Yeah. It's, it's always good, good to, uh, nice to get some new, uh, as they say, perspectives and just, uh, anecdotes and things like that. I'm a firm believer in, uh, what is it that, that data is a plural of anecdote. So I can go update some charts now and good stuff like that. Well, I mean, you, you've mentioned several, uh, several things you work on, but where, if, if people were interested in just finding out more about you in a non-creepy way, see, see things that you, uh, you've been working on, like, what would you point them at? Oh, you know what? I have them all, um, either on Twitter or actually probably LinkedIn. I have, uh, like some of these books, these books, papers, articles for VMware and also outside of VMware, you know, from my days at Docker and whatnot. Those are all, those are all there. Nicely. Yeah. You know, LinkedIn is going to, they need to make like a little webpage interface. I bet they talk about that all the time instead of just that like pinned post or something they need like, uh, what's it, they should buy that company that people use for, uh, for Instagram, like link tree or something, you know, the, the Lincoln, it's, it's like, like if you go into Instagram, like, and, you know, you can only like put,

44:32

well, now you can put like three, but you can put one URL. And so what people will do is there's some services you go to and you can kind of automate posting things in there. So you can always like, you can post your Instagram picture and you'll say like, uh, click the link in bio. And then there'll be like the last 50 things you were trying to like, you know, get people to get in. Oh, okay. And so like that, anyways, it's just a good index. Look, I, I, I look forward to clicking on your profile too. Exactly. A lot of products you're shilling. Okay. Yes. Yes. Shill tree. Exactly. Shill tree. That's what we can call it. You're an influencer. Yeah. Exactly. All right. Well, uh, great. Well, if, if you've, uh, if, if, whether you've watched this, uh, the video of it or listen to it online, it's been a, another fun Tansu talk conversation. I'll, I'll put some links to some of those things. If shill tree exists, I'll try to look that up. That would be great. I think we have an idea for you, sir. Exactly. But as always, you can go to, uh, Tansu talk.com and, uh, look up the show notes for this. And, uh, as I always like to advise the next time you get ahold of, uh, someone's phone or computer, just open up their podcast app and subscribe them to Tansu talk. Uh, they may be not thank you later, but I will, uh, for, for getting new listeners for us. Like, and subscribe. Exactly. All right. And with that, we'll see everyone next time. Bye-bye. Bye.

Tanzu Talk · 🍕 Get more pizza.