From grumps to transformation metrics, the questions we get asked (Ep. 100)

Episode 85 · 51:27 · SRT · archive.org · all Tanzu Talk

Well, you know, on my other podcast, the Software Defined Talk, we always end each show with some recommendations. But I thought for this episode here, we would start with just overall recommendation. I think we've tackled this topic before, but both of you and I do business travel every now and then. And so this was going to be, what's your, I wouldn't call it number one, it could be, but what would be one recommendation you would give people for business travel? It could be like a thought technology, or like you should have four wheels on your suitcase instead of two, or like take a tote bag, or here's an app that I like to use. What's something you would recommend? Oof, on the spot. I am, I don't check bags anymore. Since my very first business trip, they lost my luggage and I walked into the customer site in t-shirt and jeans like an idiot. So I'm almost maniacal by carry-on. I'm not the person who lurks at the front of the line until they call my section though, because I'm not a psycho. But I do try to get fairly quickly to at least get my bag in the overhead. So that's probably my, like don't check it unless you're carrying like a crossbow or a bike or something enormous. Probably just carry on if you can. And then my on-plane advice, I've shared this before, I don't think with you, and boy, the first, the minute the plane takes off and that person puts their seat all the way back, my move is to put the air vent onto their head so they get really uncomfortable and put the seat back up. That's funny. That's, that's a, you know, you're like, you're always secretly aggressive. Very subtle about it. It's a quiet power move. So either they move to seat up or they get pneumonia. Like I win either way at that point. That's funny. That's, that's strategic use of the air vent. I don't, I don't pay attention to the air vent that much anymore, that much anymore. But I guess as summer approaches, I probably will. Like there's, you know, leaving from Alice, Alice, Austin and Dallas. I was amalgamating the names there. It's often the case that it's a little warm in the metal tube on the runway in Texas. So maybe I'll get familiar with it.

Well, I was thinking, you know, my, my piece of advice I try to give people is it's, it's a, it's a good compliment, I think, for the never check a bag, which, which is, is basically like, once you get past airport security, you should just relax and not worry about anything. Because like, worst case scenario, maybe if you're like, you know, uh, an overly vigilant employee who actually worries about as, as one should, I mean, I know I definitely am who worries about like, you know, performing perfectly all the time. Like even if your flight's canceled or late, you'll get there eventually. And it's just, there's just like so much stuff out of your control that, uh, if you spend all your time freaking out, you're just going to be freaking out. And that's a great point. Yeah. Yeah. So I figured it's just, I mean, you know, I guess there is a certain line that, that you cross over, I think when you do a lot of travel, like I do where, uh, well, as someone once told me, if, if you're a frequent traveler and you don't miss and you, and you miss, let's see, and you're not missing a few flights each year, you're probably doing it wrong, which, you know, if you only travel like three or four times a year, that's a bad idea to miss flights, but it is, uh, you know, you'll get there eventually and it's fine. And so you should just relax and chill out. Cause you know, there's going to be plenty of other people freaking out and they're going to suck all the energy out of the air, uh, which is too bad. Are you a people watcher at the airport for me? That, that is, I purposely try not to read or use my phone as much. Cause I come up with elaborate backstories for a lot of the people sitting next to me. Of course. Yeah. Yeah. Yeah. I'm a, I'm a, is the word inveterate? Does that mean constant or something? I, uh, I, I people watch all the time and, and I guess, I guess that kind of brings up the, uh, the second little, uh, business travel advices, you know, I usually, you know, listen to a podcast a lot when I'm in my life, but, uh, I find that if I'm traveling somewhere and I'm walking around, I try not to listen to a podcast so I can just listen to the city

and, uh, see what's going on. Maybe like I was in Paris a couple of weeks ago and like, after being there like two or three days, you know, I I'd listened enough to the city, I guess. And I've also been there many times, but it's fun. Like when you go somewhere new to just like, uh, look around and, and figure out what's happening, even if all you're doing is like walking across the street to your, your big boy business meeting or something. But it's interesting to decode what's going on. Like, like one thing I picked up from Bruce Sterling that you can do if you need, uh, you need some structure to your, uh, looking around is check out the manhole covers, or I guess we would say person hole covers. And it's, it's often fun to like decode who the local utility providers are, like where the manhole, the covers are made, all sorts of things like that. Like if you were, uh, around here in Austin, wandering around, you'll notice that, uh, several of them say SBC Southern Bell communications, which, uh, you know, for, uh, the foot close followers of American business, uh, acquired, what did they acquire? What did it used to be before it was AT&T wireless Cigna, that's an insurance company. They had some funny name, but they acquired whatever the cell phone company is. And then they acquired AT&T and renamed themselves AT&T. So it was a, uh, I don't know. What would you call that? Reverse baby bell? I know you come to this podcast for the tech talk and stay for the telecom history. That's right. Yeah. What was, what was that? What was their mobile company called? I'm gonna have to go look that up now, but it wasn't. Hmm. Hmm. Anyways. Yeah. And then there's finally, so what I was just describing, I, I, our friend, uh, James governor at red monk, I'm sure I'll pronounce this wrong, but the, the act of being a flow near, which, which is just to see a place by aimlessly wandering around. That's what's good to do when you're on business travel. That's right. So, uh, there's your, your French. And as you say, telco history for this week, let me check that off the list. So, uh, we don't have a guest this week. So we were thinking we would, uh, in, in our, our second half, we'd go over some, a sort

of, uh, frequently asked questions and, and also, uh, cut by interesting to us questions that, that we get at the end there. But first, as always, there's some news that we have. So we had a, uh, a new version of pivotal cloud foundry come out version 2.1. And I noticed over there in Twitter that you were very excited about the windows stuff. I think you might've written a tweet like three or four times. Did that come through? No, it's fine. You're, you're the, you're the officially excited about windows person around here, which, which I think is good. But what's, let's start with that. What's, what's the windows stuff that's in there? Yeah. The windows stuff is supporting windows server containers, which kind of came out in windows server 2016. So you just got to get this first class support. And so I wrote up a blog post that just talked about how we can do some cool Boshi things with windows now. And if you're at a traditional enterprise, your options for running windows have not been great. And running windows is one thing, but running like app friendly windows, like it's ready to go for your app container that you can restart things without downtime. That just hasn't been a strong suit in most enterprises. So the fact that we can do that really cleanly now is pretty exciting. And then all the CF stuff just works that all the CF pushes and service brokers and SSH into a, you know, tunnel into a container is really cool. And being able to have metrics and logging. So just all the stuff you like from spring boot stuff is also cool for.net and windows stuff in PCF. So just a nice advance for those sorts of things and all different types of apps as well. So because it's using windows containers, you can bring your gnarly apps that use the windows registry or file system or things like that. So just a really nice update on top of some other stuff in PCF two, one, which had things like service instance sharing. So, Hey, you stand up a rabbit MQ in your space. Guess what? You can share that with other spaces now too, and everyone else can take advantage of your message bus. So a lot of nice little features made its way in. We also used Envoy, which is kind of some cool tech for sidecar in applications. We use that to actually do secure communication all the way down from that front router, all

the way down to the container. So we can have encrypted traffic. We can make sure it only goes to the right application instance, some really cool security things, application monitoring and all the window stuff, which apparently I'm excessively excited about. Well, you know, we, we, we talk about all the Java stuff incessantly too. So we got it. We got to make sure that, that the equally awesome windows world gets their due. That is important. Yeah. You know, I, uh, I've, I've, I've liked our, uh, at a meta layer. I've noticed that our release notes, uh, recently or release blogs have been like in, in a good way, insanely detailed, which is nice. I like that. Like I, I remember back speaking of Java back when I, uh, you know, had a real job programming. I was, I was always for some reason, really excited to read the eclipse release notes because they would always be like five or eight pages. And I mean, I guess I know why I was excited because I used it every day, all day, uh, to do all my wacky little programming. And it's fun to like discover the little tiny things in there from the giant parts of it to the little flourishes and stuff like that. So I still have that leftover that reading a detailed release notes is fun. And it's now in, in the app store, it's terrible. Cause they're just like, we're constantly updating this app to make it better. And it's such a letdown. That is the word, isn't it? Oh, like, Oh, Twitter updated to improve your experience. Did you just start tracking my movement? Like what did you add to the app? Yeah. There's a few, like the drafts app and, you know, I think there's probably a general rule that any app that supports Markdown probably has detailed release notes just because it's a programmer's doing it, but yeah, we'll put a link to there and there's, there's plenty of, uh, plenty of stuff overviewing there. And then just to throw out an abstract thing, I started reading, um, what the, uh, the DevOps report people, the door of people, they put out a new book that's sort of like the, uh, the science behind the DevOps reports. And it also goes over the stuff that they find there. And I, I've been, uh, I thought I got, I would get it on tape. I don't know if you've ever listened to, well, not on tape, you know what I mean? Uh, I don't know if you've ever listened to sort of like a technical book, the audio version,

but it's, I don't know if I have, it's kind of funny cause it'll, it, and especially an academic one because they'll cite authors and they'll be like, you know, uh, you should do Windows registry support, Sir Rotor 2015. And it's just a weird, like, it's a weird thing to hear, but it makes total sense. Anyways, uh, you know, one of the big things they've had in the DevOps report for a while is like, as they say, moving security to the left. And I, and I was thinking like, well, of course that makes sense because, you know, you want your stuff to be secure and it's, um, much like performance, like, uh, and also just QAing, it's going to like bring down, not even bring down, it's going to damage your system if you have bad security. And it, and it got me to wondering, like, I mean, like where is the line of stuff you should move to the left? Like in theory, the next thing's going to be like audit and compliance and you should probably move that to the left and then on and on and on. And, and because I always think it was weird that security is in there, uh, just because it kind of doesn't fit with the other stuff, but I take, uh, you know, what it is I take they mean with security is like the developers should write secure code. That would be a good idea. And I'm being a little snarky in the phrasing, but there's a whole host of things that I don't think developers really pay attention to that eventually needs to shift over to the left there. Yeah, that's fair. So I don't know. I just saw the security part of the release notes and it reminded me of that, but that's, that's maybe, maybe in 2022, the Dora report will say auditing shifts to the left. That'll be fun. Well, also, yeah, I'll also, uh, I didn't notice this, but you pointed out that, uh, maybe like a week or two after acquiring a MuleSoft that Salesforce has an integration cloud. I think, I think, do they call that an iPaaS? That'd be very exciting. Yeah, it's a good question. They didn't label it that way. I mean, obviously that tells you some of this stuff was in the works for a bit and Salesforce

is a little bit notorious for announcing things before they're ready, but this does feel like it's a pretty interesting piece. They've got a few pieces in the link we, uh, we have in the show notes about different parts of an integration builder to kind of just construct, I think the integrations of a platform for running some of the pieces and things like that. So it makes sense that they're getting harder and deeper into this integration game. Again, it'll be interesting to see how it impacts their community as a whole, since everybody else likes to integrate with Salesforce too. Yep. And then similarly in big vendor announcements, Oracle had a, uh, I haven't, I haven't found the release notes on this. Not that I would know what to do with them, but it sounds like they've got a lot more automation into their, uh, their data warehousing and, and have a, uh, a hosted cloud version of it. And I was reading another, uh, some, uh, some coverage over on geek wire, which as, as I'll probably say all year, just to get people to read it is has become a surprisingly good source for tech news. I mean, surprisingly, cause I'd never heard of it apart from five months ago or so. Uh, and, uh, you know, they, they were, they were saying that the, uh, there was a bit of the tone of the announcement that like, well, while we may not be able to do great at the infrastructure as a service area, we, we should be able to do very well at the, uh, at the database. And, and I don't know what, what that layer would be called. I'm going to have to go look up my Gartner taxonomy to see where, where databases and things like that fit in. But it does seem, uh, I don't know. Yeah. It'll be interesting to see how, how that stuff pans out just because, um, you know, everyone uses Oracle and they also have, uh, my, my, my. Sequel in there, which, which is, uh, fascinating to look at. And then, and then also, uh, there was, there was some perhaps related news that they're opening a new campus here in Austin. It looked like it was downtown and, uh, they got around just over 2000 people now. And, and they said, uh, there'll be, there'll be filling it out to 10,000. I didn't read a timeline for that, but that's a lot of people, uh, especially to be in downtown there. We're going to build another lane on the highway. Although, you know, it evoked in me a little old guy, uh, sentiment.

Which usually tech companies are very excited about being downtown, we're downtown USA. And, and in here they were writing about how, uh, you know, there's lots of workers who could, uh, walk or bicycle into work and me not living downtown. I always think, uh, I don't want to go downtown. You got to find parking, things like that. But now that said, I am always trying to hustle up a downtown job so that someone else pays for a full-time parking space. But thus far in my 20 plus years of employment, that has never panned out. So, uh, all it takes is one parking spot downtown and I'll turn the ship around. Be all about a downtown office. Yeah, that's, uh, that's good. Well, for all those 10,000 people, I guess it takes a lot of people to run an autonomous data warehouse. So it's not all, it's not all robots, but it's like some cool tech that they're working on there. And Oracle can overcome some of their kind of brand challenge. Sometimes it seems like there's still a lot of really smart engineering happening there. Yeah. Yeah. I mean, I mean, that's, uh, the technology they work on is not easy. So there's definitely technical smarts over there. Uh, and then, and then also last week, the, uh, Solomon over at Docker, I think he's been at Docker and then dot cloud for like 10 years or so. So it looks like he's finally pulling away a little bit instead of being the, I forget if he was the CTO or the chief product officer or something like that. But I think he's, he's, as it said, it's still on like the board and involved, but it is like, you know, we don't often call out individuals, but that, that dude has certainly been a, uh, a huge part of the overall cloud native world, uh, figuring out how to, how to, how to make, as, as one article put it, a, uh, a relatively obscure part of the Linux operating system, like, like usable and, uh, and, and, you know, use not only usable, but, but extremely helpful for everyone in the form of Docker and whatever the names are now, it's definitely, uh, been, been an extremely important piece of technology. No doubt. I mean, that's, uh, I've said people can argue all containers have been around forever

and this and that, but it misses the point that he solved the packaging and usability challenge for a lot of people to, to use the tech and, you know, Docker, the business, I think it remains to be seen how they're going to monetize open source. That's a hard problem for a lot of companies. And, you know, he was always an interesting character in the space, but man, you, you really tip your cat cap to someone who really changed the course of software development for a lot of companies and teams. So huge props, you know, sometimes the team you start with, isn't the team you can scale with. And that's why founders leave and things like that. But, you know, hopefully everyone stops to reflect on, you know, a big impact and whatever he does next, people will pay attention to. Yeah. Yeah. Also 10 years through two different companies, man, I think I would last maybe like seven months. That's, that's, that's, that's a lot of like, uh, as, as, uh, as our buddy, Andrew Schaefer likes to say, Hmm, that sounds dangerously close to real work. So, yeah, but, uh, you know, we, we had a longer discussion of it over on, uh, my other podcast software to find talk episode one eight, one 28, if you want to go check it out, I was thinking about it and I sort of probably came off sounding a bit jerkish, but that's the tone of the podcast. I think, uh, I think there's, that's right. There's, there's more of a good discussion of what you were talking about. Like how, uh, as always like little topical new stuff like this is more of a string of an interesting sweater to unravel, unravel about how the, uh, how the teams and the needs evolve of a company over time, which related neither here nor there. And then also in the area of, uh, promotion. So, uh, one of our more frequent guests, Rita was, uh, I had her on my, uh, software to find interviews, uh, uh, podcast to talk about analyst relations and how it works and how she got into that. So it was just like, as I do on that podcast, just an interview about, uh, you know, partly about the person themselves and also the, the work or the topic area they're in. And I think, you know, it's, it's, uh, obviously it's a good episode, but, uh, she always has, uh, great conversations on this topic and an interesting point. So you can check out our show notes to see that.

And then, uh, uh, tonight I'm going up to Dallas for a two day SpringOne tour. So, I mean, it says it's sold out, but also you probably won't hear this until later on, but it'll be, uh, tomorrow. What is that? April 3rd and, uh, 4th. But then I noticed we have a whole passel of these going on. I, I, uh, I remembered, I was looking at my, uh, my teammates travel schedule and this is like all they're doing this year. Not all they're doing, but it's a huge part. So, uh, if you go to, uh, I think it's, uh, uh, spring tour.io, uh, and SpringOne tour.io, and you can check out all the cities like Denver and St. Louis, London, Los Angeles, New York. And then there's a whole lot more like Chicago and Istanbul. And of course, San Francisco, Tokyo, Seoul, and Beijing, Singapore, and Paris all throughout the rest of the year. So if you're, if you remember our, uh, cloud native roadshows from years past, I think I would call these like, uh, maybe like a degree more technical, although those were very technical last year, but you'll get to see all of the, uh, you know, your, your, your sort of spring boot talks and other technical talks and programming things about what are going on there. I think the idea is we bring SpringOne to you, uh, which people, there you go. Well, I think that's the big difference for these is this is almost like a mini conference with lots of talks versus one or two really smart people doing kind of lecture style all day. So hopefully it's a nice mix and a good energy in there. It seems like the first couple have been great. Um, yeah, I was asked to go up there to, uh, MC the event and run the open spaces. So we'll see if I get asked to do it again. I don't know. I, I'm not really sure how to MC something. What I've been telling myself is I should probably talk about seven eighths less than I do. That's probably the key to successful MCing. And, uh, yeah, to state the obvious. Well, anyways, uh, like I was mentioning, uh, I thought it'd be fun. To go over some, some frequently asked questions we have to sort of, uh, explain the idea.

And, uh, I don't know, grab the first one. I was, when I was, uh, in France a couple of weeks ago, um, uh, I, I went to several lecture sessions, as you say, sort of like I was there with, uh, someone at one of my teammates, Nate, and he would talk about a cloud native programming. And I would go through my usual, uh, how organizations are doing things. And, and it's, it's fun to catalog the questions that you get after, let's say 60 to 120 minutes talking about how to improve IT. Um, and there's one that I was asked, uh, at one of the places I was at that kind of put this idea in my head. And, uh, I, I, I rephrased it because of course a French person was asking it. They were always very timid about speaking English, but I tried to tell them your English is fine. And the secret of, of native English speakers is we just make up everything as we go along. It's not like it was, it's not like we're speaking. We know some perfect grammar. I don't even know what grammar is. We just, uh, that that's something that they don't teach you in like, uh, middle school and junior, junior high English that what your English teacher should do is take everyone inside and be like, Hey, by the way, you can totally make up anything you want. Like that's, that's, that's a, that's a major feature of the English language. But anyways, I rephrased the question. And, uh, they, he was asking basically when you're trying to do your digital transformation or whatever, like, what do you do with like grumpy people? Like people who don't want to change and, uh, they, they're very resistant to moving away from, you know, the six or nine months release cycles with the siloed mindset and communicating through tickets and, you know, all just your, your, your, um, a straw person of your worst case scenario. And, you know, I think as I recall, I came up with essentially there's like three things that I've seen people do when they need to, uh, deal with grumpy people, resistors, I guess. And, and usually specifically this question is about like individual people who are resistors,

not like, you know, management or organizations or things like that. Like that's a whole other different, uh, topic, but you have these individuals. And the first thing, uh, I think I'd given myself a lecture, uh, earlier in the week that I should try to be a positive person instead of being so negative. So I started off with that one, which is, you know, there's, there's sort of a, uh, an emphasis in the, in the devopsy world and the agile world to build up sort of empathy and understanding. And so one of the things I've noticed recurring when I hear stories about, uh, turning frowns upside down on grumpy people is to like, try to apply some of that thinking and think about why are they grumpy and resistant? Right. Like, and if, if they're probably our age or older, they've been through like two to five waves of how everything is going to be more awesome. And they might even have some old printout of their like six Sigma black belt or whatever from whatever industry they're in. And then here we are again, telling them they need to change again. And you get sort of like, uh, improvement fatigue. And then even more so, like it's often the case, uh, definitely not in any company we currently have ever worked for or any of our customers, but other people where the organization sort of just like betrays people over time, sort of sets them up for failure. Like we're going to do this fun new thing and not, not fun, but we're going to do something in a fantastic new way. And then for some reason, uh, you know, people end up getting punished or blamed when things don't go well. So I think it's good to sort of like understand the source of the grumpiness and then you can try to, uh, do something about that and, and when people over to it, instead of just sort of like, uh, writing them off as someone who's grumpy, like they might have a very good reason and, uh, it's, it's good to go in there and figure it out. And then the second thing that I've noticed people doing is, uh, uh, and, and it goes back to the, the magic of pairing and pair programming. And I remember I recorded a tiny little monologue about this somewhere on the internet, but, um,

on one of these cloud native roadshow tours of all places, uh, we were in, um, Kansas city, I think, and some Garmin people had come there to give, give a bit of a talk. And they were saying, well, they had a question about pair programming and, uh, especially what happens when senior people are not interested in it. And they had an interesting story that, um, a lot of senior people are sort of insulted by getting paired, not a lot, but some senior people are insulted with getting paired with a junior person. And, uh, you know, so they object to it, but they were noting that what they observed with a lot of their senior people was that, uh, usually by virtue of being senior, this person is good at problem solving and coding. So they're, they, they're a helpful worker, but that usually means in the world of software that they spend all their time diagnosing, you know, giant problems and explosions. So they're sort of like the, uh, the wizard on the hill that can solve all of your issues. So they don't really spend a lot of time programming anymore. They're always debugging things and figuring out why production is down and stuff like that. And they were saying that there were some of these senior people and, uh, and then they're also harried and grumpy, um, and, uh, that once they started pair programming with people, they remembered that they like programming and they got back to like actually being able to program instead of pouring through log files and things like that. So that was, that was another thing that like to get over grumpy people is it's a bit of like a lame answer because the answer is like, well, just make them do the process, but at least it's sort of a tool that you have at your disposal. And then finally, the answer that is, uh, don't solve the problem. Like there's, there's several organizations, uh, of our customers that I've talked with. And, and you see this pattern over and over again, or part of this pattern where they, they set up a new organization and they might call it like a labs, or if they're all state, they come up with their own name for it. And, um, like I was talking with a Duke energy person a while ago and they're buying, you know, an old red brick building in downtown Charlotte.

So they set up a separate organization and one of the consequences you have of this is it's sort of a passive aggressive thing is you tend to take volunteers to go into the new organization. So you sort of bring over, uh, the people who are interested on it. And as a, you know, I think passive aggressive management is typically a bad idea, but so whether it's a good idea or not, one of the side effects you get is that if someone's not interested in changing or doing things in the new way, they just stay over in the old organization doing things in the old way. But the summary of all of that is like, you either have to, uh, convert the grumpy people over by understanding why they're grumpy or maybe letting them experience a new thing or in some way, uh, not invite them to the party and let them, let them, uh, remain in what it is they're comfortable with and in what they want to do. So that's good. That's, that's one question I get frequently. And then I'll just add one more thing that it's fun to, uh, when you're in Europe and I imagine other places where, where unions are extremely strong and you can't really, uh, uh, tell people that they don't work with you anymore. There's always, uh, that adds another wrinkle to the puzzle. Like if you're talking with government people and, uh, and others, like sometimes you don't really have a lot of choice about the assignment that you give people and, uh, like if you want to employ them or not and things like that. So it makes it a more wicked problem to deal with. So how about yourself? What's, what's the first one, the question you get a lot? Well, I want to poke at you on that one for a second. Um, so yeah, that was, that was good. From my experience, it kind of echoes you, you invest in people, then sometimes you have to isolate them if they're just not going to work. And then, you know, at some point, again, assuming you're able to, sometimes it just doesn't make sense for that person to be there anymore. And yet you, like you say, you first have to understand things and hopefully invest in that works. And sometimes you have to carve them off or keep them in the old team while the new team innovates. But gosh, I just haven't seen a whole lot of transformations that don't involve some turnover because some people just don't want to wear a pager or some people don't want

to work in balanced teams or, you know what, they've had one change too many and they're just burnt out and you understand that. So I think we have to sometimes recognize the fact that some people just aren't a fit for the current transformation, even if they're burned out. But hopefully, as you say, you re, you re-engage your passion by realizing what you were trying to do in the first place, which was build cool tech to solve neat problems. Yeah. Well, that seems to work. Yeah. That reminds me of two little anecdotes that I think fit well with that. One is, I think, I forget where I, I'm sure I've written this up somewhere, but there's one of my, a vignette I have somewhere where, like, I remember I had talked with some management at some organization who was about like, uh, a year into doing all their cloud native stuff. And, uh, we, we were, we were talking in a big room with lots of people about this issue and everything was fine. And then, and then as I was leaving, like he was walking, this person was walking me out. We were, we were literally in the parking garage. Like we're in some spy movie and he was like, Hey, Oh yeah. Also, uh, you know, the turnover is really high. Like I, he was like, I didn't want to talk about that very much, but like, yeah, I had to get, I had to transition a lot of people out of my organization because they were very resistant to it. So you do hear like that, uh, to your point, there's some people who just, uh, I don't know, they, they, they don't want to convert over after all these efforts to do it. And then there's another one. I need to go look up, uh, which talk this is, but the, uh, well, I know which talk it is there, the, um, there was a talk at SpringOne platform, uh, that, that I was helping out with and it was called navigating the, uh, the no. And I think, I think there's a, there's an interview with, with this, uh, with this guy, John, um, on our, our, would it be brother or sister podcast over there on pivotal insights. But he has an interesting point about team composition is that when you're putting your team together, uh, you don't want to necessarily get all the, as people would say, rock stars

or whatever. And, and in fact, you want to have some people who are these T I'm, I'm putting these terms into, into air quotes to kind of prove the point who are these ninjas or rock stars or whatever, but a very, you want to have a very small amount of those. And you just want to have like regular people on the team as well, because as you get successful with your initial projects, you want to eliminate the, uh, the counter argument for when you want to scale it up and spread to the rest of the organization that like, well, sure. If we had a team of rock stars, we could do that. But we just have these normals, uh, which both of those are kind of poor ways of thinking about people, but it's a good point that you want to not overskill your initial teams so that it's believable that it's possible to scale the, uh, the teams out. So there's some poking at myself there. There you go. All right. So what's mine. So the one I was going to, you know, I'm actually talking about this week with some customers in person, but we got that question of like, how do you know you're actually getting better at this? It's just not, I mean, to you, what we just talked about with, you know, people pairing and getting back to work and kind of working in these new units, you know, how does that CIO go back after the next year and go, Hey, we just doubled our IT budget. It wasn't worth it. And I actually spent way too much time going through analyst research on this. And it's surprisingly light in terms of like analysts saying like, Hey, here's some hard metrics, not just like, Hey, it should be, you know, throughput's a little better, like, you know, outcomes, but very not much that you could checklist and say, okay, here's five metrics I care about. So pivotal does, I think a pretty good job on that. We talk about delivery speed and patch windows and how quick you're patching and improving cycle time. And so there's a number of things we track about how, you know, you're getting better at software, but it's surprisingly not talked about a lot industry wise as I can tell, which is weird because we're asking companies to spend a fortune more in it than they were before for this hope of like, maybe everyone's happier versus what are those real outcomes and measurable outcomes that you're achieving?

I don't know what you see there, Coté, do you kind of hit on the same things that pivotal likes to talk about, or are you seeing people ask about actually, Hey, prove to me we got better. I think, I think that, uh, well, there's two things. One, you let's, let's, let's, let's incorrectly call this metrics, like, like management metrics, like how, like you say, like, how do I know this is working? And, and then, and then the part of the problem with calling it metrics is it gets lumped into project management metrics. And so a lot of the times when this question is asked, it's like, Oh, we're going to do all this crazy agile cloud native DevOps stuff. Like what metrics do I track? And I think the way you phrase it is more of the, uh, the right question. I try to always avoid being the person who's like, that's the wrong question to be asking. Now, let me enlighten you with the right question. Cause that I find that annoying when it happens to me. I'm always like, I don't care if it's the wrong question. Why don't you first give me the answer and then not talk after that. But anyways, uh, yeah, it is, it is a question of like, how do we know this is working and that we're getting better, uh, and that we're improving. And I think, I don't know, like, like there's all sorts of, the problem is you, it's easy to derive these metrics of like what your, uh, your lead time is, or like, you know, how, how frequently you can deploy and how, how, um, what your, um, what your failure rate is. And, and then of course, like if you're all like new age operations person, who cares what the failure rate is, what matters is how fast you recover from the failure rate, but all of those things kind of to your point, like it just begs the question of like, well, in the service of what, and I think, I think that's why this answer doesn't exist very much because more or less every single, maybe not every single application, but pretty much every organization has a different question, answer to that. Right. And cause like, if you're a business, it's like in the service of making money. Right.

And so like, whatever it is, your software process is, if you're happy with the business results you have, your software process is working well. And, and it's only like, it's only working poorly if for some reason you don't get good, uh, business results on the, on the other end. And, and similarly, like government's a little different, right? Like in that case, it's usually about, uh, well, two things, one of them is sort of like the, uh, optimistic thing, which is how well are we satisfying whatever mission or process that we have? Like, uh, you know, in immigration, you have like case management and how, how well are we solving case management problems? Does it, is it really quick or really slow? Um, and it's in our software helping with that. And then in other part, you know, the other, the other thing that government people always want is, is they always put it to, to a person, they put it this way. They say, I don't want to be in front of Congress. And so, so, so that's the other, and, and put, I think, I think in Mark Schwartz's, who was a CIO of one of the, uh, the immigration bureaus, how he put it was, um, at least, and I assume it's like this in other governments, but one of the metrics, uh, that's very important in the U S government is basically accountability and oversight. And in the same way that a business, what's important is making money. What we've decided as a society in the U S is that, and this is me rewording it is we basically don't trust government projects. So we always want to make sure that their money is being spent well and there's good oversight. And so that's sort of like the first story card we, the citizens always have with the government project is like oversight user would like oversight into the creation of this software, um, which, you know, that becomes a very real metric. Like, how do you know, how do you know if you're doing your transformation is doing well? And it's, it's basically cause we have all this oversight stuff generated, which can seem

terrible, but that's part of the delivery essentially. So that's a, as, as I told the, these French people I gave this answer to the longer my answer, the less I actually know what the answer is. Well, I mean, to your point though, how do you, how do you differentiate causality versus kind of, I don't know, causation, this sort of like, Hey, we got better. So therefore that must mean software got better. Like, I don't know, maybe you just hit a hit product and your it is still a disaster. So how did I actually attribute our change in software to actual better business outcomes? There's no way to say, there's no perfect equation. It's just, it doesn't feel like we put enough discipline into linking those two things. And people, again, I think with value stream mapping and a number of other things we do are trying to help that the only thing that really matters is outcomes here. Technology is a, a means to an end. So I don't know. I like that people are asking those questions. That's why I put it on the list as we're seeing that asked more and more. I think we can all as an industry do a lot better at actually tying this together. Yeah. That reminds me of another Mark Schwartz thing where he was saying, um, you know, in this realm we're talking about of causation, it is in one of the most precarious positions as far as like blame storming in the sense that if the business side is not doing well or, or their ideas were bad or business execute is, is, is business execution is bad. No amount of awesomeness on the it side is going to make up for the fact that the business fails. And then it's easy to sort of like scapegoat to it and be like, Oh, those it people, they were like late or, you know, this thing happened or whatever. And so it is, uh, it's kind of that reverse halo effect that if things go poorly, everyone assumes that, uh, you were doing things wrong when in fact, you know, maybe it was just a bad idea to, uh, you know, I don't know, airlift oatmeal to like the, you know, the, uh, where am I going with this to have a business that like airlifts hot made French oatmeal to the

Arctic. Like that was just a bad idea, even though you could, even though you could put in multiple release features every day and, uh, you could do that well. So that, uh, that becomes a little dicey there. All right. Well, uh, another question that I get, uh, frequently is, um, this is another one that doesn't have a good answer, but I always like the ones that, uh, the answer to the question are basically like, yes, you're right. This is hard, which is a good example of this. Like I remember, I was talking with a, um, uh, what were they like, uh, like a healthcare related company, uh, a while ago. And, uh, I, I had given my talk as I often do, or pretty much always do. And then one of the questions afterwards was, uh, it was from what seemed like a very cheerful, but sort of like somewhat beleaguered project manager. And they were saying, all right, well, I have this project that we have to deliver by, I'm making up these things by October, uh, 2019. And it involves integrating five backend data sources, you know, two of which are on a main frame and no one remembers how to do the COBOL. And, uh, and then, and then also we have to work with a brand new mobile application. And then also we need to integrate with our ERP, uh, service. And then we also have like a third party that's doing something on top of that. So how would I apply all this cloud native stuff? And, and like, this is, you know, I kind of amalgamated a bunch of those, those questions in there. Um, and I don't know, this is a question that comes up every now and then, and like I was alluding to, oftentimes the answer to this is like, the short answer is like, yep, well, it sounds like you're doing the right thing. That's just like, that's a crazy complicated project. And there's complicated projects with huge dependencies and teams that are not all behaving the same. And you don't have like the two to three years it would take to get them all on board and

all acting the same way and get your balance team. So you're going to have to spend a lot of time like managing the dependencies and doing all of that. And of course the sort of fallback from that is, you know, you still want to, uh, look at all the various parties and teams involved and figure out where you can do things in a more like, uh, you know, agile devopsy cloud native way where you can have those, those balanced teams working with each other and be deploying multiple times a week and things like that and how they integrate with each other. But I think especially in, well, yeah, especially in large organizations, this problem comes up and it's also, I think it points to, uh, the need to still have people who are product man, project managers and enterprise architects and all these overseeing roles. And I think, I think what should be happening with those roles is not that they don't do this necessarily, but they have to be a lot more active in managing and programming that overall process than just tracking, than only tracking what the status is and, you know, wrangling up all the meetings. There's a lot more, uh, getting your hands dirty to run things there. But I get, that's why I think in large organizations, management and all these ancillary things to the actual product teams are, uh, more or less as important as they've ever been. They, they just need to bring on a new type of, uh, of, of thinking about programming the organization than, than they, they usually have. Yeah. That's a good one. I mean, if everything was greenfield, life would be too easy. So in this case, you, you think about horror, you know, how do you do vertical slicing across these systems and ship incremental value? And there's at least some patterns for how you modernize and how you decompose these kind of giant systems. But yeah, no, there's no easy button there. Yeah. Yeah. You know, you can't just sort of say like strangler pattern and then leave the room in a puff of smoke. I just, I think of that Homer Simpson animated GIF where he just walks back into the bush and

just kind of just, exactly. I don't want to even focus on this. Let me just step away. Yep. Yep. That's right. And then the one, the one where a grandpa walks in and puts his hat on the hat rack and then sees, I guess, Bart there and then picks his hat and then walks right back out. Yep. That's great. We could just do a whole podcast of Simpson. I think, I think we've just come up with a good ignite presentation right there. A good little five minute talk. That's perfect. Perfect. So yeah, my other one I thought I'd ask is, you know, or I get asked a fair bit, especially in my marketing role is, Hey, can you give us a summary of customers in industry X? That does come up all the time. And what's interesting is I want to ensure we have, I mean, Pivotal has some, some enviable case studies across virtually just every vertical you can come up with, but, and you see this as well. And I think I see this in our user group is that like people are breaking out of their vertical. Like it's not like insurance people all hang out, but you'll hear, you know, a Home Depot talks to Allstate who talks to a media company who talks to a telco who talks to a government and that, you know, everyone is solving different scenarios in a lot of the same way. So if you're a bank and you're worried about data privacy, you know what? The same scenario may be applicable in a retail environment. Yes. The stakes may be a little different, but I'm seeing more common solution patterns that span verticals, which I think is great when you have kind of tech web companies who can share information with the government. Like that's really exciting stuff. So while we'll answer it industry by industry, I actually like more and more when we just point out, here's the scenario you're solving around mobile app development or streaming data analysis or, you know, secure data transfer across boundaries, whatever those problems are. I'd like that. We're actually spanning industries more. So I prefer we do that versus just, here's a great banking story. Yeah, no, I think that's a good one. Cause that does come up all the time. And I have to maybe breaking my rule of telling people they're asking the wrong question. Like, you know, obviously it's good to answer with like, here's, here's how people in your

industry have done stuff. But kind of like you're saying, my observation has been that it's when you, when you're doing your, your software development and whatever you call that, your, your life cycle stuff, like every organization kind of has the same problems, like, and, and, and the same thing. So like you're saying, like everyone needs to securely transmit data from, or data from point A to point B. It doesn't really matter what industry you're in. Like you might be in some, you know, in the military and have some exotically named like standard you have to satisfy, but you look through that and it's basically like, don't do dumb stuff. So there might be like specific things you need to apply to, but I find that like, uh, I don't know, like the problems that people have are pretty universal. And again, there's some, there's some edge cases. Like if you're doing industrial equipment, then there's some things that are a little different about your, uh, your internet of things stuff and things like that. But yeah, they all, uh, they all are kind of the same. And it reminds me of two or at least one anecdote. I luckily, I don't remember who this is because I'm sure they didn't want their, their name used or whatever. But I remember there was one, one organization we were talking with and, uh, we kept telling them about people in their industry. Of course, who are all our customers and how they were six, you know, how they were succeeding with us. And therefore, because your industry peers are doing this, you should be doing it. And I remember the, the person cleverly replied, like, I don't want to know what my peers are doing because I'm trying to like compete with all the other companies who are like trying to disrupt our industry and enter our industry. So I want to know what, you know, all the, the four and the FANG people and all these interesting new companies who are approaching our business with, with the tech bases are doing. Cause if I was just competing with the people in my industry, that's not going to do anything. Like I have to come up with something brand new. No, I mean, you get inspiration from all kinds of places. So I'm glad folks are inspiring each other across, across business types.

So, so then the last one that I'll go over, uh, is, uh, so another thing that comes up all the time is, uh, and, and this is admittedly one I should probably, uh, research more. Maybe we should get like, uh, Elizabeth on who's written several books on QA to talk about this, but I'm often asked by QA people, what, what happens to QA? Uh, and when you have like this, uh, this sort of, you know, balanced team with all the roles, the designer and the, uh, the, the developers and the product manager, uh, where, where the role of, of QA goes to, and I guess they're kind of like leading the witness by saying goes to, um, and I think, I think the, the, what I generally see, and then, and like I said, I need to figure out a lot more what actually happens and talk with more people on this. But the first thing that I noticed is that one, just like you expect your system administrators to actually start programming more, uh, like the QA people, the expectation is that if they're not already programming a lot to, to run their tests and maybe even instrument things in the application, so it's easier tested, more easily testable and make sure that their builds and continue or continuous integration, uh, have testing, then that's probably a good skill for QA people to pick up. I mean, and that's, that's sort of like the, I don't know. I feel like that's the ultimate end game for a lot of what happens on these product teams is it's not so much that everyone becomes a programmer. It's that everyone is familiar with all of the types of work needed to do on, on the, uh, on, on the product. So you sort of shift more towards being a generalist than a specialist. And so a consequence of that is for programmers is you should probably know how production works and operations a lot more. And a consequence for QA people is you should probably know how to program a little bit more. Um, so that, that tends to happen or, or, you know, I sort of hear about that happening.

And then the other thing that it's sort of like my dealing with grumpy people, like it's always been my observation, uh, when I was a programmer that the, the people who know the software, the best are often the QA people. Cause they usually have been there the longest cause they're not like these flighty, like developers who are always just bouncing around. Uh, and they usually have been through the, the software for several release cycles. And then also it's their job to know exactly everything about how the software is supposed to operate and, and therefore like what, what users will be doing it and understand it. And so they often have like a huge trove of knowledge, just sort of that, uh, what do you call that kind of knowledge? Not, not tribal knowledge, but I guess that's a metaphor for institutional knowledge. There you go. They have, they have excellent institutional knowledge about the software, which is definitely you don't want to, uh, lose out on. And then, you know, the product manager of the team and the designers would probably find them extremely useful to talk to about what the software does, who the users are and things like that. That's where we don't want to be lazy with these DevOps definitions. It's not saying get rid of QA or get, you know, make every tester a programmer or make lots of people learn, I mean, I can say it's more about awareness and like the QA skillset is super important. And Jeff Sussner wrote a great book on quality. And a lot of times this is just about making QA people raise their game a little bit to focus on total quality. And so you do need more awareness. You're thinking not just how do I write the 400 page test spec, but how am I making sure the customer experience is great as it spans all the different components? And I still need that skill on my team, even if developers are also maybe pairing with them and doing unit testing together or integration testing. So again, we were not trying to destroy every specialist skill. You're just saying you need some generalist ability as well. Yeah, absolutely. Well, uh, I, I think, I think that's good. Those are some, uh, I like, I like the, uh, the questions you had there. Those, those are good ones to think about, especially, especially the, uh, tell me more about people in my industry.

That's, that's always a fun one. So, uh, well, as always, thanks for listening. This has been Pivotal Conversations. If you want to, uh, find this episode and, uh, see all of our wonderful back catalog of things. I mean, you know, Springs here, you might going to be spending more time outside, need some stuff to stick in your ears as you jog around, or maybe you bicycle, or maybe you're like me and you don't do anything, but you still want to listen to stuff. You can go to sound, you can go to soundcloud.com slash Pivotal Conversations and find the RSS feed there and, you know, all that stuff. And then also every, uh, Thursday, usually we will, we post the full show notes over at, uh, pivotal.io slash podcast. And I'll put links to all the, uh, the stuff that we mentioned over there. Uh, and you know, hopefully we'll, we'll see you at one of those SpringOne tours, or, or at least we'll talk to you next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.