Focusing on Product, Not Just Operations, and Growing Customer-focused Staff, with Thomas Squeo

Episode 100 · 33:02 · SRT · archive.org · all Tanzu Talk

Well, here we are at SpringOne Platform, 2018. Is that the right year? I haven't checked today. All right. And why don't you introduce yourself briefly? Sir, my name is Thomas Squayo. I'm the chief technology officer at West Corporation. We're a multinational communications company focused on connecting people simply. Yeah, and so at a company like yours, what does a CTO do? So I'm responsible for product engineering globally, and we have various domains that we operate in, everything from conferencing and collaboration to safety to interactive services, which includes both inbound, outbound, IVR, and all of the applications around the customer experience ecosystem. Yeah, I guess, I mean, not to be insulting to other companies, but I often wonder like what a CTO at a non-vendor does. But in your case, now that you say it, it's pretty easy to figure out because you make stuff. Yeah, make software. Yeah, you make technology stuff. So as you say, you need someone to be like, have purview over all the product and actually doing things. That makes a lot more sense. Because now that I've talked myself into this hole, I can't think of an organization where it would be confusing about what a CTO would do. I don't know, maybe like construction? Yeah, well, they'd probably have a chief information officer. Yeah, yeah, exactly. They'd be responsible for like IT finance and PMO and all those kind of things. Totally, yeah. So I work for our CIO. I'm on his team and I have a counterpart of a chief architect and a chief product officer. So kind of those are my peers. And then we hand off to a head of operations. Yeah, no, I guess you're, I mean, yeah, of course you'd have a CIO. And I guess the thing that always thuds in my mind is if you're not working on a technology-based product, like if you were some sort of coffee chain, like your product is coffee. And so do you need like, big coffee chains probably have a CTO. Yeah, there's definitely, but Starbucks has a mobile group. Yeah, that's true, that's true. Yeah, yeah, that would be. Software has eaten the world. That's right, that's right. Yeah, that mobile app is really nice. They don't use it in Europe at all. I think I'm going to lose all my stars. I need to remember that when I'm here to get my free. Anyways, that's neither here nor there, as it were.

But so one of the things we were talking, catching up on, well, one, you've been, you know, for a little while working on a book about digital transformation. Well, let me ask you this first. You think that's a good phrase? No. What should we say instead? No, I think it's more, I'd actually move back to more business transformation than anything else. Oh, yeah, okay. So I think that we're, I think the term that they arrived at originally was actually more relevant because I think that if we talk about Starbucks Journey, you talk about any of these other organizations that are out there that are kind of weaving technology into the fabric of their organization, it's actually a fundamental shift in their business. You think we could get away with that as sort of like thought lording people? We could say business transformation? Does that work? I could drop it from all the presentations I give and start a revolution here. Yeah, yeah. Yeah, because it is like, yeah, I don't, I don't know what else to say at this point, but maybe business is better. I did just drop the word, I just talked about transformation. You're going from A to M. You know, whatever that transformation is, you have to build kind of a repeatable engine where people are used to the culture of change without necessarily viewing it as an enemy. Yeah. I think that, you know, whether you kind of view it as the only constant or anything like that, if you work in technology, there's no chance that you can work in technology and expect things to be stagnant. If you do, you have a shelf life of about 18 months. Yeah, yeah. I mean, that is kind of, I guess, what technology is, right? That distinguishes it from other things. That's why we're here every year. Yeah, yeah. So, you know, starting with y'all, like at West, where did you start with? Like, if there's change that needs to happen, like, what were you changing from? So, West was operating as a holding company for many years, so we had five business segments. Those five segments largely rolled up to, you know, segment presidents where general managers ran each line of business, and now we've actually eliminated the GM structure and pulled it into an operating company model. So, now you are able to, you know, centralize IT functions, be able to build product engineering, you're able to build around a domain model. You can operate Agile at scale now.

You have the ability to be able to go and look from strategy, architecture, to engineering, and how that's ultimately going to affect how you're going to move to operations. In our journey, from a technology perspective, it's to move from an operator-intensive model to a very product development and engineering focus, where you see, you know, teams that might have been developers doing, like, 75% of their time on non-developer tasks and 25% of their time actually doing software engineering. We want to shift that. We want to invert that entirely. So, they're actually focused on doing that thing around value creation more than anything else. Yeah. So, describe that operations mentality of doing things. Like, what does that look like from sort of, like, an end-to-end perspective of, like, you know, customer needs to do something to, like, you providing it to them? Well, West, as an organization, delivers all layers of the OSI stack. So, everything from physical infrastructure through layer 7, where it's actually a traditional application environment. So, we have physical assets that require a different way of implementing than, say, you know, a cloud-native application that's going to be delivered over a mobile device. So, in that kind of, in that journey, you've started to see kind of this notion of how teams need to be able to kind of view their work differently, view it in increments, view it in smaller groupings of work in progress, and how it actually gets rolled out to the field. From a customer perspective, our customers don't really care about the fact that we have legacy infrastructure, physical hardware, and so on and so forth. So, when we move away from that operator-intensive view, it's being able to go and take what we can move into a modern architecture and be very aggressive about that. And that ends up being about, I'd say, about 60% of our portfolio of candidates to be able to move towards a modern architecture. Right, right. Okay, okay. So, instead of just sort of like, I mean, I guess the synonym for operating is just like running the thing. And instead of, across those layers, people are sort of concerned about running their component of it, essentially. And what you want to have is more of a, I get mixed up spatially.

I guess you want more of a, it's not horizontal, but you want to make sure that, like, there's responsibility for the entire product that you're delivering to the customer. And that, instead of, instead of the teams being like, I'm at whatever, this layer, I do this thing, and then it kind of integrates together at some point. Instead, we deliver the whole thing. Or like, I shouldn't say deliver. We have as much responsibility over the whole thing that we might, the product that we might deliver as possible. Whether we look at it as a, as a domain model, or an end-to-end service model, or an agile release chain, or a train, or a value stream, any one of those is synonymous for you are accountable for what goes into production and what the quality of service for that customer experience is. So what we've done, and one of the things that has changed, or is a key part of our change and transformation, is that we now have product engineering teams who are equally responsible for what's happening in the operating environment in front of our customer. So it's no longer kind of that throw it over the transom. And I think of that old adage where Deb went to QA and they threw it over a transom. And their QA said, yeah, it's good. And then they threw it over to operations. No, that is an integrated team now where they are responsible all the way through the customer success. Yeah, yeah, yeah. As I've been thinking about this stuff over the summer, it seems like, I mean, this is sort of like a big point of DevOps stuff at a, I guess ironically, maybe at an operator level. Of if we wanted to operate this stuff better, we should have the operations and developer people work together and have responsibility for it in production. And like, as you're talking through it, like, I guess maybe, I mean, this is a theory of what I'm thinking. Like, maybe what I've always felt is missing from that is like the product part, right? Like, it's one thing to make sure that you write this code, you, the developers satisfy the requirements and they write the code. And then they're also responsible for like it running in production. But there's always been this other layer of like, well, is that a good business? And how do you layer that on top of it as well?

Well, we, we consider, so one of my key partners is our chief product officer. And then we have a counterpart, each one of my executives that's on my team has a counterpart on my chief product officer's team. Yeah. So when we work together, those are looked at in kind of that end-to-end model without a doubt. And I think the other player that's missing in that equation is security. So when we see any, any of our, our kind of, when we get punched in the face, it's always in that reality of between operations, networking, and security. So we need to be able to kind of make sure that those people are, are just as equally part on the team. So when it makes sense from a business context, that's actually being managed as a portfolio. So we're looking at all the elements that drive that, what applications actually drive that product. And then from a technical perspective, we're looking at what can we consolidate, what we can modernize, is how we actually co-mingle, you know, PAS, PKS, and maybe even directly on the IS fabric. So what are y'all, is a chief product officer a CPO? Yes. Yeah. So when you're with the CPO and I guess it's a, is it a CISO? I always forget the CISO you're doing. And you're there and some other people, like what, I mean, so like you come into the room, like what do you, what do you do? I mean, there's always a bunch of prep work, but like what are the, like the tools you use for like, here's what we're going to do next. Like, like there must be some analysis you do and some thinking or what does that look like? I mean, it's more, I mean, it's everything from business case development to, you know, kind of position and theory of action statements that we could actually test out. So a big part of it, I mean, we're on our kind of redefinition of our next generation CX platform right now. So that process involves customer engagement, being able to work with the folks that we work with, and commercial utility, pharma, healthcare, energy, and others. And what happens is that the chief product officer and I are out in those meetings together. We are kind of going over what our theory of action is and how that would go. How does that resonate with the customers? And when, and, and the executives that are responsible for those lines are in those conversations as well.

Security and architecture are usually brought in as a more of an internal process. So they're actually, you know, they're engaged after that kind of, you know, that, that kind of forward tip of the spear has come back in. Right. And what happens in that point is that we're actually looking at what can we take advantage of from a kind of a forward looking technology perspective, what's going to be able to eliminate technical debt in the portfolio. And the customer really doesn't care about any of that. So if we talk about what's below the value line from an engineering perspective, the customer goes and says, what's below the value line is everything that you do beyond the quality of service. Yeah. They're like, sorry, I don't care. Yeah, exactly. So, but the thing is, is we have to meet them where they're going to, you know, transact dollars. Yeah. That's the ultimate value problem. Yeah. And that's, that's, I mean, the part of it among many things, one of the parts that's interesting is that there's always this tension of the technologist saying, there's two things that they say that there's a tension around. Like one, here's something we could do that maybe no one's asked for. Right. And then the other one is like, uh, we got to like fix the messes we have. Right. Like in order to do any like good customer experience, any good CX stuff, there's a lot of like, well, maybe not in y'all's case, but there's, there's, there's a fair amount of like technical debt and building out that we need to do. And like, so like, I think the tension comes when the, like the product people are sort of like, yeah, but I want to talk about like product. So how do you like, how do you get like the product people to be like, all right, you should do some technical debt. Well, I think we have to carry technical debt on the balance sheet. Yeah. I mean, it's, it's without a doubt, I mean, the decisions that as soon as, you know, any line of code is put in production, there's technical debt incurred with it. You have to manage it. And ultimately any, any bit of its extensibility is going to be. And do y'all, have you figured out a way to kind of like do that? We're in the process. I mean, I think that we're, I think we're, you know, it's early and some of the more mature organizations that I kind of look to, you know, whether that be somebody like T-Row or

JPMC or anything like that, they're actually managing it on the balance sheet. So we're kind of looking at modeling that. We have a new chief architect that just joined our team. He and I are going to be very focused on how do we actually account for that and then actually, you know, pay that debt down. Yeah. But when I do think that we look at kind of next generation products, the thing is, is that one of the, one of the challenges also is that there's always that notion, we have all this IP to draw from, you know, but we also have this debt that goes on. So, but the things that give us that incumbency status is the same things that also hold us back from just kind of having a big slate. Yeah. I always think of those as like the shackles of success. Yeah. And I also don't believe in setting up an external innovation team that's going to go out and do the cool stuff while leaving the other stuff behind because ultimately that kind of creates a, it creates a framework where there's a lot of animosity against that team. Yeah. It kind of sets them on a pedestal of fail. And it seems like it's hard to integrate. Like I remember a long time ago now, I was talking with, with some, with a team somewhere that I'm anonymizing and they were, they were talking about how difficult doing their IT was and, you know, changing and getting to that point where you could have a discussion about how do we do new things with the product. And they had a, they had a really good mobile app that I used all the time. And I said like, yeah, but your mobile app is awesome. And, and kind of to what you're saying, they're like, oh yeah, that's some other team. Yeah. Like way over there. Yeah. Yeah. And like, my thought was like, well, maybe you should go talk to them. Right. Like, however they got to that point, like, obviously, like you're saying, you bring, um, that's such, that was a cool metaphor at first, but it's, I don't think it's quite, I don't know. It doesn't work as well as, as I think it used to. Yeah. Yeah. Yeah. I was thinking black hole, but that's not hopeful. So, so anyways, but you know, it's sort of like, obviously you've got more existing debt in, in, for this conversation, but there is something that that other team is doing that like you should be doing. But anyways, so it seems like it's nice to not split things off. Well, we have a continuum, everything from, you know, what I'll say legacy technologies that were built in, uh, you know, kind of MVC patterns in the mid aughts all the way

through cloud native 12 factor applications that are being developed right now. Uh, you know, we've got every, you know, we've, we've, we selected Pivotal cause it's a polyglot platform. Uh, and because of that, we are able to kind of now at least standardize the operational plane with what was announced to being able to monitor multiple foundries. Yeah. That's a big deal for us. That, that, that was an ask that we had, uh, our business reality is that we have to be able to operate in our on-prem environments and our cloud environments. And I have to keep them both as equally first class citizens. There can't be, there can't be this balance of power where I say, oh, you're in the cloud, therefore you get all these passes and everything like that. We still have to deal with patch hygiene. We still have to deal with all those things, but because of the size of the portfolio and the introduction of things like PKS, um, we now have an ability to, uh, uh, you know, of, you know, incorporate portions of our portfolio that were not candidates when we were only looking at PAS. Yeah. So that's actually now, so the more of our estate that we were able to kind of get on a single management plane, the more I'm able to have that, you know, move from very operator intensive to value creation. No. And, and, and that's the shift that like, uh, I think we're always chasing after. Like, like as you're going over that, I was thinking, I mean, I was thinking a couple of things. One, at some point you want the, the product side of the house. Maybe that's a better word than the business. Like in it, we're always saying the business, but you want the product people to, we are the business. Yeah. Well, there's that too. Well, I mean, I think that that's the thing that West has, as a part of our journey and transformation was that this notion of separate organizations where we ask it to do something and the other team is actually doing a, uh, uh, you know, the business now it's the fabric of the organization. And so that, that probably gets closer to this thing of having a product think, and of course this is completely self-serving being a pivotal person, but like we need a platform in order to evolve the product and service a product. And it was making me think like, I would assume if you're in, uh, like a, a manufacturing

environment, you realize like how valuable whatever your manufacturing process is, right? Like whether it's old, you know, Henry Ford stuff or Toyota lean stuff or whatever it is people do nowadays, or like robots. And so there's probably active discussion from the business. I'm putting that in air quotes of how like we need the robots, right? Like they're the ones pulling in the technology, whereas I think in the IT world, it's at the infrastructure layer. It's very rare that people pull in the technology, which. Well, I think, I think that with, uh, AI machine learning, RPA, you know, uh, knowledge engineering, all those activities that are happening now, those things that were the business in air quotes now, uh, now they're, they're differentiation is ultimately. Yeah. Yeah. Those, those get dragged in easily. It's just, it's just like that lower level stuff of like, uh, I mean, to be conveyor belt. Yeah, yeah, exactly. To make a joke about it. Right. This is like, we need containers. And then the product people would be like, I don't, what are you talking about? But I don't think that the, I mean, so I think that, um, one of the other things that we've also seen is our product people have become more, uh, uh, sophisticated technologists. Yeah, exactly. You know, so, so when we do talk about containers, they understand why they understand what the value of that is. No, no, that's, that's exactly the point. It's like getting, getting to that point where, and then, and I guess it's like the reverse flow of the other part where you want the technology. Yeah, technologists become more product people, but then also the product people need to sort of like understand the use of these various wacky technologies we have and stuff like AI and is a little more understandable, but definitely at the infrastructure layer. Well, I think that, I think our, our job as technologists is to be able to insulate folks from that, uh, some of the complexity that needs to really be worked out under the hood by our engineering teams. That shouldn't be the topic of conversation. It's definitely not the topic of conversation in the boardroom, definitely not with our C-suite. Yeah. But the thing is, is that our C-suite is, uh, able to have very complex conversations about what the value of something like a microservice is versus something else.

And I mean, you know, it's pretty, you kind of, you kind of mind blown when you're having conversations with the CEO and he starts talking about microservice architectures. Yeah. Yeah. Yeah. Whoa. Yeah. I mean, not to, not to. And not in a technology company like Pivotal. Yeah. Right, right, right, right. Yeah. And to stop flogging the dead horse into glue, just like, it is, like, I would imagine if you're in like a, uh, you know, a consumer packaged good company, like at the C-suite and board level, you talk about like toothpaste innovation, right? Like, like there's the technology side of toothpaste, right? And, and that probably bubbles up all the way to the top, right? Like probably at some point they were like, you should check about, you should check out aerosol, right? Like this is going to change the industry. CFCs. Yeah. Oh, wait a second. No. What if we could just press a button and spray product out, which maybe was like the containers of the day. So, uh, so in like the other thing I, I, uh, I've been asking people about is so in shifting from that operational thing to a mode, to a product mode, right? I think, I think the way people talk about that change is, you know, you have to change your culture around and, you know, I, we were talking before I was recording how there is the, um, you know, the Western model and all these things. And I always get frustrated. Well, they're delightful, but they're very descriptive rather than saying how you change over to doing something. And so, um, in your case, like when you were switching people over from, I'm going to operate my one part and instead to I'm a product person, basically system. Yeah. Yeah. Like I'm, I, I should care about, be involved in and work on the whole product, like the whole thing of it. Like what, what are some challenges you had in doing that with, with people or groups or, or was it super smooth? No, no, no. Nothing's ever super smooth. If anybody tells you that they're, they're kind of glossing over the details. So I think that, um, you know, one of the things that I found is not everybody makes the curve. You know, some people don't, they don't, they're not going to be able to make that shift. Yeah. That's something that the, uh, the Dick's sporting goods guy kind of said pretty brief.

Yeah. Anyway, it was very, he was very direct about it. It's very real. Yeah. Um, but the thing that I do find is that, um, usually the talents already in the organization and they've been starving for the opportunity to think that way. Yeah. Um, I think that what we see is that you now need to temper that back so people don't overreach beyond their kind of domain of influence. And I talked a little bit about that, uh, that notion of, I want developers to focus on development tasks, whether that be software engineering or SRE or any of those kinds of things. Um, I want that to be their area of focus. But then as you kind of move around in the organization structure, you think about how a balanced team is going to operate and you think about how they're going to operate with it, with their directors and executives and so on and so forth. That's where you're starting to see a lot more cross-sectioned into the product organization. So I think that people need to be able to understand the context of how the value is actually being created. Yeah. But that's, that's what I kind of see how that last part you're talking about when you're interfacing with like the management layers and that, that affects like, like what, what, what is that? Tell me more about that. Well, I think that, um, as, as a, as a technologist, um, I have to be understanding and also, uh, sympathetic to what drives the product organization, why they need to be able to do these things. Yeah. Okay. From an architecture standpoint, the architects need to be able to understand how the engineering organization works because most of I've, most architects always kind of came into their architecture roles through the engineering, uh, chain. But at the end of the day, I mean, we have, we have a very tight coupling of those two organizations. I always kind of joke around, you know, architecture, special forces, product engineers, regular army, you know, I think that like it's, it's, they have to work together, but, but, you know, the strategy and the product strategies are basically being orchestrated largely by the leadership teams. Yeah. Yeah. So, so what do you think of the notion of like the frozen middle? Does that, does that really call it the frozen middle or the clay layer or whatever you want to call it? The clay layer. Yeah. Yeah. Um, so it needs to be defrosted. And the thing is, is that, uh, again, um, this too shall pass is not a strategy, uh,

because the thing is, that's like the hope strategy. Yeah, I hope this goes away, you know, I hope you go away, you know? Um, but the thing is, is that, um, you know, you kind of think of that, uh, there's a YouTube video of the lone nut, you know, the guy in the audience, you should check it out. So it's basically this notion of change management is that it's just one person that's willing to run at this problem over and over again. And then when somebody joins him, it's actually that second group that joins in is actually the thing that actually makes the change real because you have one guy that's just crazy and then everybody else is actually going to say, Oh, maybe what they're doing is actually pretty cool. And in the case of technology, when you look at this, you kind of go and say, all right, well, um, when, when engineers hear from other engineers and it's not a top down mandate, then it becomes real. And one of the things we found that kind of virtuous by-product of us implementing Pivotal and kind of going through our app TXs and transformation journey and so on and so forth was when teams were able to actually draw from knowledge within, uh, from themselves without having it be kind of like, Hey, the vendor's going to come in and enable you making like self-educated, self thought leader. Yeah, my, my, my highest functioning teams have been able to implement, uh, without ever actually having any more than just the documentation. Yeah. And that's always exciting because then you're able to go and say like, Hey, I've got pockets of great talent that are also motivated to lean forward and deliver. Yeah. Yeah. And what you started saying, um, on the culture thing comes up over and over again that like the, you have the staff who have just been waiting for someone to tell them to do a good job or not tell them to enable them to do a good job. And I mean, Adrian Cockroft, when he was at Netflix, he used to say, I get all my engineers from you. Right, right. Cause yeah, yeah. That was always a good quip. I was like, Oh wow. And I took that to heart. Cause I mean, I thought to myself, I'm like, people are, uh, you know, people join teams and they work for their leader. And the thing is, is if they don't believe in that leader and that, and, or their team is inhibiting their ability to do something, they get bored and they leave.

Otherwise they stay and that might be the worst thing that can happen. Yeah. So do you think there's, there's arguments, the wrong word, but do you think there's an observation to be made that your, your sort of, let's call them engineering staff are the ones who need the least help changing? Like, like, like, you know, once they're, once they're given the ability to do something better or like, like, like to, if, if, if we were to take, let's say four groups, I'll give you a three. Yeah. Use the rule of thirds. Yeah. You have 30% of the organization that is going to just, you know, take to this, like a duck to water. Right. You have 30% of the organization that can go in either direction and you have 30% resistors. And the thing is, and I, and, and what the problem is, is that the resistors typically have more gravity than the people at the top of them. Because the thing is, is that you need to be able to get that inner, that middle 30% to be able to see themselves excelling. It's kind of like that cusp of engagement in gaming, you need to be able to have the person succeed, but it's got to be challenging enough that it actually gives them reward, whether you're, you know, uh, physical training, gaming, any of that cusp of engagement, because the thing is, if you roll up on some task, that's not achievable, then you're going to just kind of give up. But the thing is, is if you're able to kind of meet them and I, and we call it our customer journey internally. So we basically go to our, our engineering teams and treat them as customers of the platform. And then when we go to them and we say, okay, you know, you're going to start at step A and we could see you going all the way to step N or beyond. And the thing is, is that what we see here is that there's going to be a point where our, your journey is not going to be something that we're going to prescribe. You are going to tell us how that's going to happen. Yeah, yeah, yeah. That, that, that's sort of like, uh, autonomy part. That's another like mysterious aspect of, no, and you, and you said, you said it nice and concisely there is like, we'll sort of like push you. And at some point you've got to like drive yourself, which is a very, I guess, especially if you're moving from an operating sort of mode, like you don't, you are told what to operate. Yeah, yeah, exactly, exactly.

You're, you're not sort of left to, to come up with what you should be doing at any given time. West as an organization, uh, uh, a big portion of the business was implementing other people's software, you know, and doing the integrations around it. And now we're actually building a lot more of that software end to end. And that is something that is actually a part of the change. So you see, you don't see a demarcation between those that implement and those that engineer. You're now seeing that part of the whole system. Right, right. So, so you've mentioned at least one tactical thing that as, as the management layer, the leadership, you could even say, uh, that you can do to change the, the culture, the organization over, right. And that was, um, you know, like go, go to the team and kind of walk them through, like, here's, here's the product that you're working on the customer journey. And let's kind of like, I don't know, is it a week or a couple of days or whatever? Let's spend some time and just imagine what's going to happen and kind of like get you involved in that process to sort of walk them through it. Um, but like, what are, what are some other tactics that you use to switch people over? One of the things that we did was, um, you know, we're in the process of rolling out like, uh, uh, technical education academy. We've got those kinds of habits, future leader development, all these kinds of things where you start to see people like getting engaged in a professional development journey. That's around what their, their craft is. So the craft of software engineering as far as the necessary, like you're here to build this app and I don't care about anything about your career. So we're looking at the whole individual. Yeah, that's interesting. And that's something that's also part of the culture change. So, I mean, it's like we kind of, um, our CIO has a, uh, uh, a construct where you kind of categorize the world and customer and colleague, and you can't consider each, you know, you can't, you can't go and, and if, if you teeter too far on one end of that balance or the other, you end up kind of losing the ability to execute for either one. Because the thing is, if it's like, you know, you grind your staff down to a nub, the customer is going to suffer. If the customers, you know, if, if, if you invest too much in, you know, organizational health and it's at the expense of the customer, you're going to lose market share.

So you kind of see this kind of balance occurring and that's been a part of the, the, the culture really kind of gets driven at the top. But the thing is that it actually gets realized, you know, throughout the whole, the whole system. Yeah, yeah, yeah. And I mean, that's the challenge of it, right? You can't just like mandate it. You can't just rain it down and it's good. And I mean, I mean, that, that's an interesting shift as far as the way, I guess, I mean, you can call it HR, but I mean, the way you do your people management and training is equally based on you're ultimately going to be a product oriented person, right? Right, right. Opposed to, I mean, just to repeat back what you're saying in it, you could assume, or you could say the training is going to be like, you should get, you should get better at like JavaScript. So here's like some JavaScript training, right, right, right. But instead you want to give them some training and nurturing of like, here's the broader picture of, of what you should be paying attention to. Well, I think that we use a, a, a maturity modeling framework that we built internally. Yeah. We worked with ThoughtWorks to build the initial one and then we kind of iterated over it from there. And what that did is it kind of gave us like, you know, eight maturity assessments that we would administer to the teams and they would actually go and say, Hey, we think we're here. And the question, what the outcome of that is actually that we go and say, okay, you're here now. Where do you want to be in a year? You know, and then that gives them the ability to go and say, Hey, you know, we want to get better at our automation, CICD configuration management, blah, blah, blah. Some of those are just, we'll use the platform and automatically you're going to be in a better spot. And that's, and the thing is, is that, you know, once people kind of that light bulb comes on, they go and say, Oh, okay. So what we want to do is make the right way, the easy way, whether it's from, you know, configuration management, deployment, environment management, or even security by using the platform. We insulate people things from like, uh, things like patch hygiene, uh, you know, library management, uh, automated security testing is baked in your CICDs there, you know, automated QA, all those activities that actually are kind of the far end of the maturity spectrum, they

get when they start to come into the platform and then they start to see that these things become part of their craft and then they can become better software engineers, where they're focused on something like O theory or they're focused on, you know, yeah, yeah, it's like a product enable, cyclomatic complexity. Yeah. So, so then, so then just to wrap up lastly on a somewhat related topic. So like, uh, if someone wanted to be a CTO and they were like maybe a senior technical person or, you know, there is some, some, they're about maybe two thirds of the way there. Like what, what's kind of like the last mile advice you would give them? Uh, go be diverse. Uh, nobody comes up from one, one path. All right. So kind of spread yourself around. Yeah. I mean, I think that, um, you know, I think that one of the, one of the, uh, observations that I have about my peers that are, uh, uh, CIOs executive team is none of them came up from a single track. Every one of them came up from, you know, they spent time in the product organization. They spent time in the strategy function. They've, they've done time in security or engineering or any of these things, quality by having that kind of diversity, you now have an opportunity to kind of a better perspective for how you need to be, you know, empathetic as a leader. No, that's good. That's, that's not advice you get all the time because oftentimes your manager wants you like, like it's difficult to get sort of mentoring. Mentoring is, I guess what you want to get, but to get, you know, in your annual or whatever meeting of how you can improve. It's, it's very rare that your manager's like, what you should do is not work for me and, and mean it in a helpful way. Well, I think, I think that we also view it as that, um, our ideal, our, our ideal staff is going to be somebody that's valuable, not only to West, but valuable in the market. Yeah. And I think that one of the reasons why we selected some of the tech, the technologies that we did was technology first process, you know, kind of, um, uh, capability. And then ultimately that culture kind of goes throughout all of those. Yeah. But the thing that makes that staff member, uh, valuable to us is the thing that makes them valuable in the industry. And if they have that, if they, if they've been worked with as a whole individual, then,

then they're not as likely to leave us. They're likely to be enjoying the work that they're doing. They're enjoying the team that they're working on. But if it's a drag, why would they stay? Yeah. Yeah. Yeah. Yeah. And then like, I mean, as you're saying earlier, that'll be reflected in your product and your business, right? Like, like it's, uh, like, you know, just as a happy wife makes a happy life. Yes, exactly. The employee makes a happy, vibrant company business. Yeah, they're, I need to find something that rhymes. Yeah. Well, great. Well, thanks for, uh, finding some time to talk. And if people want to, uh, I don't know, follow you around in a non-creepy way, you got a Twitter account or anything? Yeah, it's K-O-T at, uh, at Twitter. Yeah, yeah. Sounds good. All right. Well, uh, we'll see everyone next time.

Tanzu Talk · 🍕 Get more pizza.