The Middle-management Bind

Episode 102 · 56:08 · SRT · archive.org · all Tanzu Talk

Hey, so your book's been out for like a month, right, Richard? It has. Yeah? Yeah. Are you five stars all the way? Are you like circling around that four and a half star and you're like, who are these people? Clearly, everyone likes it except this one person. Yeah, so far it's a pivotal exclusive, so it's just download counts is what I'm checking out now and listening for random feedback. Oh, yeah. Huh. Huh. Have you seen, have you found this character, Johnny Legion, who's downloaded it yet? I love your alternate persona. He's my favorite character. I need to look. I need to look at the raw numbers. I actually get a physical copy in two weeks at the Gartner show, so that'll be the first time I get to hold this masterpiece. You should save one for me. That's exciting. I have a copy of Nate Schuda's book here that I haven't read yet, so I could get a copy of yours and not read it, too, and add it to my collection. That's when I know I've made it. Yeah. I think once we get those books at the booths and tables, they'll just, I don't know why hot cakes fly, but they'll fly off the shelf like hot cakes, but people will love that. It'll fill a solid hole. Now, what image did you pick for the cover? How does that go? You know, it's funny. People have asked me that. Since I think it's one of these sponsored books, and it's not a giant book. It's like 100 pages. I didn't get an animal. I got like a picture. Yeah, yeah. You get like a black and white picture that's like, I wouldn't call it. It's not like a 40s. It's more like maybe a early 80s style black and white picture, if I remember all of them, right? Like it's kind of pre-smartphone industrial, I think you might. So at least this one was my suggestion they actually took, which was a building with a bunch of scaffolding around it, because it's modernization. So, you know, it was that or get a sea otter. And I guess I'll take the... Did you say a sea otter? Yeah, that could have been my animal. That would have been my choice. That would be great. Like the two sea otters holding hands. Yeah, sounds good. All right. Well, I wasn't expecting that.

Well, also, it's been a while since we recorded, as always. I don't know. I have all the usual excuses. I know none of it's your fault. It's just me. I just travel around a lot. It's great for podcast scheduling. But there's been some gigantic news. It looks like IBM is buying our friends over at Red Hat. That's some exciting consolidation going on. We recorded a couple episodes ago on my other podcast, Software Defined Talk. Episode 153, if you've got your pen and paper out and you're writing this down, there's a lot more babbling commentary from that. As I think the title of that, it summarizes my commentary. I don't know anything about this topic, so I'm going to go on and talk for a long time. It's a much more concise topic. But there you go. Consolidation. I think that's supposed to close like next year sometimes. So it'll be official. Right. And then, yeah, of course, you had VMware declaring they were intent to acquire Heptio. Oh, yeah. That's right. During VMworld a couple weeks back. And that was so it's kind of Kubernetes land, lots of stuff going on, which would have been fascinating three years ago if you had said you'd see this massive $34 billion merger somehow on the backs of Kubernetes or VMware dropping untold millions to acquire a Kubernetes-based startup. You would have been laughed out of the room a few years ago. But now, clearly, infrastructure companies get infrastructure. That's right. That's right. And then also, like I just noticed this over the weekend, there's going to be a new CEO at Google Cloud, right? So Diane Green. And she had a good, I think a good, I don't know the exact quote. I'll have to find it for the show notes. But there was a good summary from herself of what happened during her 10-year and how she helped out, which I think was, to summarize, it was basically like a handful of sort of like smaller companies and startups. And now I think they have usage, which is to say penetration across like all the Fortune 500. So she helped out, I'm sure, along with many other people, like growing a lot of momentum around that business.

And then you have, how do you say his last name? Thomas Kurian, I think, who had just departed Oracle. And I think he was the head of what part? Maybe he was the head of like all the non-application stuff of like cloud. Maybe not database, but all their cloud stuff. And then I think they said Diane Green is going to rotate up to the board and I think serve through the end of the year. And then he becomes the CEO. It's a very well-planned out transition there. Yeah. So that'll be, there's all sorts of changing dynamics. 2019. I guess you would call that CY 2019 since some people might be in their FY. But we'll see why all these people are emerging and whatnot in 2019. That's my really fraught calendar joke right there. Yeah. It's just funny how, I mean, next week, so next week I think it's re-invent. And again, also the Gartner show I'll be at. But it's just funny how many of these moves have a, you feel like there's the shadow looming of AWS among all of these. All right. I mean, Red Hat and IBM is arguably, you know, IBM's kind of waving the white flags and can we really win in cloud, even Red Hat potentially. And clearly even VMware buying Heptio. It's continuing to just own this sort of infrastructure layer that might span clouds because that's an important story now. Even the Google story, you can just wonder if some of this was because Google had a little trouble just kind of breaking over this next chasm of being relevant in the enterprise and you can't wait too long. So who knows? We're not sitting in their boardrooms making those decisions, but you can almost see this, you know, I don't know, eye of Sauron staring on all the different sectors that get freaked out and do mergers and acquisitions. Trying to grow ogres and trolls in a mucky pit. I think that's the other part of that, if I recall, right? And lots of dry cleaning and bleaching of white robes, also necessary in that environment. Well, also the, there's just a couple more things and then we'll bring our guest in.

I sort of rudely forgot to do that at the beginning, but what are you going to do? Just keep going the course, push through the paper. Also, I was just, I've had people ask me quite a bit recently for like recordings of the standard talk I give. So I made a few like talks on my own alone in my little house here. But there's also, I was at, I was at, this is Monday, I was at DevOps in Antwerp, just the main DevOps thing. And I finally gave a talk on enterprise architecture that I don't think it was terrible. And there's a recording of that as well. And I'll put these all in the show notes. And then when I was in Singapore that same week, last week, I gave, I gave like a new talk on like, you know, what is culture and DevOps culture? And more importantly, like, as I like to do, like what are tactics and things you can actually do? And hopefully, I think the Singapore people said they would put that recording up sometime soon. But I've organized all of this. I've used one of my absurd domain names for good, finally. So if you go to Coté.coffee slash better software, you can find all this stuff. And there's like, I got a 30 minute version of my little stump speech, and a 50 minute version. And then I have a 90 minute version, just for like, so you can fill whatever time you have, you know, if you got some empty time, you can fill it out. You could combine these together, see how they evolve. You could watch one, just two, three. There's lots of combinations. Maybe you could even splice them together. Anyways, they're available for enjoyment. Your media empire is continuing to impressively grow. And no, it's good for Thanksgiving this week if people have some downtime. Just really flip on their cootay dog. There you go. If you don't want to hang out with like Uncle Larry and Aunt Matilda, just be like, oh, I got to work. So much to be thankful for there. And then finally, something else came out I haven't had a chance to look at, but you were my notification system for it. I assume you've looked over a little bit.

What is that? I don't know. I have an irrational affection for the ThoughtWorks radar that comes out. I think it's quarterly, maybe bi-yearly or twice annual, however you're supposed to refer to that time period. So it's kind of a radar chart of technologies and platforms, tools, languages that you're supposed to care about, right? And ThoughtWorks is a, hey, smart company, keeps a good eye on the sector. And a lot of times this is a good way to look at kind of forward-looking tech. Like, hey, this isn't always stuff that you're going to use right now, but things that you should pay attention to. So it can be techniques like canary deployments. It can be things like, you know, how do I do infrastructure as code? Or what are things you should actually hold on? Like, hey, stop having microservices envy. Or, you know, doing complicated things with API gateways that you shouldn't. And so it's a really good list of, you know, dozens of things that you should pay attention to. And interestingly enough, even all the public clouds, things like Amazon, Azure, Google, are all even kind of demoted down to a trial mode just because all the competitors are decent right now. So saying you should just purely adopt one of the clouds as your sole platform isn't their recommendation, which was interesting. It's weird to see AWS in a trial category in this day and age, but they're doing it for that reason. But just lots of good things. So I'd encourage most of our listeners here to take a look at the radar, thoughtworks.com slash radar, and just see, look, these might be things that you want to pay attention to or even just keep an eye on. Because your customers, if you're a pivotal employee listening or probably looking at this stuff, and if you're in industry, these are things that may help you build better software. At least you should pay attention to them just in case they turn into something good. Yeah, it is fun. And then they have all the historic radars listed there as well. It's a good ongoing source that I think is free. I don't know if you've got a Johnny Legion yourself into it. No, it's a Johnny Legion. Oh, just Johnny no name. But it is. I like their visual, right? They've taken like a hype cycle or a wave and transformed it into like a vortex of innovation. Because as you sort of spiral down, I think the outside is basically like, you know, know how to spell it.

And then it's sort of like watch it and then figure it out and maybe trial or POC it. And then the middle is the adopt it and start using it. So I like a good vortex. A vortex is what happens in the southern hemisphere, right? Am I getting that right? Or no, that's like a hurricane versus a typhoon? I don't know. Yeah, a typhoon. There you go. I get it mixed up. I just love IT-based geometry. There are more quadrants and vortexes. It's great. Yeah. Great. Parabola. Well, why don't you introduce yourself, guest? Yeah. Introduce yourself. So I'm here in Seattle with Carl. Can you tell us who you are? Hey, my name is Carl Coriel Martin. And I'm currently a senior advisor on Josh McKenty's Systems Advisor Group, which is a relatively new formed team here at Pivotal. But you're a longtime pivot. You are hardly just recently recruited. So tell us a little bit about your long, tortured journey through the Pivotal halls. I would hardly describe it as torture. It turns out this whole be kind thing is real. Yeah. I first ran into Ian McFarland, who was a Pivotal Labs principal in 2009, when he and his partner were on vacation in Singapore. And a mutual friend introduced us and spent a day with them. And then in November of 2009, Rob and Ian and actually Elizabeth Hendrickson, who was not at Pivotal at the time, came out to Singapore. And they were looking at opening their first international office to service some potential Asian customers and spent some time talking with them. And 2009 joined Pivotal Labs. And April of – sorry, 2010 joined Labs. And April opened the Singapore office. And so I was the director of the Singapore office until we sold it to NEO. I went with SAIL. And then in 2014, left NEO and moved back to Seattle and worked again with now the new Pivotal to open the Seattle office.

So I was the director of the Seattle Pivotal Labs office for another two or so years and then got very interested in the travails, the opportunities to help our large, complex enterprise clients change behavior. And so I was quite happy to take a break from the office director role and focus on driving success, particularly the success that comes from our clients making lots of money by engaging with our tools and processes as patterns and practices. And a lot of that requires getting the business and the IT to actually collaborate on identifying valuable new opportunities and then building software and teams to exploit those opportunities. So what's the – so you mentioned the system advisory group. So you're a collection of superheroes based different parts of the country here in the U.S. What's the charter? Like what is that team supposed to accomplish? Help Josh McKenty scale? Yeah. So it was – his original name for the group was the Technosocial Systems Advisory Group. Rolls off the tongue. Rolls off the tongue. And I encouraged him to drop the Technosocial part because I didn't have an adequate supply of pocket protectors at the time. So there's a huge class of conversations that McKenty has been having with our complex clients. And a lot of that comes to – he calls himself sometimes the couch to get IT and business to talk together. And also there's a fair bit of just getting different groups inside Pivotal to talk together and manage escalations. And he was supporting like 35 accounts, which is a lot for a single human to manage. And so started building out a team to work with a – let's say the mid and senior leadership of our accounts and help them think about the execution strategy.

We've been really thinking a lot about right now this – calling it the conflicted middle or the middle management bind. Our engagements with our customers tends to put the middle of the hierarchy in a very stressful position where they're being asked to support the new behaviors that Lab is busy teaching to the delivery teams and cope with the limitations that Cloud Foundry adoption removes, which is awesome. And all of that is in service of these sort of larger strategic goals that their senior leadership have changed. The CEO and the CIO or CTO want new behavior. But their informal and formal contracts with their bosses and peers and sort of these complex network hierarchies is not changing. And so they quickly find that they're in conflict with their peers if they want to support these teams or their managers. And it's very hard to untangle those relationships and figure out what's a viable approach. And, you know, I've been – we've been doing a lot of strangler pattern conversations on the IT side of how do you sort of build a new system in place and incrementally move work from a legacy environment onto a new environment? And I've been really thinking about, like, what is the metaphor for human institutions? How do we do very small incremental changes from one org structure into a new org structure where we're able to always experiment and then roll back or test hypotheses and deploy in contrast to, like, big bang org redesigns where it's like, hey, and some of our customers every January, it's just chaos for six weeks because everybody's changing their managers and their team charter. And I want there to be less chaos and more just continuous incremental improvement and iterative improvement.

So what do those entwining things look like? I mean, you're trying to pull apart the spaghetti bowl back into a nice package, so to speak. But, like – well, and I'll ask it in a more naive way. It's like, so why don't you just change people's incentives and, like, get a bag of cash like Santa and kind of hand things out to make people change? That'd be lovely. It turns out there's a tremendous amount of paperwork that involves, in any organization, to get a bag of cash. So that is not easy. It doesn't just come from the frozen north? Right. Which I think is part of why cost takeout is a big part of many of our enterprise engagements. And so they're looking at the cost savings that come from migrating to the cloud and the just much more efficient use of infrastructure because that pays for the other activities we want to do. So it's like, okay, you know, where are we going to get this bag of cash? And then the other question is, change our incentives to what? And it's easier for a local individual to say, well, if my incentives were such and such, then I could support this behavior. But if we change that person's incentives, we also have to change the incentives of the people around them and around them. And so it's, I think, very hard for somebody who's sitting in the C-suite of our customers to say, like, this is how we need to change the incentives of everybody in the organization. Maybe this happens, and I just haven't seen it. But my hypothesis is that's a tremendously difficult design problem. And I suspect that if we spent six months or a year of study to say, we're going to understand your organization and sort of define a new incentive structure, that that would be out of date by the time we're done.

And it wouldn't have acted to move the ball. It would have just spent a bunch of money and lost a year of calendar time. Yeah, I don't think anyone's really come up with a generic, repeatable solution. Like, I read a lot of stuff, books and whatever else, on basically, like, corporate change management. And they're very long. And they have a lot of content and studies of, like, you know, compressed air companies. And I was reading one recently, and they talk about DEC, you know, D-E-C, which is kind of interesting and slightly relevant. But it is all of their change programs. And, of course, they all reference Alcoa, which is like, you know, I'm always pleased as punch to read the Alcoa change story for the 20th time, which is fine. But, like, yeah, none of them really seem to operate on a speed that sort of people are probably expecting, which makes me, you know, one of my, like, I always hate it when people reframe what you think the problem is because I just want people to solve my problem. But to do that, one of the things that I kind of fall back on is, like, maybe you should just have, like, lower expectations of, like, the time it will take, right? Like, it's not going to happen overnight, and you're not going to, like, transform a $5 billion business in a year and so forth and so on, right? And so, like, the thing that I've observed is, like, the smaller you start, the not faster, but the better chance you'll have at getting bigger and scaling up rather than just sort of, like, changing everything over. Yes. But can you play through for me? I mean, I know this whole switching from optimizing the cost to maybe optimizing for speed or any of that. I mean, play through something real life here. You can protect the names of the innocent with, you know, who companies. But, I mean, tell me about, talk us through some of these misalignments. Like, what's the thing that might be happening at the C-suite that then as you get down to some director of IT, they need to try to accomplish to make that thing happen?

And then some managers of dev teams get out of. So, I mean, talk to me about what starts the ball in the whack. Sure. So, one of the things that's really important for us when we talk about the improvements in throughput for a delivery team is they're able to make very fine-grained and high-quality decisions about scope. And, you know, I'm being sort of asked to implement this feature. How much gold do I plate onto that feature? How awesome does it need to be? How robust does it need to be? And if I have a really good sense of this is the customer that feature is serving and this is the business outcome that that feature is intended to realize, we as a team are in a very good position to make very good decisions about how much quality, how much scope to put into that feature. Now, if I am working for a manager who is then preparing reports for her manager, who is then preparing reports for his VP, who is then preparing reports for the board, saying, we funded this program. We want to know what percent complete it is. And, you know, I've been working in some of the aerospace sector for a while. And so there's a long history of government contracting tied into that. And you have sort of these, like, 4,000-page, like, RFPs with, like, all of the bullet points that this thing needs to implement and execute on. And so if you have the strong expectation of, I want to be knowing what percent done I am, and so I'll go, well, percent done of what exactly? How much scope is actually necessary to implement and take that off as done? It becomes very hard for people to communicate. It's like, well, you know, I can't tell you what this feature is supposed to do and what the business customer is. Like, I just got the spec sheet, and I want to know if it's done or not.

And the team is saying, well, I can implement that feature, but I can't help you with the situation of is it done or not, or how much quality should we bake into that unless I can understand who the user is. So this sort of desire to report, well, when is this thing going to be done and how complete is it, can be very stiff through the entire vertical of the organization. If everybody above the delivery team is saying, well, I want to know what percent completed is, it's like, well, percent of what? And that percent of what means that the chain is not thinking very deeply about the outcomes and who the users are and what that need is, and they're not giving the small team the tools they need to make scope decisions. So that's one example. I think another example that I run into is very commonly around performance management. It still surprises me. There are many companies that are asking their managers to grade people on curves, and that is in direct conflict with healthy team formation. Why? Because it means that you're competing with your people on the team. It's like, okay, Richard, only one of us is going to get the five. Right. It's going to be you or it's going to be me. How does that encourage collaboration? That's right. That's right. That's right. And I've pushed some really wonderful employees into labs offices that I've hired where they just couldn't get high-quality work because they were in competition with more senior engineers in their teams for high-quality work. Interesting. And then it's like, well, you know, this performance management system is designed to work for all of the employees in our 50,000-person organization. Why are you, little manager of this, like, 30-person org, special and different? It's like, oh, my goodness, you have to have a lot of conversations to change that. And yet, to some degree, pivotal, like, our value is we're going to deliver to these radically more effective product development teams.

We have to change that whole. But as you say, if I'm a senior manager and now I'm not only grading my team differently and I'm redefining what done means. That's right. Up to some manager above me who just has a line on a spreadsheet or a project plan or a funding plan, that creates a ton of stress. As you're saying, on that layer of people who are trying to sincerely introduce change. But that's a lot of pressure. Absolutely. And then it may not even be like, okay, like, I've sold my direct manager, but she now needs to go talk to all of her, like, finance business partners and HR business partners and say, like, these expectations that you're building into your spreadsheets, we need to change them. Um, I had a lovely conversation with a, um, uh, I think it was a, a shipping, a shipbuilding company. And, um, this, uh, VP director came up, uh, sorry, IT director came up to me and was like, how do you get your teams to not gold plate things? I was like, well, do they know who their users are? It's like, oh no, the business won't let us talk to the users. I was like, well, if the business needs to own that user relationship so they have control and you can't build a team that is a mix of the business people and the development people, the developers are never going to get good feedback as to who the customer is. And, um, as a programmer, like building awesome gold plated systems is bananas fun. Like I'm going to spend the extra two weeks making this thing awesome. So I'm proud of it. Um, if I don't have any feedback as to what good means. Now, those are three great points. Coté, you next. Well, I, uh, yeah, I have this uncharitable phrase that to myself is a cliche nowadays, which is like, you know, to put it in the family friendly version of it, like, you know, uh, you know, don't do dumb. Dumb stuff, right. Which, which, uh, is sort of like, well, of course, you know, if your developers aren't talking to your end users, you're going to get, I don't know, middling garbage, right? Like if you, if you're not sort of paying attention to the way people are using your software and feeding that back into the system, then, uh, logically it won't work out very well.

And, and unfortunately, a lot of the dumb stuff that people have to do is because they can't change it. Or the worst case, like the, um, I don't know, intellectually depressing thing is when the higher level executives are like, we have to transform and change and we're still going to stack rank everyone. And it's sort of like, uh, it's sort of like, you know, you, you don't think the system you currently have is effective and you want to change the current system. So the first step is to not change the current system, uh, or, or, you know, figure out how to change things around that much. Like I remember when I, I, you know, I've unfortunately been a manager several times in my career. I don't know if that's unfortunate for me or the people who worked for me, but man, stack ranking sessions are ridiculous. There's like that, there's like that, uh, one person over there with like a pile of paperwork and who used to be like, you know, I don't know, a captain in the army. And you're like, well, that person's going to win. Right. Like whoever's like organized the most and like, is the most aggressive and all that. Like it's a total like, uh, stuff show, so to speak. Um, yeah. And it, and it does, uh, it encourages hero culture, uh, which is not, not what you want in the IT world. So anyways, you know, Coté, for your example, you know, if, if I'm, if I'm a, a senior leader in this organization and I don't have a good model that describes the inputs and the outputs to the human dynamics of these product teams, which we still don't to say like, I'm going to change everything all at once. Like that feels bananas. Yeah. Yeah. Exactly. I want to do incremental experiments and like limit the number of control things. Yeah. And, you know, we're in this position of saying, well, stack ranking is obviously one of those things that you want to control. But on the other side of the table, I can see that that wouldn't be obvious at all because that may have worked and have very positive benefits. Yeah. I had a long conversation with Austin Vance, uh, who was the former labs director in Chicago, uh, now at Braintree. And he's like, well, here are six awesome things that organizations can get from stack ranking.

It encourages strong managers to take their good people and spread them across the organization. And so you don't get these like hotspots of talent. Yeah. And like, that is a, that is a delight design solution. And we can say like, is that what the organization wants? Right. But there, there are, you know, institutionally interesting reasons to, to argue for that. And so that is like, well, how do we, how do we design experiments or how do we quickly iterate through things to give leaders feedback and signal on this is a change that's going to drive the outcome you want. And this is not a change that's going to drive the outcome you want. Right, right. Exactly. Like, like you can't, you can't expect to, uh, people to, to intuitively, what's the word prima facie? They won't just believe the truth. If you show it in front of them, like some sort of like a Plato's cave, like that's not the way people work. Right. You've got to like put some system in place to make them, uh, believe in it and realize it on their own, which I think, I think, I mean, that's, that's over the years, that's been my observation of a huge, or I don't know what my observation means. Uh, what I've thought about a huge amount of always trying to change it is like, it's not like we have a good history in software development of being trustworthy or reliable, right? Like, like no matter, like, I don't know whose fault it is. That's been long lost to compilers and bugs and things like that. Uh, but it's just like, uh, yeah, we haven't been really great at being a reliable delivery mechanism, so to speak. And so it's kind of little wonder that the way most people think of it is we need a tremendous amount of process and, uh, I don't know, feelings of controls wrapped around it. So, yeah, I mean, like you're saying, it's almost like you have to, uh, I don't know, win back the trust by walking people through the system and, and very systematically not changing everything at once, but figuring out a way to win back that trust by having kind of a small series of changes that you walk through. Yeah. You sort of touched on the, like, is, is software development ready to be a professional engineering discipline?

And, uh, I think we aspire to be, but we have a long, a long way to go. And that is because we have inflicted so much harm on our business customers over the last year. That's, that's right. I mean, you know, there's a lot of horses that had to die to get electricity put in place, if I remember. And so, like, we, we got to exit the horse killing phase of, of technology. But I think, I think what, what, you know, it sounds like you're studying and, and, and you're hitting upon is like, it feels like when it comes to, let's call it professional software development as distinct from hobbyist or maybe even scientific is now the big challenges are not, not only scaling the technology, which is kind of fun, but really scaling the engineering practices and switching it over from something to, to be able to get to the point where you've got all these, as we would call them product teams, uh, sort of developing on their own. And, and, uh, yeah, that's difficult. So, so what have you found so far? Have you solved the problems? I solved the problems. Well, I've got some ideas. Um, I think we're making, I think we're making real strides as a, as a civilization. Um, you know, I, I feel like the, the data coming out of our experience, building these, these small teams that have a business outcome that they can, they can measure progress against, uh, who are deploying onto reliable, durable pipelines. So the, the, the cognitive scope that they need to think about, and most importantly, their cycle time, like human scale cycle times and rapid feedback is transformative. That is transformative, like allowing people to learn and building a context where people can learn, um, and improve and own their destiny a little bit, um, has made, I think a tremendous difference in the success of products that we've worked with. And, you know, one of the, I think the tremendously rewarding things about being part of our labs practice is we get to see that over and over and over again, where we come in with tremendously fraught environment, uh, relationships between business and IT. Um, we did a project here last year where the business was out shopping for outside vendors to replace this internal tool for one of our customers.

Um, and, uh, the internal IT people didn't want to lose the business and they were also like very concerned about the loss of strategic IP. Like when you engage, uh, with outside vendors, they'll want to sell that solution to other customers. Um, and, uh, we started the discovery and framing process and had, uh, the enterprise customers, uh, paired with labs people out talking to the business users and understanding what their real needs were like, this is the first time we've actually had this conversation. Um, and then we started building, uh, demos that they could interact with and play with and give feedback on. And then we started getting like very minimum, minimum viable products into production that they can interact with that were orders of magnitude quicker than their previous workflow. Um, and, um, that made a tremendous difference, tremendous difference, um, I think, you know, larger scale building sort of institutional change around these small scale successes. Um, I've been experimenting with, uh, Toyota improvement Kata as a process improvement pattern that, uh, Toyota has been using to improve performance in their factories for a long time. Um, and briefly it's this idea of, uh, get alignment on your future vision, use that to set context for alignment on your current reality, set a next target condition, some, some, something that is just out of reach in terms of knowing how to get there, but not tremendously out of reach. Um, and then run experiments to try to move you from your current reality into that next target condition. What I find very powerful about this is when we, a lot of that, that exercise of finding some shared vision is a constructive activity that you can use to get diverse stakeholder groups together to at least find, okay, we disagree with many things, but here's a common thing we can all agree on.

Um, and constructively find some common ground and then try to sort of take that common ground and anchor on a current reality. So we have some strengths to work on. We have some challenges to overcome. And then the experimental framing is one that leads to very little judgment and it provides a framework for being wrong about your vision, being wrong about your understanding of today's reality, being wrong about your understanding of the next target condition. The, the, the, the, the only way to sort of fail an experiment is not to run it. Like you'll learn from that result and that, that learning teaches you where the defects in your thinking was. And so, um, um, I've been running this workshops around this for sort of groups of four to 20 people or 25 people, which are small enough that you can get it done in a day or so. And, um, um, um, big enough that you can get like a cross section and, um, I'm, I'm thinking about this as a, as a mechanism to help people, the organization get clear. Because like what, what we talked about earlier, like the managers, they all know the problem with their incentive, like how that conflicts with their behavior. What they don't know is how changing their incentive is as going to ripple out to the next tier and affect their peers and stakeholders. And we can have that conversation in the context of the improvement kata. And then as a group, they can try some experiments and see how did this actually ripple out? And then we can use that to try to continue to ripple that out with more of these, um, or conversations with senior management. Interesting. So I wanted to take you through something that you mentioned a couple of times. It kind of undercurrents a lot of what you talk about. And I wanted you to maybe first define for us what you think empathy is because it covers in how do you heal that relationship between potentially the engineering and business side?

And how do you understand your customer, how do you actually potentially do these value exercises together? Do you know where people come from? But I, I was part of a training class last week where we spent a lot of time on this and different definitions of empathy and how you can mistake that for other things. So, I mean, when you come in and describe empathy to someone, what is that to you? Uh, I have not been asked to describe empathy. Um, so I think about empathy is twofold. Um, it is, it is feeling what the other person is feeling. And secondarily, it is the other person feels heard and understood. And what, what I'm seeing with empathy right now is that, uh, I'm talking with somebody who is wrestling with very challenging problems and I can listen to those problems. And one, I got a lot of information about their reality, which is wonderful. Second, they feel heard and then they get to see a different solution out of that same set of inputs. So if you actually, um, get this, I, I think it's actually this sort of like almost physiological coupling. It's like, you see that I've heard you and that I have, I'm experiencing the same feelings that you're having. And then I'm able to sort of broaden or bring alternative outputs. It's a very broadening experience. Um, I try to do this with my daughter a lot who's four, like mirror back to her that I'm experiencing, understand how she's feeling. And then I can model for her a different way of handling and coping with those feelings. And I think you need, you need both.

Like it's, it doesn't help me if you're like, well, yeah, Carl, you can take this other thing or go in this other direction. It's like, well, that advice is only valuable if I feel like I've been heard and you actually understand all of the complexity. Right. And so with the empathy that we do for me, that's about like, um, trying to understand and, and feel the holistic experience, the person with the other side of the table so that we can craft a better solution together and model for them a different physiological response. Yeah. Yeah. That's, that's, that's interesting. Like, like I, I haven't thought of empathy in that way. So I'm glad Richard asked you a confounding question there because we, we found it. Is that the opposite of confounding? Uh, and, and it seems like, uh, it's also, I had to front load a lot of like this, this stuff. Like, I think, uh, I think it's why in like, uh, socialists probably why in social situations, I feel like my head is like, you know, uh, a box of leftover coins being shaken around. And it's always a strange situation, but like, like I always think of empathy is like understanding people, like being in their shoes, right? Like to use that, that phrase. And then, and then there's a third part. I don't know how to make a snappy little phrase out of, but there is, uh, you know, acknowledging that someone's been heard, which everyone likes that they want to have been heard. And I don't mean that in a flippant way. It's a, it's a very kind thing to do to someone. But then I think, I think the reason, like, I'll speak for myself and then people broadly as, as is my practice. But like, I think the thing I always find like, uh, frustrating is the wrong word, but just sort of hollow, uh, about empathy talk in the tech industry is like, I don't know what to do with that. Like, I don't know the utility of it. Right. And I, and I think, especially if you're in like a managerial position, I mean, you're basically a bureaucrat in, in a good version of it, which is a bureaucrat is there to make sure in a utilitarian way that the process is, is followed and things are fine and stuff doesn't, you're an engineer of the organization basically.

And so like this idea of just understanding and acknowledging something, it doesn't really tell you what to do. But I think, I think what, you know, what you've added in that I think is exciting and interesting is like, and it results in an outcome, right? Like when we say empathy, we don't just mean some sort of like X-Men thing where you can read someone's mind and their feelings like, uh, I don't know, like a beta zoid or whatever. But it's more like, it also allows you to figure out like what to do to make a situation better and how to actually take actions, which I think is an angle on it that, uh, doesn't always come up. Well, there was one, I mean, when we were studying this last week, it was, we actually named it that there's emotional empathy in that point of like, literally, if you bang your shin, like my brain actually lights up in a way, like I kind of feel it. Like it hurts, right? I understand you're, you're hurt, right? You console a friend who lost their parents. Like those are emotional empathy. I'm really, excuse me, kind of feeling that. And then there's the cognitive empathy of, I kind of know what you're thinking and I've listened to you enough to now know, I know where you're coming from. Now this, none of this means that we're going to agree. None of this means that we're all going to have to say, but it means, right? It doesn't mean that somehow I build some universal consensus, but I know where you're coming from and we still may disagree on something, but I've truly listened. I've understood this. And so maybe based on compassion, I act on it, or maybe I, you know, I'm better at understanding you. So it's interesting to just see how empathy can be useful. It doesn't necessarily result in all of us being on the same page. So there's two stronger aspects that I want to build on what you said, Richard. The first is that, you know, part of our facilitation practice is often about breaking people into groups of three. And the reason we want to do groups of three is we're trying to build buy-in and support for a decision. And I want everybody in the room to feel like they own a piece of the end decision that the room made. And what we're coming to believe and what is part of our doctrine as a facilitation practice at Pivotal is that you can't get to decision until you feel like you've been understood.

So if I don't feel like I've been heard, I'm not going to be bought into the decision because it's like, well, I was not understood. And so my point of view is not reflected in this end decision of the group. And so we build a lot of exercises around making sure that people feel like they've been heard and ideally actually hearing people. I like to get both. Sure. And oftentimes I've had a couple of conversations with business leaders like, why should I do this workshop? Like, I know what I need to do. And I say to them, I say, well, you may know what you need to do, but you're going to need your team to execute. So you want them to feel like this is also the right thing to do. And it's also possible that people on your team will improve upon your desired plan. So if we actually have this conversation where we give a chance for everybody in your team to participate in this decision, I think the worst case scenario, if we do our job right, is we'll execute your plan, except that now everybody's going to be bought into it because they feel like they were heard and they participated. And the best thing that we as a group could come up with is what you went in with, which is a little bit frustrating as a leader sometimes. It took all that time, but you still need to get that buy-in. But there's also the opportunity that ideas and contributions from people in that group will sharpen, improve the idea. And so at the end of this, you're going to get buy-in and it'll be better than what you went in on. And so I think that that is awesome. And so I think that hearing aspect and feeling like people are heard is so important to that empathy. And then I also, I don't think you can separate the cognitive and the emotional. And I think that the way that I feel heard and understood cognitively is I see that you are able to experience and feel the emotional impact that it has for me. And so I think that to have a high-quality conversation about the cognitive content of the conversation,

I also need an open line of communication around the emotional, the feelings that comes up. Because I think we as humans don't separate those well. And that is one of the ways that we communicate that the signal has been received. Interesting. I know some of the point where, again, reading some things last week in this class was sometimes the emotional can be dangerous because I can be – I can make decisions because I actually feel this sort of pain. And I actually might over-rotate on that and say, like, look, I see a homeless person coming into the office and I just give them all my money. And I was like, that wasn't actually a smart choice because I actually need some of that money still. But I felt so bad and I put myself in that situation. So, again, it's a challenge, but maybe it's better to over-rotate and have to back off versus just have no feelings in the first place. But it's just an interesting conversation. I don't think in tech we've had a ton. And you've brought up, I think, as we think about inclusion, as we think about bringing teams together, then we've probably over-rotated on the sort of clinical aspect of engineering. Well, so I had a lovely conversation with Sarah May who gave this fantastic talk at PearConf a couple of months ago. And she was looking at the power history inside Agile. And her point in that talk is XP was written by, sort of signed on by 12 middle-aged white guys. It works fantastically well for middle-aged white guys. And most of the critiques that have really been inherited and used to adjust XP have been ones that also apply to middle-aged white guys or guys who will turn into middle-aged white guys. And so we talked a little bit about this over lunch, and she's been paying very attention to communication skills and teaching communication skills. And one of the things that she raised with me was like, hey, middle-aged white guys are generally good at communicating with other middle-aged white guys. And so when I think about the practice of XP as sort of executed in non-diverse teams, we haven't thought about the discipline of internal communication very much.

And when you're looking to build highly diverse teams, and I believe, without evidence, but that diverse teams result in better products. You have some evidence for that. But that is something which I believe to be true, is diverse teams are inherently better from a product outcome. Yeah. That we're going to need to teach effective communication skills now for diverse people talking to each other, because that is not something that everyone is good at. Sure. And that's not part of much of our technical training today. Do you see that same sort of, you know, as you, when we're talking to our customers, we're helping them have communication between design people and coders and analysts and people who are doing, you know, claims in the business of, you know, whatever. It's like, are you seeing, I mean, that seems to reach beyond just how the engineering teams work better together. It's also, how does engineering become, or software development become better in the organization, right? Yeah. No, that's a good point. And I was thinking, one of our most profound experiences with one of our large enterprise customers here was we ran this, it was called the Pandora Workshop, named after the radio station. And the internal IT organization was trying to prioritize its backlog, and they were serving sort of six different internal stakeholder communities. And we're like, cool. So we built this effectively room-scale board game where we got the six stakeholder communities to come in. Each of the five different IT sort of major group areas had booths, and the stakeholders went around and had conversations with the different booths, and then we gave the stakeholders poker chips, and they collaborated with each other and funded the work that they actually wanted done. And the IT folks were just like, I actually had to talk with my customers and stakeholders in language they understood because I wanted them to fund the things that I thought were important.

And so I had to articulate the work that I thought was important and cool in a way that they understood. And the customers were like, oh, like, we actually had to talk with each other because the way we set it up, like, none of the customers could get everything they wanted. They had to collaborate internally so that they could fund the things that they wanted, and so they had to find shared goals. And just building those communication bridges was tremendously impactful for that organization and getting them to talk with each other. It feels, I mean, I think, I think this also comes back to this change from IT being a cost center to IT being a revenue center. And when you're a cost center, you think a lot about efficiency and high utilization as opposed to throughput. And so when you start, like, it becomes like, oh, we don't want to have these people talk to their customers because their customers can interrupt them all the time, and that'll be inefficient and expensive. So, good. All right. Well, those were some fine topics there. I feel like we could talk for forever, or at least I could, if I let myself. But we should, it would be good. We should have you back on and definitely talk about something that you've been alluding to a little bit, which I think is interesting, is like how you have the, I don't know, the organizational version of a strangler pattern. Which is, I don't know, somehow isolating out things that would slow you down from improving, but that you can't change as well. And sort of like back-burnering, changing them when the time makes sense. I don't know. That's my interpretation of it. But, yeah, it'd be good ongoing here. Like, just the topics and things that you encounter would be fun. What you were going to say? I'm happy to come back. I realized I had a conversation with Rob Mee the last time he came to, well, two times before he came to Seattle. And he was talking about a model he was toying with of, boy, maybe instead of trying to change like a 6,000-person IT organization, we should build a side, like, 10-person IT organization and slowly grow the new IT organization.

And they could hire from the old one as they prove things to be successful. Yeah, yeah, yeah. Yeah, well, that's actually, like, that's something I mention every now and then. But when you look at our customers, that's a pattern lots of them follow, right? Like, at Allstate, you have composed labs. And they often set up, like, labs in their own things. And the idea being, like, as you're talking about, like, I think of it as the immutable organization problem. Which is, once an organization is set up and successful, you can't change it. It's just, like, it's not that it's impossible, but to use Ferengi Talk to make my second Star Trek reference, it's not profitable, right? Like, it's very difficult. And so instead, and exactly as you're saying, you see people setting up a new organization and you take, like, volunteers at first so you don't get, like, the grumpy detractors. And then slowly you, I don't know what to call it. It's not, like, a strangler thing. It's just, like, I don't know, more sunlight. It's a strangler fig. Right, right. Yeah, yeah. I'd like to find a much better name for that because I'm trying to find nonviolent metaphors for the work that I want to do everywhere. Yeah, yeah, yeah. No, that's true. You're growing a new tree. Exactly. And, I mean, it seems to be a way around a lot of these issues. Now, the problem is, like, it might be, I don't know what you would call it, begging the solution. It's, like, if you have the corporate authority and wherewithal to do that in the first place, that might have been a solution to the problems that you had. But I don't know. Maybe it's easier just to, like, go to, you know, a senior committee of people and be, like, we're going to go down the street to that abandoned red brick building and set up a new organization and just kind of pretend like we don't exist for a while. And let us operate differently. Correctly using begging the solution. I've given up on that in the world, and I just mentally replace begging the question with ask the question. But that was not what you did. Exactly.

It's a whole other thing. Lots of begging to be had, especially if you give your money over to someone. Then you become a problem. The office guy who walks into your office. That's right. All right. Well, we'll find some more time to talk to you with you. It'd be fun to see how your gallivanting pans out and things that you learn. So thanks for being on. If people wanted to follow up with you, like, where would they go to in a non-creepy way? Well, I post to Twitter very occasionally at Carl Coriel. I work out of the Seattle Labs office. I suppose you can send me email at carlcm at pivotal.io. Well, I like that phrase, speaking of phrases, very occasionally. That's a good one. I'm going to have to remember that. I think when I was in high school, I was commenting at one point that I had a small abundance of something. And I think very occasionally is right there, right next to it there. That's good. I think frequently might also be more precise. No, no, no. I think very occasionally is much more precise than frequently. In the same way that, like, a small abundance is, like, a lot of something, but not, like, a lot of something. It's a significant amount of something, but not an abundance of it. I don't know. We can obviously talk about language a lot, too. That would be fun. But, as always, this has been Pivotal Conversations. If you want to find this episode and all the past episodes, you can go to soundcloud.com slash pivotalconversations. We post the show notes for this about every Thursday or so. And also, I think sometime in about this month, or it should be happening now, we're actually going to be merging together the two podcasts we have here at Pivotal. You've got your Pivotal Conversations and your Pivotal Insights. Now, of course, we have that moment and a few other podcasts that are sort of in their own style of things. But our sort of weekly, classically styled podcast, People Talking With Each Other podcast, are going to merge together. And so, if you keep subscribing to this feed, which you should, eventually you'll see those two merge together.

And, I don't know, I think you'll find a lot more satisfaction and frequency in having both of those. And if you haven't listened to Pivotal Insights, it's fantastic. They tend to interview customers and end users a lot, definitely a lot more than we do. And it'll be a good mix there. So, with that, thanks for listening. And we'll see everyone next time. Bye-bye.

Tanzu Talk · 🍕 Get more pizza.