Culture Champions: Jim Whitehurst, Ex-CEO, Red Hat

Yeah, no problem. It's great to be here. This is one of my favorite topics and one I don't get to talk as much about, but I continue to be fascinated by this and there's still a lot of work to do. So glad to be here and look forward to the discussion.

Yeah, well look, I mean, you know, it is interesting because I think we all kind of came up a little bit separately and all developed kind of a similar set of working norms. You know, my view of this is very simple. It is about how we are organizing a company to get something done. And that's like, how do you figure out what to do? How do you arbitrate disagreements? How do you have a kind of a control function, etc., etc., etc. And so, you know, if you want to say that some of those things are being replaced or augmented or what you want to say from a traditional management system, you know, those are the elements. So something like, you know, I talk about autonomy with accountability. I'll pick one of a couple of those. I think there's this real drive around autonomy, oh, let's give people more ability to make decisions. But honestly, if people don't feel accountable to actually go do that, you've kind of just created chaos. So if you're trying to say, hey, I want people to make the right decision in the moment, it can't just be I'm giving them latitude to do that. You have to kind of create this sense of ownership and responsibility that they will do that. I'll take a far different extreme. I'm on the board of United Airlines and during, you probably all remember the horrible Dr. Dao incident where a passenger was dragged off a plane. And getting into that is more of an over-drinks long conversation, but kind of coming out of that, one of the things that United worked on was something saying it's never wrong to do the right thing. So let's give people more autonomy to make decisions in the moment because if you went through that, every decision was made right, but at multiple points along the way you would have wanted somebody to make a different decision, but everybody was, you know, kind of following orders. So we said, okay, it's never wrong to do the right thing. The response to that was people were frozen because they're saying, whoa, whoa, wait a minute here, I don't, what if I make a decision that later on turns out to be wrong? So what you got, because you didn't kind of create this sense of accountability, you had to do something and people were scared to do something, nobody did anything different, right? So just giving autonomy, you know, again, either creates kind of a lack of action or it creates a degree of chaos if you don't also have accountability. You put those things together, you're now saying, you know, versus a formal prescription of here's what you need to do and a set of rules, you're saying, well, you have the ability to do this, but it's incumbent upon you to do it. You got to combine that with this understanding of the strategic context so people know, you know, what to do. And so those things kind of come together on how you replace, I call it prescription and compliance in terms of what people do. And then the next points around, you know, meritocracy versus positional power and minimal bureaucracy versus fiat decisions are, well, how are disagreements arbitrated or how are decisions made? And again, trying to say, let's not do it, you know, the highest paid person in the room. Let's try to make sure the right sets of dialogues happen. You know, those are the vehicles to do it. And yes, they're cultural elements, but they're actually replacing the cascading decision rights that you would see in a normal organization. So I think a lot of the things that you see naturally gel together, whether it's Red Hat or HubSpot or Netflix or others, because you actually literally are replacing other, you know, kind of traditional management processes and functions with something different. But if they don't hold together, you know, again, if you have, you know, kind of this minimal bureaucracy but people don't actually have the right set of conversations or you don't have the right set of kind of drive around ownership, then again, you kind of get chaos, decisions aren't made, things get pushed out. So these things kind of almost have to go together. And we talk a lot about, at least inside of Red Hat, about the tension between these things. Like again, you can't have autonomy without accountability or again you have chaos, right? So it's these things generally kind of have to work together and, you know, kind of a set of bundled things. And I do think there's a sense with a lot of companies about, hey, I just need to give people more freedom. It actually doesn't work that way. This idea of candid discussions, you actually find the direct opposite. You tell people it's okay to have a candid discussion, most people are too nice, they don't want to have hard discussions. So how do you actually get people to go have the hard discussions? And I tell you, and we can go into it whenever if you would like, but, you know, that was one of the really difficult things to go do at IBM, where talking back to authority was just not something people did. And so we really had to think hard about how we specifically intervened to make some of those things happen. So I can talk about that now, I can talk about that later, but those are the types of things where you can't just say I'm going to give people more autonomy, all right, wash my hands and go away. There's a lot to go with that to actually get the effective, full, you know, kind of management processes working.

So IBM, we did several things. So one of the first, I mean, some of these you're going to laugh because they almost sound trivial, but they made a big difference. So one is we mandated that everybody leave 30 minutes at the end of their staff meetings free for open dialogue. Because one of my observations early on was when you tell people, hey, if you have something, bring it up, let's talk about it, if they have to actually go schedule time with their boss to bring it up, you've created a hurdle that makes that hard. And IBM, I guess you could argue, was great. I mean, they would run these meetings down to the second with long checklists and all this stuff, and, you know, but you never left any room to be able to bring up issues like, hey, I've seen this in the market, how do we talk about that? So we did that and it was amazing the feedback we got. It's like, oh my God, we can actually talk about it. And then people started creating even more time because again, if you're continuing to drive forward in something, you know, and the world never changes, you don't need as much space to have those conversations. When things change, where does somebody saying, hey, I'm not sure that's effective anymore, and let's go talk about it. And so kind of creating that space to make it easy was one. Number two, I really, really, not just me, but getting multiple executives to model and celebrate when people would kind of come up and say something. I used to go out of my way. I remember this one time I'm doing kind of an all-hands, so there are, I guess, tens of thousands of people on the call, and I just said, and look, I wanted to make the point, but I also wanted to emphasize beyond the point. I said, you know, I was walking down the hall the other day and someone pulled me aside and said blah, blah, blah, blah, blah, blah, blah. And I was hurrying on to a meeting so I kept walking, but I really reflected on it and how insightful that was and it changed the way I thought about blah, blah, blah. Well, a, that person, the next time I saw them was like beaming, like, I can't believe you remember that conversation, you announced it to the whole company, etc., etc. But it also got people to say, oh, it's actually okay to pull someone aside. And it's not just okay, it's like, man, maybe I make an impression that actually changes kind of what they do. And so trying to talk about those things are incredibly important. So multiple kind of things like that, you know, and again, trying to talk about times where we've made a mistake. So you say, well, you know, I wish I'd done this differently or I could have done this better and here's what I learned. And just as you talk more about it, you kind of make it more kind of visceral that it's okay. The other thing, I mean, I tell you, going straight from Red Hat to IBM, I mean, you could see it. I would walk into a room at IBM and if I walked into a room at Red Hat, I was like anybody else in the meeting and people would be happy to disagree. I'd walk in a meeting at IBM, first off, there's a little bit of a stunned silence and then everybody tries to say, okay, what kind of mood is he in? And then it's like they want to structure things around what I want to hear. And I used to say, and I would actually do this to make a point because I used to do it at Red Hat, is like, look, I'm here because I want to have a dialogue around this and if we get a monolithic culture agreement around this, I'm going to take a point that I may disagree with just to argue the other side so we hash out all the points. So don't assume what I'm saying in a meeting is what I believe. I'm going to advocate a position to get the dialogue going. And so when people kind of got used to that, then they were more willing to disagree with me because they didn't necessarily think they were quote unquote disagreeing with me, they were taking another side. And so really doing those types of things to get people kind of used to dialogue is key. But a lot of it really is celebrating people who are willing to do it and thanking people when they give you tough feedback, which is hard. So especially in meetings when somebody would bring something up, say thank you so much, that was really, really valuable. All those things go a long way to getting people kind of more comfortable doing that. And then as your reports do it, they start doing it more. And, you know, we actually kind of again rolled out a set of programs around this and took executives through it to get people more used to that kind of set of ways of working. I don't want to say IBM fully got there. I mean, IBM still has a ways to go. It's a work in process. But those are examples of things. Now, if leaders aren't bought in, it's not going to happen. And that's one of the biggest issues is, you know, the simple way I would say it is change management happens in the decision-making process. So all of those things are painful versus saying just go do that. But because you've heard people's opinions and you've kind of taken all that into account, once you've made a decision, you've already heard all the disagreements, you've already hashed it out, people feel like they've been heard, so execution goes pretty quickly. But at times it feels like you're in this morass of decision-making and it's really easy for executives to say, I'm going to be decisive, go do X. But the reason there are management consulting firms who have massive change management practices is because a lot of companies go and say, we're going to go do X, now let me go convince people that was the right thing to do. And I don't know about you, how many of you are in a relationship with somebody, but if the person you're in a relationship with says, I've made a decision that we're going to go do X on our next vacation, I hope you're excited about it. Even if it's some wonderful trip you want to do, you're probably a little pissed you weren't involved in the decision, right? And so this idea that you then have to convince people that this was right, and honestly, oftentimes a decision will change a little bit when you've involved a broader group in actually making a decision. But even if it doesn't change, that when people feel like they've been heard, their opinions at least been considered, even if you do something different, that's okay. But for an executive, when you're going through the process, you're like, this is inefficient, it's taking a long time, it's emotionally taxing because people are telling me I'm wrong and I'm trying to defend this. But if you don't do it, it's just going to all happen in the execution, which is more expensive and takes longer and it's a bigger problem. But again, all that around to say, you have to have executives that believe that there's value in doing it.

Yeah, and you know what, I think that's a good point. We on purpose didn't use the word leadership in the book. And because I do think it's more systemic than about an individual and what an individual is doing or even about a team of leaders are doing. Leaders have to be on board, but it's how do you make systemic change. And that's why I call it organization. It's a way to organize. And that has to do all the things that a normal organization would do, you know, in terms of a control function and rewards and direction setting, etc., but in a different way, which is why we call it The Open Organization and not something around open leadership or anything around that. One just contextual story, let me tell really quickly, and I will get into it. One of the reasons we definitely didn't want to use the word leadership was early on at Red Hat, one of the things that I observed is we had this, I call it broad, you know, playing a role in open source, but we didn't have like a really crisp mission statement. And so I kicked off an effort to develop a mission statement. And we had, especially developers, or passionate open source, got really, really involved in this and others. And, you know, we had a small team that was collecting input. And so we ended up coming up with our first draft which said our mission statement was to be the leader in, you know, let's see, how exactly did we do it, because this isn't what we use, the leader in communities of contributors, partners, and something, building better technology the open source way. And so we put that out there and some of the most passionate people in the company and that worked in this said, that's not right. We don't, we're not leaders. We don't have any real full control on these things. That's just not correct. And so we came back with the second draft and said, okay, we are an active participant in communities of customers, contributors, and partners building better technology the open source way. And that same group says, we're more than a participant, we're driving direction. I'm like, yeah, but we said leader. And so finally one of the engineers, and so he can, a little geeky, came out and said, well, we're really a catalyst. And so if you think about what a catalyst is in an experiment, is because of the catalyst, the reaction happens. And if it weren't for the catalyst, the reaction wouldn't happen. So a catalyst is really, really important, but the reaction happens because of the other participants. And so our mission statement ended up being, you know, our mission is to be the catalyst in communities of customers, contributors, and partners building better technology the open source way. But when you kind of think about that role as a catalyst, you know, one of the examples I think I use is it's a little bit like if you put a post in a lake or in the ocean, all of a sudden a set of teeming wildlife will build around that. And it wouldn't if the post wasn't there, but you're not making any of the wildlife go do that, it just naturally kind of does that. So I think about what you are as a leader is how do you build the scaffolding for the right things to happen because people want to and it's logical, makes sense. And so, you know, the highest level way I would say it, and I didn't develop this line until after the book, is, you know, a leader's job is to create the context for people to do their best work. So again, a lot of this comes down to how do you create a context where these things happen. And of course, by creating the context and the way you're putting the poles in the water, you're determining kind of what develops. But it's more indirect. Or another analogy you often hear is it's a little bit like a perennial garden. And as the gardener putting it together, you are putting things certain ways to help things grow, but, you know, you are catalyzing that garden growing, you're not ordering something or able to do that. So if you think about some of the big, big, big, broad aspects of that, one is importance of purpose and people really believing that they are part of something more than just, you know, a P&L on a quarterly basis. I do think that's critical. All the way back, some of the things we talked about about autonomy and accountability, and I would actually go, there's a third level of true ownership there. Like, how do you get people to say, okay, I have to own this, it's important for me to go do it. Which, so there's kind of the whole purpose piece. There's then how do you get people to really kind of think about ownership. And quick example of that, just as an example, is, you know, as Red Hat started to scale, you know, we were bleeding edge of technology. The problem that often happens with companies at the bleeding edge of technology is they don't listen to their customers enough and they drive off a cliff technologically. So great technology, but it doesn't meet customer problems. Sun Microsystems, a prime example of that, incredible technology, fell off a cliff. The flip side is if you listen to your customers too much, you can, and honestly, this is one of IBM's big problems, you also don't deliver anything new and innovative because your customers probably aren't coming up with something new and innovative. So you got to do both. And so I used to talk about this at a corporate level and I started doing this in, you know, kind of company meetings and people are talking more and more about it. Well, then without me trying, you know, the senior vice president group, which would have been one level down below the EVP group, got together and created a customer council with various people across the organization. Our customer support organization carved out 4% of their budget to start and had a group that started doing outbound calling. Somebody found budget to go institute a net promoter score program. So all those happened not because I created a working group that said, hey, we need to go figure out how we're going to be customer focused yet continue to be bleeding edge on technology. Smart people across the organization said, well, Jim said it's important, so we better figure it out, right? And they, we didn't go create budget for it, people figured out how to do it within their budgets. So again, this idea of ownership, nobody else is going to tell me to do this, I got to figure this out. And building that kind of sense in the culture, and part of that is celebrating those things, talking about those things, but holding people accountable. It's like, hey, we said this is important, why isn't this in your plan, right? So it's kind of both sides around that. So I'd say kind of purpose and culture is key. I think the messaging that you're sending in terms of your expectations around people speaking up and the level of debate you have and continuing to drive that forward. We created something called the open decision-making framework which we trained everybody on, which was very clear about our expectations. One of the other things we did, I'm just kind of talking out loud on these because I didn't kind of put together a full list, but we always talked about on our best day we do X, because it's always easy to find counterfactuals where somebody didn't do something the way we would like them to and would say, yeah, you know, we're human and that happens. You know, the analogy would be you can have a perennial garden and the gardener, somebody else can walk right through the middle of it and step on everything and it'll come back. Too many people step on it too long, you kill it. But I think it's okay to recognize that we're not all perfect, at times we make mistakes. And so recognizing that, I do think how we hired and how we brought people in. So as we said, like roughly half or more of our employees, actually I didn't say in the book, it talks about over half our employees came from employee referrals. And we spent a lot of time on that and celebrated people. Anybody who over their career referred more than five people, I sent a personal note to. You know, so we really tried to say nobody knows a Red Hatter like a Red Hatter and pick people who fit. And we tracked how good people referred and how well they did and coached people on it. Our new hire orientation was basically a cultural inculcation more than, new people come out like, I still don't know how to get my laptop, but man, I know the history of open source and why you people are so passionate about it. So working to build those things. Our leadership development program, we had, I'll say the regular kind of set of things you would do with competencies and competency models, but we then had an overlay called the Red Hat multiplier, which are five things we would also rate people about associated with culture. So across all these processes, where it's new hire, how we hired, how we brought people in, how we assessed, those are all things which give us cues to not only kind of drive the purpose but also behaviors in a way that ultimately help people be kind of consistent against that. From the top down, you know, as leaders, there were people that were frankly listened to more even if they were individual contributors because, you know, they were respected. And honestly, that's one of the things I found quite interesting. A lot of times I would see at IBM people would say, well, I don't really want to be a people manager, but that's what it takes to move up in the organization. At Red Hat, there was much more of a sense of, oh, I can have more influence as an individual contributor because, you know, Jim will call me to ask for my opinion on XYZ area before he's going to go do something. And so those types of discussions, or those types of kind of phenomena can kind of exist when you work to kind of build that out. But I think it really does start with thinking about purpose and those things and then how you build all of the processes and systems that support that kind of culture that you're looking to build.

Can I tell a quick story on that though? This is an analogy that it's not in the book, but I use a lot, but I think it's a really apt analogy. I'm sure most of you took Economics 101 in college. And if you remember this, this is classic, you know, there's an upward sloping supply curve, downward sloping demand curve, where price and quantity fall, that's, you know, kind of equilibrium, blah, blah, blah, blah, blah. And like in one of the last two lessons of a semester, you know, the professor finally says, well, this is all theoretical, but it assumes everyone is rational and there's perfect information and those things never really exist, but we had to do that to make the math work. Well, there's now a whole new set of economics, an economic departments called behavioral economics, and this relaxes those constraints. And like Dan Ariely, if you've read some of his books, Daniel Kahneman, so there are all these economists who are now writing books specifically on the...

There are systemic biases that people have, but there is no new general theory of economics, and there's certainly no general theory of behavioral economics. The reason is, as soon as you relax the constraint that people are always 100% rational, the math gets too hard. So I do think, back to your point, the reason there's not a fully formed new thing is, in the same way there's not a newly formed full canon around economics in a world where you say markets aren't at equilibrium, we don't have perfect information, and people aren't always economically rational because the math is too hard. It's funny you said at least on my book that you thought there was some generalization in there. I try to be very specific, to try to put a framework to describe and not necessarily a framework to prescribe, if you know what I mean. Because I do think different people are doing different things. I don't want to be arrogant enough to say do what we do at Red Hat, because that may or may not be right depending on the context and circumstance.

The other example I'll use on that, which I think is really kind of apt, is I came from Delta Airlines, went to Red Hat. At Red Hat, we loved people experimenting, trying new things. At Delta, on the web app or the mobile app that you used to check in, yeah, we want people to experiment, try new things, agile, etc. You do not want anyone experimenting with the safety procedures before your flight. You follow that, and if you don't follow it, you're fired. Period. Full stop. So depending on what the context is, you got to think about different guardrails. That's why I say I don't think there is one right way to manage or lead. I think there are better cultures, leadership styles, processes for different outcomes you're looking for. And again, safety procedures before a flight versus feature development in software are just fundamentally different.

I think I know where he's going with that, so I'll try to answer even though I don't know for sure. But yeah, no, I do think there's this idea of if you break out kind of components of a management system, there's how do you determine direction, right? And then how do you coordinate people to make sure they're doing the right kind of sets of activities around that? How do you arbitrate decisions getting made? And I guess one could argue whether it's separate or not, how you incentivize people to do those sets of things are the same. You have to do that if you're trying to organize a lot of people towards a common goal. Sorry, I was hopefully answering your question, not sure if it was exactly right, but what I was saying is I think a little bit is that there is a scaffolding because this idea of how do you motivate people, how do you coordinate behavior or coordinate thousands of people to ultimately get to an outcome, how do you arbitrate disagreements, how do you observe and ultimately decide to change, all those things need to be in any management process or system. And so that's true in these, I'll call it more organic, agile type systems as well.

Yeah, well, I mean, especially first coming into Red Hat from outside of Red Hat, lots and lots and lots of kind of concern. It's like, you know, what's this airline guy doing? Is he going to kind of kill us? And some of it you work through over time. So I think you have to have a set of principles that you kind of work and live through, and then you got to be able to modify. For example, I felt very, very strongly because it worked at Delta, we can kind of come back to that, that we needed to have strategy on one page. Because one of the feedback I got at Red Hat is people are passionate about open source but didn't quite know what we were doing. And one of the things that works so well at Delta is we put together a strategy on one page. So I said, look, we're going to do this and we're going to hammer it home, everybody's going to know what it is. And people thought I was kind of... on the senior team, you know, thought I was crazy and it was a waste of time. We spent six months, we put it together, that one pager. Five years later, everybody knew, and five years later is the first time we actually changed it. And everybody knew it was the house because it had a triangle at the top with the mission and the stuff. And so we're putting an addition on the house, and so the whole organization talked about the house and the addition on the house, and everybody kind of knew it. And it did help us kind of get people to understand below the purpose to actually understand what we were all doing and help guide decisions. That's one I just had to go force and pound away and pound away on. It happened. Another is I said, oh my God, we do not run a really decent management cadence, and I know how to do this because I did it at Delta, first flight performance, etc. So I put together a very rigorous kind of management system that we went through monthly. About three months in, I finally look around and say, okay, this is crazy, you all are right, this isn't how we run the place. And the simple thing is, for Delta, thousands of flights flying every day, and so first flight performance, our crews, mechanical dispatch reliability, all of these things that go into that, you could do every single day. When you're releasing software, we get together twice a week and it's like, yeah, we're still planning on releasing that in five months, no more update. Yeah, so there just wasn't enough for a cadence like that. And so that's one where I said, you know what, you're right, put it together, you were right. So I think you have to have some degree of conviction but then be willing to admit, yeah, that didn't work, that was wrong. Sometimes you're right, sometimes you're wrong. Was right about needing to lay out the one page, or totally wrong about the management system. So to some extent you have to kind of push and advocate and then you make some decisions and you ultimately walk some of those things back. So I do think you have to have some degree of conviction but you got to be able to have them relatively soft unless they're around values or other things that you feel super, super strong against, and modify as you go forward.

That's tougher when you get into people, because I will say one of the biggest issues that can screw this up is having people that don't kind of fit that mold. If somebody's off 20% of the time, again, this idea of well, on our best day we do XYZ, but we don't always have best days. The problem is as soon as somebody has 80% of not best days, it gets tougher because people do often say, you know, look at who gets promoted and that's the values that a company cares about. So there were people at times you could actually argue that they're an individual contributor in this extraordinary way and we continue to work on this person, this isn't what we want. But if it's somebody who manages a lot of people, it gets a lot tougher to make that argument. I mean, it's one of the reasons we actually assessed against it and if people fell low on that, we didn't keep them. Now the other way to look at it, which I do think happens, is different parts of an organization can use different styles. Again, going back to that Delta analogy, they had a safety, you know, not a squishy kind of let's try a bunch of things people. The people in development, much more so that way, much more kind of creative. So the other kind of piece that I found worked when you had different styles, what we'd often get is, well, this function doesn't seem to live up to as much as this function. And somebody in accounting would be like, well, I don't have as much creativity. It's like, no, you don't have as much creativity, and there's a reason, because I go to jail if our SEC reporting is off. So yes, no, your job is to make sure. So you can have people in certain functions if that function isn't a place that requires as much, and be very, very clear, it's like we do different things and those different things do require more or less. Now you have to have an overall set of values and culture, but how those are manifested by a leader can vary depending on, again, the importance of or the consequences of making a mistake, like where can you experiment, where can you not, etc. So you rarely have a super touchy-feely CFO, and that's okay. But if you have somebody in a keyline role where they need to do it and they're not that, honestly, that gets really, really hard.

Well, a couple things, and you're right on the point, it actually is tough. Some of it is got a broad-based program. So we had a bit of that at Red Hat, so we made every people manager go through a Crucial Conversations set of training, number one, to make sure that we work to kind of drive that through. And then, frankly, in various meetings that we were all in, we all tried to model a behavior of having tough conversations back and forth with each other. And I would laugh about it and talk about it, and especially my number two, Paul Cormier, and I used to frankly yell and scream at each other. We were probably beyond what would be considered appropriate, but we had worked together for so many years, we're like an old married couple, we could scream at each other and walk out friendly. So we probably took it a little too far personally, but we did let people see enough of that to kind of know that that was okay, and we talked about the importance of doing it. And you got to celebrate. I'll give you an example that I used to talk about. So my second week on the job at Red Hat, I'm still getting up to speed and I'm just out of Delta Airlines. I'm getting briefed on this area of technology called virtualization, which was brand new back at the time, this is 2008. And the head of all of engineering and the CTO, and then the person who worked for him who ran that area, and then a whole bunch of people, multiple layers in the organization, are briefing me on our strategy. And they're almost done, and one of the engineers in the room says, I just have to say, I know this is our stated strategy, but it's completely, totally wrong. We picked the wrong technology, we are going down the wrong path, this is shortsighted, this is crazy. And this massive argument ensues in the meeting. We get done and everybody walks out happy, and the engineer who said this and his boss's boss is putting his arm around him and they kind of walk out friendly. A couple of observations there. One is the importance of afterwards them walking out friendly, so he didn't have to say it at the time, but saying thank you so much, I really appreciate that dialogue. The important part to me of that story is I remember going home and telling my wife I'm in crazy town because I can tell you at Delta, if an engineer in front of his boss's boss's boss's boss and his boss's boss's boss's boss had said what we're doing is completely wrong, that person would have probably been fired by the end of the day, if not killed by the end of the meeting. You just wouldn't have done that. But what was really interesting about that story, about four months later, that same group came back in and said, you know what, our strategy's wrong. We actually need to go... it's the strategy the other guy talked about. There's circumstances that have changed and we need to buy that company and it has another offer, so we got about two days to make this decision. You got to go to the board and tell them you want to spend several hundred million dollars buying that company. Now, if I had just gotten a brief on here's what we're doing and why and why it's the right thing to do and didn't hear all the other dialogue that it was kind of a 60/40 decision that then flipped, I would have looked at people and said, no way, you're out of your mind, I'm not going to do that. That technology ended up being incredibly important to the future development of Red Hat, all the way through for why when we were bought it was the largest software transaction in history. So it was a crucial, crucial thing that if I hadn't heard that argument, we wouldn't have made. And I tell that story a lot internally so people know it's important to do that. I highly encourage people to say thank you around the debates and we talk about how important it is. One of the things we also did kind of broadly, which I used to broadcast, is like if you say something and people just kind of nod or don't argue with you, that's the biggest insult. That means they didn't think it was worth arguing with you about. And there's no way you're going to say something that people are going to say that's perfect, that just doesn't happen. So the worst you can do is not garner kind of criticism, push back, some degree of debate around what you're doing. So you should be proud of the fact that you generate that, and for others, you should feel good about pushing back because you're actually complimenting somebody saying this is worthy of my time to kind of criticize and debate. So some of it's again the basic skills training, people how to do it with things like Crucial Conversations was a program we used, I can't remember who did that, and we put everybody through. But then we kind of talked about the messages kind of top down and model those behaviors. It's kind of that combination, but you are on the exact right point. It's the hardest thing because most companies are way, way, way, way too nice. Delta was the worst that way. Matter of fact, if you want a good story, when we were first getting ready to go into bankruptcy, we're talking with the bankruptcy advisers and we're kind of going through stuff, and one of them says, yeah, you know, I can already tell you, Delta has one of those cultures that we've seen before. It's called terminally nice, and it's so nice that you never have the hard conversations, so you never make the hard change until you go into bankruptcy and then you have to. And there's something I've always remembered, that terminally nice, if you don't kind of address the hard things, you can end up in really bad circumstance. I don't know if that was helpful, but a few thoughts.

So I'm a little torn on this, and let me kind of walk through why. Without a doubt, being in person is better. I think you have just a richer dialogue and the ability to talk and have that kind of multi-visual cue, audio cue kind of when people are together. But a couple of observations. Red Hat started off as a very remote company, we always were, because we used to hire developers wherever they were around the world and we didn't ask them to move because a lot developed a reputation in an open source community, then we wanted to hire them. So it's not like we hired them and then slotted them in. We often hired people and they were expats or they had families and they didn't want to move, so we were always kind of remote. So we always worked to build systems to build our culture in a remote environment. We had something called the show, so we literally had a hired video crew, they were part of our internal comms, who would go around the offices record people and things people were doing, and we had like a show. It was once a quarter, it was about an hour, and it highlighted people who were doing things that kind of lived up to our culture, whether it was an office doing something or an individual and what they did with customers. And we made it funny and fun, and when they came out we always had viewing parties at all the offices. If you were at home, we'd all watch it together, so people would be on video and we'd have pizzas and beer. One example, the way we did our company meetings, all with video. We always kind of did a set of offsites. So we built a whole set of structures to inculcate our culture in what started off as a remote environment. I think the problem is a lot of companies started off where much of their culture and the cultural cues came by people being together, and then people went home but you didn't replace them all with a bunch of other structures and processes to inculcate culture. And if you don't do that, then it just kind of falls apart. So we also were very... I think we fell into this, so I don't want to say we were smart about it because we were more lucky about it. We learned over time that depending on, I hate to use the term, the API that people used, how people interacted, did it need to be super rich or not. So we found marketing people had to be together, like all the marketing people were together in our headquarters, because you had this really rich API between marketing people where people were at whiteboards and talking and gesturing and doing all that stuff. Developers are sharing code, that's a pretty arbitrary API, and a lot of those people, because they were introverts, they honestly didn't want to get on video. They would use this like IRC, which is this tech-based chat, and they would look at each other's code, and that was a great API for what they were working on. So I think getting smarter with who needs to be together and who doesn't also matters. So again, what I would say around all of that is you have just been a while building up a whole set of mechanisms, processes, I would call it video heavy, not just video conference, but like literally how you're highlighting what's going on in the company that supports your culture, and you need a whole program around that if you're going to be more remote, or you need to bring people back. I bias slightly to bring people back, but Red Hat was pretty remote and it worked incredibly well. But again, we spent 10, 15 years developing a system to be able to do that.

Right, and so that's what I tell you, this idea of doing the quarterly video, and they were hysterical, and I'd have to make a fool of myself and some others, so they made it you really wanted to watch it. It wasn't some dry corporate thing, I mean they were like rolling on the floor laughing out loud kind of things that they would do every single quarter, but it would highlight a person and what they did or an office and things they were doing. So one example of just myriad things that we did to try to do that. But I do think it takes a while to develop all of that. So to me, mandating people coming in is easier, of course.

I'm going to try to tell a story really quickly if I can to end. This was the most impactful night of my life and completely changed how I lead. So I was named Chief Operating Officer at Delta about eight weeks before he filed for bankruptcy. I was 35 years old. I'd been a strategy consultant, I'd had staff jobs in finance and running the network, and basically had to lock myself in a room with consultants and bankers to put together the plan. I'd spent no time talking to employees at all. I mean, literally, we were trying to raise money. When you go into bankruptcy, you raise something called a DIP loan to survive while in bankruptcy. So I've spent forever doing that. And the day we filed for bankruptcy, somebody asked, hey, could you go over and maybe chat with some of the mechanics after you're done with the day? And I kind of forgotten about it, and somebody mentioned that to me, it's like, hey, you know, you said you're going to go over to the break room if you still have time. Well, this was unplanned, unscripted. I go over to a break room. So I'm 35 years old, I now have 80,000 people working for me, but I'd never had big groups, I was a staff person. And all of a sudden I have 80 people sitting in a break room looking at me thinking, and I got to figure out what I'm going to say. So it's night shift mechanics, they're all going to get laid off because they're the most junior mechanics, and I had no idea what I was going to say. So I just said, look, I'm sorry, let me tell you about the plan and what your sacrifices are for what we're trying to build. And then I turned on and gave the exact same pitch I've been giving to creditors to raise our DIP loan for the last six weeks, because I could literally do it, I'd done it a hundred times. So I do this for about 40 minutes and I stop, and there's this stunned silence. And these mechanics, then rather than saying, well, when am I going to get laid off or what's my... people started saying things like, but if you're going to move that plane to international, do you actually have enough galley space there or lav capacity? And okay, well, can that actually do this mission? So they started asking very mechanic-y questions about the strategy. So I go home, I wake up the next morning, and so this was 2005, the iPhone came out in 2007, so my pager is blowing up and people are saying, look, we don't know what happened, but it's like going across the company that you came and told people about the strategy of the company. So I end up canceling the next couple days, going hangar bay by hangar bay, walking through the pitch. And it was like literally, there's nothing proprietary about it, it's how we're going to move planes international and downsize this and how we're going to redo the leases and all that stuff. And people just latched on to it. And so pretty quickly people started asking, as you can imagine, what can I do to help? And so we said, look, get the planes out on time if nothing else. We ultimately modified to save, clean, on time. Between September when that happened and January, Delta went from dead last in on-time performance to number one among the major carriers and has basically held that ever since. We did nothing but lay people off and cut their pay and benefits, but people wanted... now they had context for what we're doing, they all wanted to have a piece in saving the company. And we told them, get the planes out on time. And so people thirst for that. Later on, we end up calling this the Velvet Rope Tour and ran all the flight attendants through it and made it more structured. I remember some people coming up to me and saying, I have no idea what you mean by local flow mix and all these other pieces, but I appreciate the fact that you respected me enough to spend time to tell me about it. And I will say, this idea of where we're not going to let Delta fail on our watch, this is the strategy, this is what we're doing, creating that context is super, super, super, super, super important. And that's why we talk about knowing purpose, making sure people know the context of the strategy. It's not just that they make the right intellectual decisions, they become much more emotionally engaged and intellectually engaged in the company and therefore perform better. And that's why I think Delta kind of came out so strong. It's still... I'm on the board of United, shouldn't say, but Delta is still the best major airline. And I think a lot of it kind of comes down to a very engaged workforce who knew the strategy. So coming around to making sure people know that, I would just leave with that last message.

Yeah, happy to join. It's nice to meet you all and enjoy the conversation. Thanks.