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, it is interesting because I think we all kind of came up a little bit separately and all developed a similar set of working norms. My view of this is very simple. It's what we are doing, and that's why when I called the book The Open Organization, it is about how we are organizing a company to get something done. That's like how do you figure out what to do, how do you arbitrate disagreements, how do you have a control function, etc. So if you want to say that some of those things are being replaced or augmented from a traditional management system, those are the elements. So something like autonomy with accountability, I'll pick one of those. I think there's this real drive around autonomy, 'let's give people more ability to make decisions,' but honestly, if people don't feel accountable to actually go do that, you've just created chaos. So if you're trying to say, '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 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 the horrible Dr. Dao incident, where a passenger was dragged off a plane, coming out of that, one of the things that United worked on was saying, 'It's never wrong to do the right thing.' So let's give people more autonomy to make decisions in the moment. But the response to that was people were frozen because they were saying, 'Wait a minute, what if I make a decision that later on turns out to be wrong?' So because you didn't create this sense of accountability, people were scared to do something, and nobody did anything different. So just giving autonomy either creates a lack of action or a degree of chaos if you don't also have accountability. You put those things together, and you're saying, versus a formal prescription of 'here's what you need to do' and a set of rules, you're saying, 'You have the ability to do this, but it's incumbent upon you to do it. You've got to combine that with understanding the strategic context so people know what to do.' So those things come together on how you replace what I call prescription and compliance. Then the next points around meritocracy versus positional power and minimal bureaucracy versus fast decisions are about how disagreements are arbitrated or how decisions are made. Again, trying to say, let's not do it by the highest paid person in the room; let's try to make sure the right sets of dialogues happen. 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 are literally replacing traditional management processes and functions with something different. But if they don't hold together, if you have minimal bureaucracy but people don't actually have the right set of conversations or the right drive around ownership, then you get chaos, decisions aren't made, things get pushed out. So these things almost have to go together. We talk a lot at Red Hat about the tension between these things. You can't have autonomy without accountability, or you have chaos. So they generally have to work together as a bundled set of things. And I do think there's a sense with a lot of companies that 'I just need to give people more freedom.' It actually doesn't work that way. This idea of frank discussions, you actually find the direct opposite. You tell people it's okay to have a frank 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? That was one of the really difficult things to do at IBM, where talking back to authority was just not something people did. So we really had to think hard about how we specifically intervene to make some of those things happen. I can talk about that now or later, but those are the types of things where you can't just say, 'I'm going to give people more autonomy,' wash my hands and go away. There's a lot to go with that to actually get the effective management processes working.

So at IBM, we did several things. Some of these you're going to laugh because they almost sound trivial, but they made a big difference. 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, 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 things.' And then people started creating even more time. Because if you're continuing to drive forward in something and the world never changes, you don't need as much space to have those conversations. But when things change, you need somebody saying, 'I'm not sure that's effective anymore, let's go talk about it.' So 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 come up and say something. I used to go out of my way. I remember this one time I'm doing an all-hands, there are tens of thousands of people on the call, and I just said, 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, 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, that person, the next time I saw them, they were beaming. They couldn't believe I remembered that conversation, announced it to the whole company, etc. But it also got people to say, 'Oh, it's actually okay to pull someone aside, and it's not just okay, maybe I can make an impression that actually changes what they do.' So trying to talk about those things is incredibly important. Also, trying to talk about times where we've made a mistake, so you say, 'I wish I'd done this differently' or 'I could have done this better, and here's what I learned.' As you talk more about it, you make it more visceral that it's okay. The other thing, going straight from Red Hat to IBM, you could see it. I would walk into a room at Red Hat, I was like anybody else in the meeting, and people would be happy to disagree. I'd walk into 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 they want to structure things around what I want to hear. I used to say, and I would actually do this to make a point, 'Look, I'm here because I want to have a dialogue around this. If we get a monoculture of 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.' When people got used to that, they were more willing to disagree with me because they didn't necessarily think they were disagreeing with me; they were taking another side. So really doing those types of things to get people 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. Especially in meetings, when somebody would bring something up, say, 'Thank you so much, that was really valuable.' All those things go a long way to getting people more comfortable doing that. And then as your peers do it, they start doing it more. We rolled out a set of programs around this and took executives through it to get people more used to that set of ways of working. I don't want to say IBM fully got there; 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. 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 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 an executive to say, 'I'm going to be decisive, go do X.' But the reason there are management consulting firms with 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, 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. But even if it's some wonderful trip, you're probably a little pissed you weren't involved in the decision. So this idea that you then have to convince people that this was right, and honestly, often times 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, when people feel like they've been heard, their opinions at least considered, even if you do something different, that's okay. But for an executive 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 is a bigger problem. Again, all that to say, you have to have executives that believe 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, because I do think it's more systemic than about an individual or even a team of leaders. Leaders have to be on board, but it's how do you make systemic change? 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 in terms of a control function, rewards, direction setting, etc., but in a different way, which is why we call it the open organization and not something around open leadership. One 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 broad playing a role in open source, but we didn't have a really crisp mission statement. So I kicked off an effort to develop a mission statement, and we had especially developers who are passionate about open source get really involved in this. We had a small team collecting input, and we ended up coming up with our first draft which said our mission statement was to be the leader in communities of contributors, partners, and something building better technology the open source way. We put that out there, and some of the most passionate people in the company said, 'That's not right. We're not leaders. We don't have real full control on these things. That's just not correct.' So we came back with a 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.' So finally, one of the engineers, and he can be a little geeky, came out and said, 'Well, we're really a catalyst.' If you think about what a catalyst is in an experiment, 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 important, but the reaction happens because of the other participants. So our mission statement ended up being: our mission is to be the catalyst in communities of customers, contributors, and partners building better technology the open source way. When you think about that role as a catalyst, one of the examples 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 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 and makes sense. The highest level way I would say it, and I didn't develop this line until after the book, is a leader's job is to create the context for people to do their best work. So a lot of this comes down to how do you create a context where these things happen. By creating the context and the way you're putting the poles in the water, you're determining what develops, but it's more indirect. Another analogy you often hear is it's a little bit like a perennial garden. As the gardener putting it together, you are putting things certain ways to help things grow, but 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 broad aspects of that, one is the importance of purpose and people really believing that they are part of something more than just a P&L on a quarterly basis. I do think that's critical. All the way back to some of the things we talked about about autonomy and accountability, and I would actually go there's a third level of true ownership. How do you get people to say, 'Okay, I have to own this, it's important for me to go do it'? So there's the whole purpose piece, and then how do you get people to really think about ownership? A quick example of that is as Red Hat started to scale, we were at the 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 is a prime example—incredible technology fell off a cliff. The flip side is if you listen to your customers too much, 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've got to do both. I used to talk about this at a corporate level, and I started doing this in company meetings, and people started talking more and more about it. Then without me trying, 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. 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.' And they 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've got to figure this out. 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?' So it's kind of both sides around that. So I'd say 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 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 we would say, 'Yeah, we're human and that happens.' 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. So recognizing that. I do think how we hired and how we brought people in. As we said, roughly half or more of 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. So we really tried to say, 'Nobody knows a Red Hatter like a Red Hatter,' and pick people who fit. 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 learn about us.' 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 the regular 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—new hire, how we hired, how we brought people in, how we assessed—those are all things which give us cues to not only drive the purpose but also behaviors in a way that ultimately help people be consistent against that from the top down. As leaders, there were people that were frankly listened to more even if they were individual contributors because they were respected. 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 Jim will call me to ask for my opinion on XYZ area before he's going to go do something.' So those types of phenomena can exist when you work to 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? This is an analogy that's not in the book but I use a lot, and I think it's a really apt analogy. I'm sure most of you took Economics 101 in college. If you remember, there's an upward-sloping supply curve, downward-sloping demand curve, where price and quantity fall, that's equilibrium, blah blah blah. And in one of the last two lessons of a semester, 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 departments called behavioral economics, and this relaxes those constraints. Like Dan Ariely, if you've read some of his books, Daniel Kahneman, there are all these economists who are now writing books specifically on the 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 is too hard. So I do think, Don, back to your point, the reason there's not a fully formed kind of 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. So 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 apt is, you know, 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've got to think about different guardrails. So 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. 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 components of a management system, there's how do you determine direction, then how do you coordinate people to make sure they're doing the right sets of activities around that, how do you arbitrate decisions getting made, and how you incentivize people to do those things. 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. So 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 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 of concern. It's like, 'What's this airline guy doing? Is he going to kill us?' And some of it you work through over time. So I think you have to have a set of principles that you work and live through, and then you've got to be able to modify. For example, I felt very strongly because it worked at Delta that we needed to have a 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 on the senior team 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 it, and five years later is the first time we actually changed it. Everybody knew it was 'the house' because it had a triangle at the top with the mission and the stuff. So we were putting an addition on the house, and the whole organization talked about the house and the addition on the house. So everybody kind of knew it, and it did help us 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 on it. 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 with first flight performance, etc.' So I put together a very rigorous management system that we went through monthly. About three months in, I finally looked around and said, 'Okay, this is crazy. You all are right. This isn't how we run the place.' The simple thing is, for Delta, thousands of flights flying every day, 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, you get together twice a week, and it's like, 'Yeah, we're still planning on releasing that in five months, no more update.' So there just wasn't enough for a cadence like that. So that's one where I said, 'You know what, you're 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. I was right about needing to lay out the one-pager, totally wrong about the management system. So to some extent, you have to push and advocate, and then you make some decisions and ultimately walk some of those things back. So I do think you have to have some degree of conviction, but you've got to be able to have them relatively soft unless they're around values or other things that you feel super strong about, 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 fit that mold. If somebody's off 20% of the time, again this idea of '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, 'Look at who gets promoted, and that's the values that the company cares about.' So there were people at times you could argue that they're an individual contributor in an 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. 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. Going back to the Delta analogy, the safety people, not a squishy kind of 'let's try a bunch of things' people. The people in development much more so, much more creative. So the other 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 SEC reporting is off.' So yes, 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 clear: '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 the importance of or the consequences of making a mistake, like where can you experiment, where can you not. So you rarely have a super touchy-feely CFO, and that's okay. But if you have somebody in a key line role where they need to do it and they're not, that honestly gets really hard.

Well, a couple things. And you're right on the point, it actually is tough. Some of it is a broad-based program. So we had a bit of that at Red Hat. We made every people manager go through a 'Crucial Conversations' set of training, number one, to make sure that we work to 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. I would laugh about it and talk about it. 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 know that that was okay, and we talked about the importance of doing it. And you've got to celebrate. I'll give you an example that I used to talk about. 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. The head of all of engineering, the CTO, the person who worked for him who ran that area, and 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. The engineer who said this, his boss's 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. 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 is about four months later, that same group came back in and said, 'You know what, our strategy's wrong. We actually need to go with the strategy the other guy talked about. There's a change in circumstances, and we need to buy that company, and it has another offer, so we've got about two days to make this decision. You've 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 to why when we were bought it was the largest software transaction in history. So it was a 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 broadly which used to broadcast is, if you say something and people just 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 is perfect; that just doesn't happen. So the worst you can do is not garner criticism, pushback, 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 criticize and debate.' So some of it is again the basic skills training, teaching people how to do it with things like Crucial Conversations, which was a program we used. We put everybody through that, but then we talked about the messages top-down and modeled those behaviors. It's that combination. But you are on the exact right point: it's the hardest thing because most companies are way, way, way too nice. Delta was the worst that way. Matter of fact, if you want a good story, when we went into bankruptcy, we were talking with the bankruptcy advisers, and one of them says, 'Yeah, you know, I can already tell, 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.' I've always remembered that: terminally nice. If you don't address the hard things, you can end up in really bad circumstances. I don't know if that was helpful, but a few thoughts.

So I'm a little torn on this, and let me walk through why. Without a doubt, being in person is better. I think you have a richer dialogue and the ability to have that multi-visual cue, audio cue 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 of them developed a reputation in an open source community and 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 in different places or they had families and they didn't want to move. So we were always kind of remote, and we always worked to build systems to build our culture in a remote environment. So we had something called 'The Show.' We literally had a hired video crew, they were part of our internal comms, who would go around the offices and record people and things people were doing. We had a show once a quarter, about an hour, and it highlighted people who were doing things that lived up to our culture, whether it was an office doing something or an individual and what they did with customers. 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, you could 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 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 with a bunch of other structures and processes to inculcate culture. And if you don't do that, it just kind of falls apart. 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 the people used, how people interacted, did it need to be super rich or not? We found marketing people had to be together. 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, honestly didn't want to get on video. They would use 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 getting smarter with who needs to be together and who doesn't also matters. So what I would say around all of that is you have to build up a whole set of mechanisms, processes. I would call it video heavy, not just video conference, but literally how you're highlighting what's going on in the company that supports your culture. 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 so with others, so they made it so you really wanted to watch it. It wasn't some dry corporate thing. I mean, they were rolling on the floor laughing out loud kind of things that they would do every single quarter. But it would highlight a person in what they did or an office and things they did. So one example of just a myriad of 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. I was named Chief Operating Officer at Delta about eight weeks before it 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 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 forgot about it, and somebody mentioned it to me, 'Hey, you said you were 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. 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, and I've 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'd been giving to creditors to raise our DIP loan for the last six weeks because I could literally do it like 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, rather than saying, 'Well, when am I getting laid off?' or 'What's my severance?', people started saying, 'But if you're going to move that plane to international, do you actually have enough galley space there or lavatory capacity?' and 'Okay, well, can that actually do this mission?' So they started asking very mechanical questions about the strategy. So I go home, I wake up the next morning, and this was 2005, the iPhone came out in 2007, so my pager is blowing up. People are saying, 'Look, we don't know what happened, but it's going across the company that you came and told people about the strategy of the company.' So I end up canceling the next couple of days, going hangar bay by hangar bay, walking through the pitch. And it was like, literally, there's nothing proprietary about 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. So pretty quickly, people started asking, as you can imagine, 'What can I do to help?' 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 now had the context for what we were doing. They all wanted to have a piece in saving the company, and we told them, 'Get the planes out on time.' So people thirst for that. Later on, we ended up calling this 'The Velvet Rope Tour' and ran all the flight attendants through it and made it more structured. I remember some people came up to me and said, '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 '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 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 came out so strong. I'm still on the board of United, I shouldn't say this, but Delta is still the best major airline, and I think a lot of it 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.