Beyond the Sea of No’s, with Jon Osborn

Episode 118 · 45:44 · SRT · archive.org · all Tanzu Talk

Well, I was telling my son with his homework, which either when I've got a daughter, when she gets to be homework, we'll see if my head explodes. But helping your kid with your homework, at least mine, is either the most wonderful thing that could happen or it helps you remember all the tall bridges that you could go jump off of. Now, is that helping with your homework or her homework? Touche. This is a good question. It's actually helping with my son's homework. He's reading some, what's that service that writes summaries of business book, Blinkist? He's reading some Blinkist-like summaries of The Wizard of Oz. And then he has to ask some questions afterward. And here's the thing I taught him. And then I want to hear if y'all have any tips, any sort of like study or homework tips you would give people. I told him that if you are given some reading material and you have some questions that you're going to have to answer, what you should do is read the questions first. So, when you're reading the material, you can like proactively answer the questions. And, you know, as always with things I tell my son, like, you know, he was trying to program some Minecraft stuff the other day and I was trying to give him advice. And I was like, you realize I was a programmer for 10 years. He didn't care, right? Anyways, I was a little nervous that the advice wouldn't pay off. But sure enough, he just like, he answered the questions as he read it. And I felt like I felt like I had taught him an important lesson. But guest, I want to ask you, what are some studying, homework, test taking things like that tips you would give to the youngsters out there to help them out? I think my advice is always like start early and work hard, right? If you wait till the last minute, you're like looking for trouble. Like, my, my... Now, that's not, that's not practical. No, it's not. My soon-to-be 18-year-old still waits till the last minute to like submit his college application. And of course, there's a software defect that they didn't do the date math right. So, his app is unsubmittable when before the deadline, right?

Yeah, yeah. Now, now, now, did he, did they teach enough economics in his school to allow him to tell you why that's great to maximize optionality? You want to wait till the last moment? Yeah, right. He actually brought up that argument. That was kind of funny. He took, he actually took economics and buried me with all these like new, newly found ways to argue his point. Yeah, yeah. You know, it's the cognitive bias of the fallacy of kids are just like this. So, don't try. Yeah, that's, that's what I try to keep telling, telling my son. And of course, I know he's not going to listen is like, oh man, I find myself giving out so much of this dad advice that I shake, I'm shaking right now, but it's just like, you know, the sooner you start, the sooner you'll finish. And then, you know, I feel like I'm giving my dad like a, a metaphoric, like cheers, like a little, a clink of beer. But how about yourself, Richard? What, uh, what are some tips you would tell the youngsters to get through their, uh, their studying? Yeah, I mean, I definitely read the, uh, no procrastination rule since I try not to do it myself. So, we try to do that. I also try to, uh, and you probably know, both know this too. Some of the education nowadays seems to be focused very much on the answer and not much of the process. So, I try to encourage the, uh, kind of think outside the box stuff, especially with like physical items. So, if it's like, you know, you get one of these random questions, like, I don't know how to solve this. I'm like, line a set of quarters or like use something physical to actually kind of visualize how this thing looks versus just staring at the sheet of paper for 10 straight minutes and then looking at me with like these puppy dog eyes, like, just give me the answer to me. Like, now, solve it. Like, post it, huh? Yeah. So, just use something physical sometimes to jar your brain is usually, for me, uh, what I encourage him to do. And, you know, then I'll quiz him with like random stupid Microsoft-like interview questions, like how many oranges fit in the state of Utah, just to kind of make him work through stuff in his head. Like, how would you possibly solve? The answer will be wrong, but just tell me how you might solve it. It seems to kind of help. Do people still give those interview questions? I think people who read those books 20 years ago and those companies aren't doing it anymore,

but now these other follow-on companies might be doing it, but I haven't seen them in a while. How about yourself, John? Do you, when you're hiring people, do you give questions like that? Um, you know, I've actually learned not to do that. So, I'm more interested in like somebody's like desire to like learn than I am like what they know right now. Yeah. Yeah. I'm pretty, I'm pretty sure I, uh, uh, I missed out on a job because I couldn't answer, I couldn't explain how, if you're in a lake and you get into a boat, how would you calculate the water displacement or something like that? And like, I was, it was just a job to like QA bug tracking software. So, I'm not sure how that was related, but, uh, anyhow, probably for the better. Now I'm anyways. So, why don't you introduce yourself guest? Oh, so, uh, this is John Osborne. I'm, uh, the, uh, enterprise architect for, uh, great American insurance here in Cincinnati, Ohio. Now, now you've given, uh, I think a couple, I get podcasts and presentations mixed up, but anyways, we've talked over the years for a while about how, uh, you know, a greater American insurance company. Yep. Do you say the company part? Do you just say, uh, it's technically it's great American insurance group group. We're like a conglomerate, but, but we own everything. So it's not really a conglomerate. So, so we, we've talked over the years about how you and your team, uh, and folks there have, have, uh, I mean, done digital transformation. That is in my way of explaining it, improve the way that y'all do software and therefore improve the way the, uh, the group as it were operates. Um, and I remember, um, I guess this was the year before last, your sea of nose presentation. Is that right? Yeah. Yeah. Yeah. Yeah. That's always been one of my favorite presentations because, um, uh, in, in, in a good sort of like,

you know, flashback to my time working in the executive suite and doing MNA, there was a lot of like tactics in there that were, uh, realistic and, and reminded me of both the good and the bad times. Um, and so, uh, you've always got some, some good takes on sort of like, what are these realistic tactics, um, and, and some pragmatic experience of how people can fix up the way they do software. But I think, I think the more interesting points, I mean, not to the exclusion of the other ones, but some of the things that are unique to the conversations we have are, so I'm, I'm going to the big meeting and, uh, should I use light blue or dark blue, but you know, I, stuff like that, like things that actually matter for, uh, spreading out change in a large organization. So all of that said, let's, let's first start with like, can you give us a brief overview of, uh, just kind of the story of when y'all started, I think maybe three years ago. I mean, no, actually, uh, I was, um, I started about three years ago, maybe two and a half, but, um, I was just, um, joking around with one of our, my lead platform architects because our, we first installed Cloud Foundry, um, two years ago, I think next week or the week after. So he, he was, um, he was, couldn't believe that it was two years ago that we started with Cloud Foundry. So, um, we, uh, uh, did that. We did an install dojo with Pivotal, um, which was great because we were able to train our platform people, um, really well. And then we went to Denver, took a team to Denver. That's the whole navigating the no discussion. How do you get, how do you get a team of people to Pivotal Labs in a way that's going to work out for you? Um, then we brought them home, built out a lab space, and we're now at, um, close to 36 people starting, um, with six. So it's a pretty, it's been a pretty amazing journey.

So. And, and like what, what kind of like apps and services or like, what's the things they're working on? Um, you know, you'd be surprised. Um, when we first started, people were like, Oh, we'll just do services or whatever. And of course we do microservices. Um, but we also have, it turns out, uh, a whole bunch of external facing apps, uh, either APIs or actual like mobile applications and websites and things that people previously valued, but didn't really consider as part of the tool set for some reason. I think that's sort of a business perspective maybe. Um, so we have that, um, we have a ton of, uh, back office. It's a software, which isn't technically it's an app, right? It's not just a service cause you have humans that you have to like make happy. And then, um, but then now we're, uh, we're starting to expand into the data space too. So we're taking our learnings from the microservice app world and learning how to do test-driven development and pairing and all that, all those activities, including the post-it notes with the data space. And that's been an amazing journey also over the past months. Yeah. I mean, what's that look like? I mean, how do you, first of all, did you start that because you felt like we've got this apps thing down? Let's to data, or did you just recognize that was a different bottleneck that you now had to tackle? And, and Kyle, what was the first thing you went after? So, you know, that's really interesting. Um, one of the things that happens when you grow up is sometimes you need to change leadership because you need to reapply skills other places. So last June, um, I transitioned the formal lab. We call it gas lab, great American software lab, uh, uh, to another manager at the time because we had this huge data problem. And of course, you know, my boss and his boss are like, and then CIO are like, well, of course John has to solve this. So we need to get them out of here so he can go solve data. And, you know, to some extent that was fine with me.

Um, but then of course, when I get to data, I'm like, you know, why aren't we doing all the good stuff we learned over there over here? So, so I started another lab, we call it bacon lab because, you know, data is the new bacon, right? And, um, you're happy at bacon. Yeah. Yeah. Funny enough that the, the, the programmers who work there, we call them baconators. I mean, you guys have pivots, so I, we need something, right? That makes sense. Totally fine. So, um, so I just sort of, uh, you know, gained some alignment with leadership. I'm like, oh, look guys, this stuff works over here. I don't really see too many things that will have to change to reapply it to data. Um, although there are a few things, of course, but, um, pretty much it works, you know? So we're going from like less than 4% test cases in data to like 90 something percent test coverage. So it's amazing. I mean, the amount of, um, work we're getting done is like extraordinarily higher. Like it's, it's not even, it's, it's hardly even measurable the difference. So now when you say data, do you mean like data, like a division? Or data is like, you're doing this in the database, like a test to store proxy or things like that? Uh, data as in we're completely rewiring how we account for our policies and claims in the corporate finance world. So we're basically shifting the entire, um, internal guts, um, uh, over to a new, a new way of doing business. Uh, and, and part of that's because for the same reasons on the front end space, you know, where you're slow with low quality and underserving your customer, um, data is arguably worse. Even it's ground to a halt. It's hard to make changes. It takes too many people. There's too many skills involved. The, like all the reasons that you know, you want to change something and we've sort of found a way to do it. Um, yeah. And I would imagine in insurance, like, I don't know the value stream of any given task, like, uh, slow data is probably a big problem if, if, if it picks it up.

Cause there's a lot, like you said, there's a lot of stuff involved, right? Like whether it's policies or, uh, someone applying for things or whatever, but it's not, uh, I don't know. It's not just like an ATM transaction or something. No, it's very much not like that. Um, uh, it is absolutely complicated and, you know, we're, uh, uh, we do specialty insurance so we have 34 different business units all with their own stuff. So how do you, how do you rationalize that and turn it into a corporate PNL? I mean, that, that is an extremely complicated task. Um, so we found ways to measure, um, success, like how, you know, you're going to make it and how do you know it's better. And, uh, we're getting through the implementation part and it's, it's, it's, it looks like it's playing out, um, great for us. So how are you, how are you measuring success then? Like, what is that thing that you would stick up in some, uh, executive dashboard that says like data team gets it now or they're getting it or we're improving? Yeah, there's a, there's a couple of things. So, um, in our old system, um, if you were to like, let's say add a checkbox, um, to the policy administration system, uh, a policy system is basically like the point of sale for insurance, right? So you type in all your stuff and then outcomes, this policy that you can sell to somebody. Right. Um, so if you were to add a checkbox in there that says like, oh, my car, you know, is four wheel drive, for example, um, getting that checkbox onto a report, um, took like 14 different skill sets and nine people to be involved in that effort. So, so, so you look, kind of look at that, look at that and you're like, okay, well, what are we going to measure here? It's like one, well, let's, let's see if fewer people can do it. So let's see if we can get down to two or three people maybe. And let's see if we can cut down on a number of skills that you have to know for that to happen. Right. But then we have other measures like the number of ETL jobs should be less, like the amount

of data we copy should be less. And, and so you kind of go through it and you, if you, if you take an honest sort of approach toward it, you can sort of see, um, what you should measure. And then, and then you have to go through the, oh my God, it's impossible. There's no way this, this can happen. Right. And then, and then you start getting creative about like, and getting real about what problems you're actually trying to solve versus like, you know, 20 years of history in your system and sort of setting aside some long held beliefs that of course are true and finding out that they're not true. Um, again, it's, it's, you know, navigating the nose with data, right? So you just have to, um, you know, imagine a better world and then turn it into, turn it into the right thing, but you know, measuring the right stuff's important because otherwise you, you could just squeeze the balloon, right? But you really want the balloon to be smaller. You want it to be simpler, less complex, less costly, um, and operate with fewer people. Yeah. You don't, you don't want to do what I do when I clean my kid's room and I just get a big Ikea bag and I stuff into the Ikea bag and then another part of the balloon grows. You seem like a good dad. Yeah. And of course, like the complexity is like, you know, breaking some back office app for a week or something, you know, it's a big deal, but it's not going to end the world. But like, you know, messing up the corporate P and L is probably not something you want to do, right? Yeah. So, so in the, in this, in this second round, I think I, well, I would assume you have at least if only with yourself, the benefit of having gone through something like this that works before. And so, like you were saying, you know, you could kind of say, Hey, we should maybe do that thing we did over there. But, um, you know, the first time you're going through this, uh, you didn't have that. And so one of the, one of the things that's, that's always interesting to ask people is, um, so how did you like bootstrap into like, we're going to do things in this new and different way instead of, as you were saying, the way we've been doing things forever.

Like, how do you, how do you prove that something is a new, better way of doing something when there's no firsthand proof of it? Yeah. So that's really interesting. Um, uh, one is like, um, uh, just speaking about data, I, I cheat a little bit, right? So I get a little head and like come up with some proof of concept work that like is real. So people have something to touch and feel versus, you know, believing that, Oh, John's doing a crazy thing again. Right. And we should challenge everything. So a lot of times, if you make it a little more real early on, um, that, that can help a lot because it'll bring people along for the ride. Right. If you're doing it for the very first time though, you might not really have that benefit and you really need to, to get real about, um, challenging some long held beliefs that your company might have and then write it down, like write down the reasons why something is or isn't, um, isn't right. And then, then you can have a debate about it and you can have, um, hopefully some air cover to go off and try some stuff that might not be normally, um, approachable. I want to ask you about that, the air cover thing. Cause I've been thinking about that lately as you give, I don't know, sometimes the personal risk you even take trying to sponsor these sort of bigger changes. I mean, obviously if it blows up in your face, you're probably marked for, marked for something and that might actually impact your career. So is there some sort of underlying conviction you felt like you had, like this is fundamentally broken. Let me, let me lead this through, even though this is going to be hard, there's going to be naysayers. And then what kind of air cover did you require to make sure you felt like this wasn't going to be a complete disaster? Yeah. You know, the air cover, uh, discussion is really interesting. Um, I was fortunate in that I had, um, uh, you know, not free reign to do everything, but at least my CIO would, um, you know, ignore complaints that John's doing stuff he shouldn't be doing. Right. Um, and, and so I think the more air cover you have, the better, uh, the change can be

because you can explore those areas that you wouldn't normally be able to explore unless you're willing to like, you know, go find another job. But, but even in, even in that case, you can only push so hard if people know you're not, you're, you're not safe. You know what I mean? Um, it's, it's easy to say no. Right. Uh, because it's like, well, well, you know, in six months, you know, he or she will be gone and I can just go back to normal. Right. Um, so, so getting sort of that, that buy-in at the right level is important. Um, but just recognize that like, you know, if your CIO is the one giving you the air cover, they can't really do any of the work. So somebody still has to work, right. And somebody has to prove the points and somebody has to like do the presentation and do the math on the finance and, and, you know, all that kind of stuff. So, um, you know, I, I think looking back, if I didn't have air cover, I think it would have been a smaller win and it, it may have taken a lot longer for it to happen. And I would have had to have grown like so much grassroots that it will became inevitable. Right. But, um, but I think that if you can get the air cover, the acceleration then becomes real. Like you don't have to like go through all of that, um, um, drawn out sort of behavior. You can, you can sort of get to it if you know what I mean. Yeah. I mean, did that person who sponsored you, I mean, this is his CIO, did they get your vision or did they get John? Were you cashing in chips you had or were you, did they buy what you wanted to do? And they said like, look, you are going to have to do the work cause I don't code. I can't build a demo app. I don't, I don't have the business case. Again, was this just like, I trust you don't make me look like an idiot. Well, yeah, I mean, to some extent that's true. I mean, in our case it was like, um, you know, the, the challenge was go faster and it really wasn't any specific directive. It was like, go faster. Um, so that's like, okay, what does that really mean? Right. And so I divided our organization up into a couple, couple things.

One is the app space and one is the data space and the data space is too hard. So I couldn't start there because it, it, it has all these challenges that I knew I didn't know how to deal with. And I knew, um, we needed experience in the app space cause that was a lot clearer road to success. Um, so, so we start in the app space then and, and start moving and learning really is the most important thing. And the rest of the organization is learning too. They're going, they're learning, oh, test driven development is a good thing. And pairing actually makes you go faster, not slower, et cetera, et cetera. And then, so, um, once you start to get that buy-in and you want, you get to see other people doing it and have more people experience it, then, um, then you start to win. Right. Got it. So, so you, you are, you are alluding to something that one of those things that, uh, was reminding me of my, uh, corporate experience. And, and one of those was, uh, it's, I had to learn this lesson several times the hard way, which is, um, uh, the corporation let's, let's, uh, take the people out of it. We'll tell you, we want to do this exciting new thing. And, uh, and, and then you're, you're all revved up to do it. And then, uh, you sort of go in to kind of like check out your library book of awesomeness to do it. And they're like, whoa, hold on. You still got to tell us why we're going to do this new thing. And like, you need to like prove out the planning for it. And like you were saying, uh, you know, come up with a business case and kind of run through the traps as we used to say of doing that. And so, uh, like, like what, how, how did you initially figure out like doing that sort of, I always think of it as like the meeting you go to, but like, what's like the business case you start with and the way you kind of show that this new thing, no one's heard of or done is worth trying out. Like, like what do you put together in, in the, uh, the nice slides and the charts and everything that you have? Right. Yeah. Um, that's, that's really, uh, that's, that's really good question.

And I think, um, you know, in a, in a generic sense, it obviously it varies company by company. Right. Um, but I would divide those, the, the sort of opportunities into two, two camps. Right. So sometimes you're trying to do cost savings. Um, that's one camp. And sometimes you're trying to grow your top line or your, make your business bigger. Right. And that's sort of the other case. And the reason I divide those up is, um, you know, on the cost savings side, I think the bar is pretty high to get started to make, to build that business case. And, uh, because when you bring in a tool like Cloud Foundry, for example, um, you have to retire enough old stuff to kind of pay for it. Or otherwise the business case is upside down. Right. Or you have to consolidate enough things or you have to like, you have to do, you have to have a lot of stuff to make that work. Right. And, and a lot of companies do have a ton of stuff. So that works out for them a lot. Um, but what you're not focused on in the cost savings business case is, is, you know, actually making the customer happy. Maybe you're kind of making it happy because the costs are lower, right? Yeah. I've, I've been reading this book, uh, this textbook on a lean accounting and, and it's in manufacturing. So you've got to like imagine, man, it also makes you realize, I'm glad I'm in software and not making, uh, but, but what, one of the points that they brought up that was interesting is oftentimes you put, um, uh, you put a lean initiative in place and the whole point of lean is, is flow basically. And so when managers end up looking at the short, medium term returns, it's like more expensive like sometimes. And so of course they kill the lean initiative because you know, who's got time to be wrong basically. Yeah. Right. Wait for it to play out. Right. Yeah. Yeah. And, and, and one of the points that they make, which, which I'd be interested in hearing how this is applied to you and you were kind of alluding to it is it's one thing to like save money per unit. I mean, we can all agree on cheese, right?

That's great. Uh, but what's too easy to lose sight of, um, I think in software, especially is like growth or like opportunity or how these new things were created. And, and I'm curious, like if, and how you like capture that. Cause at some point it can't just all be savings as tasty as those are. Yeah. You know, I think, um, I think that if you start with that cost savings business case, you do have to have a longer term view onto, okay. Hey, when I'm done saving and I get to my new baseline, what am I going to do now? Like, am I going to be able to affect the growth side? What type of apps am I doing? Am I going to be multi-cloud? Am I like going to get out of my own data center into a, into a cloud data center? Like, like what's the longer term sort of goal there? Because I agree the savings one kind of has a definitive end and it might, it might feel good right now that I'm retiring all this stuff, but like when I'm done, I'm going to be like, like, okay, what, what next? Right. And, and now I've learned a bunch of stuff about how to operate differently, but now I want to turn that to sort of the business side. Right. Or I have a somewhat expensive PCF environment that now looks like the thing I have to actually save money on, because now I have consolidated everything and like, crap, now I have to get the AI costs down or, so it seems like, yeah, you're always in cost savings mode. The next platform becomes the next thing you have to save money on just in this endless loop. Yeah. You get in this loop and then, and then you, you, it's hard to go over and to the, to the boardroom and say, Hey, look, like we actually affected the business. Right. Um, with that. Um, so personally I prefer the growth side business cases, uh, much, uh, much better at the same time though, um, you know, you have to include a little bit of, uh, savings that becomes, uh, a choice, right? It's like, okay, I'm going to grow and I'm going to spend some money, but if you want to, here's the areas where you can save budget dollars if, if that's what you want to do.

Right. And then it becomes a business, a business choice. Right. So I'm going to write all these apps for you. We're going to watch the, you know, the revenue go up or whatever the customer base get bigger or whatever your goal is. But, but at the same time, it, um, should save money, but let's not base the business case on that, but let's present the options for that. So let's, let's make sure that like, as we're on the growth side that we're paying attention to the cost side, because it's going to be more expensive for a little while. So how do I know when I get to the end, I can correct my baseline later. So my costs will in fact drop. Yeah. That reminds me of, uh, uh, of one of my own, my old bosses who was a manager of a large group. And he basically, uh, he was trying to encourage his team to be a little more, um, I don't know, on the ball to match his management style. And like you're saying, you know, you're providing options, uh, to, you know, the people above you, whoever that may be. And he was always telling them, like, I want you to bring like decisions to me, right? Like, like things that I should choose to allocate the resources that I have. And like, my, my job is to decide things, uh, essentially, um, which, which I think, I think is for the type of like bootstrapping and then ongoing work is, is, uh, from what you're saying is probably as valuable as any, any environment is like, we can do these two things now or these four things. And, you know, I think we should do this one thing, but let's explore all the options that we have explores the wrong word. Let's decide amongst these options that we have, uh, hopefully not submitting your college application at the last minute. But, uh, now, now that, that, that said like you, you, the, on the, how we're growing the business, uh, side, like how, am I overthinking this or is it hard to show like a cause and effect between like software and like revenue growth? Like how that seems real, it seems like I'm doing that, but how do you do causation?

Yeah. I mean, um, so it's really interesting and, um, uh, I've spent a lot of time thinking about that and, and sort of the bridge that, that I've had to cross in my mind is like things like cloud foundry that support your speed, like, so that you can put a culture on top of it and go faster. Those are like platform concerns, right? So if you, if you try and justify the platform or the business case on this one business thing, and then this, you have this big platform that you have to grow and train a bunch of people on, like, it doesn't really, it doesn't really play out. Right. Because, because now I have, you know, 600 AIs, but I have like, you know, 12 for this one project that's growing the business. Right. So how do you, so how do you cross that bridge? Right. And I think, um, the way, the way I got there, um, for, for our organization is we talk in terms of, um, um, staffing flexibility now because we're cutting down on the number of skill sets. So if you remember that part of the conversation, and so I have less things to train and the things I'm training are more approachable. Um, so that means that I can rotate people between teams and I can, I can gain, um, a lot more organizational knowledge, uh, on these teams. And, and that seems to resonate with, um, the executives because one of the sort of the, the sticks in the mud that you get stuck in, that you literally get stuck in is I, like, I have this one team that can do this one thing. And now my schedule all of a sudden got serialized because that one team has to do this thing. And then they're going to move and do this thing and this other thing. And, and so the way we've kind of played it out is in order for us to look faster to the outside world, we need to be able to do more things at the same time. I can't, it can't be one team anymore. Right. So, so when you look at your business cases, um, you, you're more apt to be able to say, well, I want to do three of them this quarter instead of just one this quarter. And that, that's where, um, sort of, I went to with, with how to get the organization on

top of this platform, doing more stuff and actually watching things happen more often. It's not that any one project is getting delivered more quickly. It's that now I'm doing like three or four and where I used to be able to do one. Yeah. Yeah. You know, you're, you're, you're, you're making me think there's like, like a theory of, uh, uh, this, this is like the Coté confessional podcast where I tell you how I think of things in my memories, but like, I, I get all torqued up about trying to prove things that should be intuitively believed. Right. For example, uh, if we had software that users that was more efficient and productive, so users spent less time using it to accomplish their jobs, things would be better, right? Like, like intuitively that just makes sense. Uh, and, and, you know, you're making me think there's a theory of when it comes to improving the way you're doing software and it, there are a lot of arguments you would want to make intuitively. Like if we reduced down our release cycle time and our ability to patch things and allowed people to self-manage their stuff in a DevOps way, then we're going to reduce our time to market and up the quality of our software and people using it. And intuitively, well, hopefully to anyone who would be listening to this podcast, that makes sense. Uh, but you know, my theory would be the reputation of it is so terrible that no one believes an intuitive argument from them. That's absolutely true. That is absolutely true. And so you've got to like win that trust back and then you can start relying on intuitive arguments, uh, you know, backed up by some spreadsheets and, and not, not to be dismissive of that work, but you get a lot more understanding and benefit of the doubt for what should be easy, intuitive arguments to make for process improvement. Oh yeah, absolutely. Absolutely. And you know, um, it shouldn't be lost that sometimes just doing two things at once, uh, but at the same pace is, is twice as fast as doing one thing at a time.

Um, but, but you're really not working faster, but the outward perception is, is that you're doing more, which is, which is true. Right. Um, um, I like that parallelizations of argument. Cause in your business case, you're not asking for 50 new heads, right? I mean, you may be asking for some technology investment, but you're saying, look, making this move, you will actually see higher throughput, even though we're not asking for a major organizational staffing change. I think that's probably a pretty powerful part of that business case to not have to include that. Yeah. I mean, back to Coté's manufacturing thing. I mean, really, really it's about throughput, right? So, um, if I can do, do twice as much stuff with the same number of people, that's a good thing, right? Exactly. So the trick is the trick is you oftentimes get stuck where I don't have teams that can do that. Right. So that's where the simplification and, and selecting a single platform instead of trying to use, you know, AWS for this project and GCP for that project. Now I have two teams that can't talk to each other, you know, get on one, get on one platform and then share the knowledge and, and, um, that, that, that strategy seems to be playing out for us. So, yeah, I mean, when you, I mean, you've, you've touched on kind of finance and funding a couple of times. Did you actually have to change anything within the company on, you know, projects for projects always funded annually or projects funded as they went along, were there things like that that you had to deal with, or is this just like, Hey, has this helped foster any change in how you think of funding products versus projects, that kind of argument? No, I mean, um, that change, um, needs it, it's coming. Right. So we're, well, like I said earlier, like two years in, right. So last budget cycle, uh, we were unable to commit to doing the estimates a different way for 2019. Nice. Um, but for 2020 it's, you know, we're, we're going to have real discussions around, Hey, this is the old estimate. So shouldn't it be, you know, some percent smaller if we're going to do the work the new

way that we know is better. Um, or should we go even further and do some sort of, you know, value stream financing and start to treat certain things as products. Right. So, I mean, out of the 500 projects we have, you know, not all of them are going to be software products because some of them are just maintenance activities or, you know, that kind of stuff. Um, but for the ones that are, you know, which ones do we want to try and fund differently? And, and how's that going to work? So those are really, uh, sort of topics that matter right now because the scale is starting to have an impact on, on that. Right. So when you do your first project, it doesn't really matter. Like, in fact, if you, if you bring all that stuff up, you're just going to get bogged down in like these rabbit holes that aren't helping you. Um, but as you, as you get to scale, it becomes a real problem of, well, how are we going to fund this thing? And, and what happens if we have all this money left over, what are you going to do with that? Or what happens if, if you discover that the product is more valuable and you want to spend more on it? Like, how does that work? So. Yeah. You, you, you get into that, that, that exciting category of good problems to have. Right. Which there's still problems, you know, the words right in there, but, uh, so, so they need to be solved. Well, the, the, uh, uh, you know, you, you and I have been talking about like doing some more, uh, writing up a finance stuff, which, which I think would be fun, especially as, um, uh, as you sort of bush wet, you and your, your team sort of bushwhack through how to do that. Cause I think there is kind of like, like Richard was asking about, like, I don't know. I, I, I don't know accounting that well, but like, I'm always very unsatisfied with how like the numbers stuff work around software. Like it's weird. So there's gotta be some better way, but on, on a, on a slightly different topic, kind of, you've kind of alluded to this with, uh, with, with people and staffing, um, one, one of the things, and I think this is when we were recording a podcast somewhere, but one of the things I tell people a lot to repeat your advice is like, uh, the kind

of skillset of the initial teams that you form. And again, with that long-term view, why it's important to not have all, I don't know, level 20 wizards, so to speak. And, and it's good to have people who are like experts, uh, I'm making air quotes here, but you also want to have, and maybe, you know, a good phrase for this. Uh, I w I was, I was recently chastised by my book editor for using this term, but you want to have some normals, right? Just, just like people, like if I went to go back to programming, I would definitely be like normal minus five, right? Like, um, I mean the theory there being, and then I'll, I'll stop talking is that if you had, let's say a team of 12 experts, uh, and you would see it wonderfully at your project, you would go to your peers or whoever and say like, Oh, look how great this, uh, this new process is this agile stuff. And they would in, in the most cynical version of this scenario, they would say, well, of course you are successful. You took all of our best people from us. And if we had all the best people, we would be successful as well. So, which kind of leads to like, you know, don't do that with your initial team, right? Like make sure that they are proactively build up your team as a marketing bullet point on your slide. And so I wonder if over, over the time of doing that, has that, um, like how, how has that worked out? Has that kind of proven itself out? And like, what are the benefits or drawbacks of that kind of staffing approach? Um, so I think in the beginning, um, you know, I used a volunteer model to build the first team and then sort of very selectively put that team together, uh, having the whole spectrum of, of career, um, um, age, right. So some young career people, mid career, late career, and then different skills. So took a .NET guy to a Java project, for example. Right. Um, I think that played out, um, sort of masterfully well.

And so what's happening at scale then is, you know, we started to have stories, uh, that, you know, almost every week and certainly every month, we have a story about somebody who's starting on, on the team and they don't want a pair cause they don't know what it is and they don't know how to do TDD. And then after, you know, three, four weeks, they're, they're all in. Right. And they're like, oh my gosh, I'll never write software a different way again. And it just keeps, continues to play out at time and time again. Um, and I think that's just because it's the right thing to do. And, and so what's happening, um, to us, interestingly is our level 20 wizards, for example, um, we're sort of accumulating them into a center of excellence where these people can, um, go join a team like early on for, you know, the first couple of weeks of a project just to make sure they get on the rails and they're, and everything's going well. And everybody's like the veil's been pulled back and like all this mystery about this awesome stuff kind of goes away because it becomes real for them. And we're, so we're starting to deploy those people, um, differently and we really don't depend on sort of any masterful people, um, to drive, uh, like sort of an everyday project anymore. Um, uh, I think, and I think part of that is, um, people are just, uh, they, they become so much more productive that we don't need them to be a superstar anymore. We just need them to be normal and that's fine and good and sustainable. Right. And then for the people who actually are extraordinary, we have a role for them too, which is make everybody else become normal. Right. Like, yeah, no, no, exactly. That's, that's like in the, uh, four or so years I've been, uh, talking with and observing like the organizations like yourself and other pivotal customers. Like that's one of the more humanistic things I've come out of it is, um, the notion of like leveling the skill level in your team sounds bad at first because you're basically

like going to the least common denominator. But I, but I think, I think it's, it's more of what you're saying. And in the DevOps world, there's this notion of like hero culture is bad for various reasons. And it's, I think it's more of, I don't know, to kind of make up a rephrasing is there is more widely shared responsibility and contribution from all team members than like these one or few tent poles that are a very fragile way of doing things. And so, you know, I don't know, it's almost the wrong perspective to say like people are raised up and others are lowered down. I think, I think it's more that people are basically raised to the same level and they all sort of, not that they're interchangeable, but, but they all become better. The team becomes better for sure than if there was just like a little spike of improvement. Yeah. And, uh, you know, we're, I personally like to focus on the sustainability of, of it, right? Of it all. Right. So if you wanted everybody to be superstars, then you'd be constantly, you know, training new people because the normal people, maybe they, maybe they don't want to do that. Maybe they just want to be normal. Right. Um, and that's, that needs to be okay that because, you know, organizations and marketplaces where you hire from and all of those that there just aren't like the expectation that everybody's a superstar just isn't, it's not, it's not real. It's a, it's an illusion, right? The practical reality of it is that I, you know, I have a bunch of people that I hired and now it's my job to train them and give them meaningful work to do. And the good part about what we're doing is they're so close to the value delivery that they get really excited when they hit that production button for the first couple of months. And then it's boring after that. Like, you know, I, I actually, I paired with them, um, um, for whatever reason I got on this project and I paired with, um, uh, a young junior programmer, um, who had never done it before. And in three weeks we delivered, you know, uh, like $2 million of business value. And, and she was like, wait a minute, that was crazy.

Like, are you kidding me? And I'm like, yeah, I mean, it was kind of cool. Right. And, and so she, um, um, actually changed her whole outlook on her career and what she's doing. It was a really excellent outcome. So yeah, that is not, not only for, from your corporate overlords is it good to show cause and effect, but from the people actually doing the work. Yeah. Well, you know, we push, uh, we, we try to push this decision-making down to the team. And at first they don't really realize what that means, but then when they, they see that they have a pathway to production and they have a business partner sitting next to them and they can go together, like that is like, that's where the sustainability comes from. It doesn't come from my type places, my lines of software as you do. It comes from, you know, partnering and, and growing something together as a team. Like that's, that's really where it is. And I just don't really care how fast you type. Like, it's not my, I don't even hire people for that anymore. Like, yeah, they don't need to figure out a water displacement. No, I mean, it doesn't matter. Like, well, you know, you need to be reasonably, you know, analytical to write software, but you know, after that I can train the rest. But what I, what I can't do is, you know, make you be happy with toiling in your cube. Right. Totally. Totally. Well, great. Well, well, uh, well, thanks for being on. I think, I think it was, it's always good to catch up, see how things are going. And, uh, man, we, we ended in perhaps one of the more positive notes of our podcast series here. It feels like it. It's only Monday. So we'll see how long I can coast off of that until, until we get to Sunday night when I have to help my son with his homework, but, uh, thank you. Thank you. So if, if people were interested in, uh, seeing what you're up to or, uh, or anything like that, you got, you got like a Twitter account or anything to tell them about. Yeah. Um, at, uh, J O N N I O 20 Johnny O 20 is my, uh, my Twitter feed. Um, that's, that's a good place to, uh, to interact or, you know, follow me and we'll have a online conversation. And then, uh, of course, if you're, uh, in Cincinnati and you're successful hitting me

up on Twitter, maybe we can have a lunch or do something like that. So that'd be fine too. Yeah. Yeah. Y'all are in a, I haven't been able to see it, but you've described it to me and you're in a very, very beautiful building. Go check that out. Yeah. It's a hundred year old, um, um, bus terminal building and, and, uh, there's been several movies filmed in there at one just this past year by Netflix. So it's pretty, it's pretty interesting. Yeah. Nice. Nice. Well, thanks again. And, uh, thanks for listening. Thanks for your time. Yeah. Thanks for listening. This is always has been Pivotal Conversations. If you want to find all of our old episodes, it's at soundcloud.com slash Pivotal Conversations. And we post show notes for this, uh, every Thursday, if I'm doing my job correctly and we'll put links to, uh, to that sea of nose, uh, conversation or presentation. And there's a couple of podcast episodes we've done and, uh, John's Twitter thing. So as always, thanks for listening, and we'll see you all next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.