TT: Maximizing Your Perspective on Leadership with Arthur Hu, SVP at Lenovo

(Intro Narrator at 00:00:00) Today, we're bringing you an episode of Tech Titans. Art Hu, SVP at Lenovo, joins us in this episode to share his best advice on maximizing your perspective as a leader. You're listening to Joel Beasley, Tech Titans.

(Joel Beasley at 00:00:19) In your experience, what's a mistake that you found yourself making over and over, and then you finally were like, I'm done. I've had it. I'm never repeating this mistake again.

(Art Hu at 00:00:30) Yeah. Well, that's a fascinating question, right? Because I think it goes back into the level of abstraction that you think about. And what I mean by that is a mistake, you're very unlikely if you're at all thoughtful to repeat an exact mistake, right? The same situation, the same context, the same system. But where I find, I'd like to move faster, and I've been working with my team on how to identify patterns, the patterns, right. How do we find classes of mistakes that might have more similar root causes? So let me give you an example, right. For a while, we went through a period where we were having higher production level incidents that were causing significant impacts to the business, right? We might not be able to ship. Maybe we couldn't answer the call center in the region for a time, right? Maybe our manufacturing line went down at a critical moment. And we have a process within Lenovo called full pad. That's literally a kind of a metaphor of replaying the board of chess. It's a retrospective in a sense that goes very deep on the root causes. And what I found is we would go very deep on what I would call the proximate cause, right? The teams were excellent about firefighting to say, okay. Well, for example, in this case, the hardware had a failure, and we just had a single node setup. And so how do we fix that? Okay. Well, we should make it a high availability setup, right. In another case, it might be, well, the high availability didn't work the way we thought it would work, right? So even if we had high availability, it didn't cut over the way we thought. And so what was happening is we were getting deep on a particular problem, a slice of a problem, but we weren't necessarily taking that and trying to expand it to say, what is the class of failures, right? So for example, if hardware failing, right, one week it was the server failed. The other was the storage failed, right? The third was the firmware and the controller node failed. And we were treating them as separate things, right? It's like, okay. Well, if the firmware level fails, let's do this, right? If the storage fails, let's do this, right? If the network interface card on this port fails, let's do this. And while those were all addressing that very narrow proximate cause, what we were missing was, well, guys, why don't we step back and think and put on our hat of we keep seeing different types of these failures, right? But they're all related to some kind of hardware failure, right, somewhere in the stack. And it doesn't matter if it was the storage, if it was the disk, if it was the motherboard, if it was an IC, like a 50¢ IC somewhere else on the chip. The broader problem to solve is how do we solve and how do we tolerate kind of arbitrary hardware failure, right? And so if you put your hat on that way, then you can reorient yourself and think differently. It's not, well, let me just think about it very technical. It's actually there's an entire discipline around this, around SRE and site reliability engineering, right, and how you engineer assuming that there's going to be failure at different points, right? And then there's techniques and patterns that you can adopt to go fix that. So not so much as mistakes, but I think the mental framing we took was too narrow, right, in a way that forces I would say not to repeat mistakes, but not stepping quickly enough to identify the synthesis to say, hey, look, there's a broader way of looking at this. And when you look at it more broadly, you don't have to be, you do have to be down in the nuts and bolts to fix the proximate issue. But if you can think correctly and group and identify the classes of issues, then you can multiply the effect you get by fixing just one issue into, well, how do we fix an entire class of issues across the company?

(Joel Beasley at 00:04:19) That's brilliant. You say stuff sometimes, Art, and I'm just like, my mind is just so focused on what you're saying. I'm not even thinking of another question. I'm just wanting, I'm taking notes. It's great.

(Art Hu at 00:04:34) I mean, it's, and I think it's not me. It's the team, right? I think that's part of the value of dialogue, right, which is you're constantly thinking what else is at stake, right? Because you're not going to be the person who's best fit to diagnose, well, what's wrong with the firmware version and how many patch levels am I away? Am I n minus one or n minus two, right? The teams are going to be on top of that. And so a lot of the value add is really thinking with the team about these mental models, right? Are we thinking about it the right way? And so, for example, it was like a light bulb for the team. It's like, well, instead of laboring every time when a production issue comes up, this whole class of issues we should bring, right? And there's a whole body of work, right? This is the whole point of how do you share knowledge and how do you, again, to your point, not make the same mistake twice. You can draw on people who are way smarter and at different scales than you and have done different variations to accelerate your journey. So the next time you're confronting something new, it's really net new that you can spend your brain cycles on.

(Joel Beasley at 00:05:34) So the result of those issues was site reliability engineering?

(Art Hu at 00:05:40) Well, it was introducing elements of that, right? Because I think, obviously, it's easy to say, oh, we should just do site reliability engineering. But because there's a practice, there's a methodology. There's role definition around it as well as architectural implications, right? That sets the team down a mindset change, right? Up to and including shifting from a very reactive mode to incorporating the mindset of how to incorporate quality from the beginning, right? How do we design in so that critical applications are more fault tolerant, right? Because there's a whole different way of engineering at different levels. You can make application logic choices, or you can make deployment pattern choices about your cloud, and if you use private cloud or public or on-prem. So even on the technical side, there's a whole, it drives a whole different set of downstream discussions that we need to then think about how do we allocate skill to go do that. And the other interesting thing that happens is also, it raises good business questions. So it flexes those muscles. Because now if you want to engineer a solution that's much more robust compared to what we've traditionally done, well, there's a cost and a time associated with that, right? It's not free. If you think about the childhood parable about the three little pigs, right? Do you want to build a straw house? Do you want to build a stick house? Or do you want to build a brick house, right? They don't all cost the same, and they certainly take different times, but they have different characteristics about their resiliency and fault tolerance and the usability characteristics, right? And that's an interesting discussion with the business because normally they're just like, oh, just make it right. And sometimes you have to have a bit of the discussion to say, yes. We can make it right, but let's really talk about what right needs. And by the way, there's no value judgment in that. It's just a discussion. Sometimes the straw house is okay, right? I just need this for six months to the promotion season, and then we'll build it again next year with the learnings of that. And that'll be the brick house for the long term. But for the next year, we'll just make do with the straw house.

(Joel Beasley at 00:07:38) So figuring out that everything could change, but I really like owning outcomes and working with brilliant people. Those are the two things that are requirements for me.

(Art Hu at 00:07:50) Yeah. And again, if you look at Modern CTO, I think it's great, right? You've kind of built up a network of really cutting edge thinkers on a variety of topics, a variety of enterprises, right? So you kind of have this great network and you can see that accumulated over time, right? And maintaining those relationships and seeing how the world evolves along with them. And you kind of are at the front, the leading edge really of, well, I guess, management and technology thought, right? And that's super appealing to see what you've built over time bear fruit. And some of the things, since we last spoke, similarly on seeing the outcomes, to have a hand and see the power of technology as part of our business of driving deeper. And there have been several, and at this point, Lenovo is over $50 billion, right? But we've had, and directly as a result of some of the things that we've worked with the business on enabling with technology, we have multiple new billion dollar businesses that are high growth, right? Where I can point to and say that's something that we helped build in the last, in the time since we last spoke two and a half years ago. So similar to you and seeing some of the arc over time, you're saying, boy, I helped build that. And that's really something to, that gives me a tremendous sense of satisfaction. That's awesome, right? There should be a few things where you couldn't predict, but if you look back, you're like, yeah, right? That's awesome that it happened. I wouldn't have imagined it could, but I'm super glad it turned out this way. Again, on a personal side, just a book that I read a while ago, but I will revisit regularly, and you may have heard of it from Clay Christensen. Of course, he passed last year, I think. But the Innovator's Dilemma fame, famous business school professor. But he wrote a kind of a very different book called How Will You Measure Your Life? And it wasn't a business book at all, but really a much more philosophical reflective piece about thinking about what's important, right? And so if you haven't read it, it's certainly worth a read to help put things in context.

(Joel Beasley at 00:10:02) I definitely will because when he passed, there was a lot of social media post and I said, well, I hadn't heard of this person. So I watched a TED Talk, and I think the TED Talk was maybe a preview to measuring your life. And, man, that was deep. It really stuck with me.

(Art Hu at 00:10:18) No, it's yeah. It really helps put things in context, right? If you're having one of those days, and we all do, where things aren't quite going the way you think it is. So that helps keep things in perspective.