All Things Open 2015 | Keynotes: Mark Skarpness, Sarah Novotny, Brandon Philips, and Jim Whitehurst

All right, thank you, Jason. Well, first off, let me welcome you all to our hometown, Raleigh, North Carolina. We really do appreciate you all coming to visit us. I have to say, speaking for my wife and my kids, it was really nice to be able to go to a keynote but sleep in my own bed last night and have breakfast with the kids. So we're doing more things here, and if you have time, I hope you have a chance to come visit the tower. We're about two blocks away; you can't miss it — it has the big red thing on the top. So I really do appreciate you all being here. I do encourage you to find Charlie at some point during this, listen to him. From the video, it really is a phenomenal and inspirational story. That was just a short trailer; you can go to the site that was up there — redhat.com/redhatstories — and there's the full video there. It really is an extraordinary and inspirational story about what all he's achieved at Penn Manor. I'd like to broaden the conversation, since this is "All Things Open." I'm actually not going to talk about technology today. All right, I'm already causing problems — I'm supposed to stay in these yellow lines, and I'm already outside of them. I'm always the troublemaker, which is a problem. Everybody else stayed right on time, you know. So all right, I'll try to do a better job here. So I'd like to broaden the conversation since this is "All Things Open" and talk about open as it applies to literally management, to business, and to our society. Open source is a key part of that, but I do think what we are all looking to achieve actually has implications far beyond just software. Let me start off broadly with why I think there is such a need for the principles of open source. I'm saying the principles of open source because open source itself is a license; it's about source code. Yet we talk often at Red Hat about "the open source way," which is how we apply those principles beyond technology and open source software itself. If we think about the world we've come from and the world we are entering into, it's been a long change. I'll come into a little bit how all of a sudden I recognized this change personally. But if you think about the Industrial Revolution that we came from, we have come from a world of mass manufacturing developed in the late 1800s, where we basically had — and this is simplification — relatively uneducated people, meaning most people did not have a high school degree, typically doing rote tasks. Most tasks, because the way we actually work to specialize — you know, science and management specialization — people were doing relatively rote tasks on assembly lines in a very static environment. Business and strategy changed over decades, certainly not over years, months, or frankly, it feels like weeks now. In a world where we had no information or very limited information that was very latent — if you're lucky, you had a telegraph. So basically, when we started thinking about how we develop principles of management, leadership, how we coordinate behavior, it happened in a world of a very different context: relatively uneducated people doing relatively rote tasks, static environment with limited information. If we think about where we are today in the context that we all live in, we typically have much better educated people than we did even though we need to continue to work on things like high school graduation rates. They are typically well above 80% in the US. Many of the people that we all work with as employees — probably most that we actually work with as employees — have college degrees. In a world where we've automated the rote tasks, so most tasks out there that need to be done broadly, and certainly in IT, require a degree of initiative and creativity in an incredibly fast-changing environment where we have unlimited broadband information in our pockets. So when you think about that context of the world we live in today and how different it looks from before, how we need to think about coordinating behavior, how we need to think about leadership and management, needs to change. The traditional world of hierarchy has got to open up. Let me try to talk a little bit more in detail about that. We've all seen this in technology. We've gone from a world where 75 or 80% of our effort was around sustaining and very little was about innovation — that goes in terms of both dollars and time and attention — to a world where I think most of us recognize in technology, but broadly for business, sustaining becomes less important. Our ability to innovate becomes dramatically more important. One thing that we absolutely know is that the traditional hierarchies, the closed systems that we've used to manage and coordinate activity, are really bad at innovation. Nobody says, "Give me a great bureaucracy so I can come up with something new." I think we see that happening as well as we think about how we work and become more efficient, how we move more quickly, how we innovate in information technology. DevOps is kind of the buzzword with every CIO I talk to now. Everybody's — whether it's agile for the maybe less bleeding edge or DevOps for the more bleeding edge — almost every conversation I have with CIOs now is talking about how do we move faster. What I hear over and over again is disillusionment, because everybody's figured out the joke now: it's not about the tools. Tools are important; certainly you have to have enabling technologies to increase speed, efficiency, ability to innovate. But so many companies have bought the tools, thrown them into their traditional ways of operating, and they have fallen on their face. It just doesn't happen. It's actually quite fascinating. When I now go out — and I have a great job, I have to say — I get to go out and talk to the web companies, I get to go talk to large corporate CIOs and CEOs, and I get to feel like I'm on the front line of getting to watch this change happening around us. I can say absolutely virtually everyone I talk to, there is a recognition now that something other than technology needs to change. The way we organize, the cultures that we are involved in, need to change if we're going to be able to keep pace with the faster-moving world that we live in. So I actually wrote a book about that. Let me spend just a couple minutes on it, because this is important how I actually came to this. I'm not that smart to certainly not to write a book. Actually, my English teachers would be horrified with the idea that I ever wrote a book. Plus, it's about people, and I actually — this is a true story — I failed Human Resource Management at Harvard Business School, so maybe that gives me a real reason to write a book. But no, in all seriousness, I wrote a book not about what I've done but about what I've learned. I think I've gotten probably the greatest gift that a CEO or an aspiring leader could possibly get. I'll use the analogy: I'm the frog that got thrown in the boiling water. What I mean by that is the world has been changing from this need to be efficient, prescribing kind of classic industrial-era world of bureaucracy and how we lead and manage, slowly over the last 50 years, to a world where things are moving incredibly quickly and the bureaucracies, centralized planning and budgeting, and all those things cannot keep up, nor can they do as good a job at innovating as enabling people. But most of us are the frogs that are in the cold water that slowly heats up, heats up, heats up, and you don't really realize anything's changing. I would say until I got to Red Hat, I thought I knew what management leadership was about. I used to run a large company — Delta Air Lines, which is about as military bureaucratic as you can get. And then I came to Red Hat. In my first week at Red Hat, I thought, "This is the most crazy, ridiculous place I've ever seen. It is total and complete chaos. They've obviously brought me in to clean it up." If we had more time, I could go on story after story after story. But literally, I would tell people to do things, and they would just say, "No, that's not a good idea. We're not going to do that." At Delta, literally when I drove in in the morning, there were people who would salute me. I'm serious. So this contrast was extraordinary. So again, at first I thought I need to clean this place up. Luckily, before I had a chance to do this, the organization wore me down before I could make enough change to happen. I actually realized that what we had developed at Red Hat was a different way to run an organization, but one that was extremely effective. We made several significant strategic decisions without me even being involved in that first six months. All of a sudden, I realized, "Wow, this isn't chaos. It is a different way to run an organization." The reason I'm talking about it here is it literally grew out of the open source movement. Red Hat as a company is all in on open source. We are 21 years old now, and we literally grew out of the open source movement. Red Hat is an experiment in applying the principles of open source for how you run an organization. The book's called "The Open Organization." This is kind of our definition: an organization that engages participative communities inside and out. I want to focus on two words here, because I think these are fundamental to any company that wants to move more quickly, certainly any IT department that wants to move more quickly. The first word there is "participative." We come typically from an era where employees were considered a commodity; they were price takers. Going back to the Industrial Revolution, you got paid a lot more to work in a factory than work on a farm, and people were moving from farms to urban areas. So our management structures that we developed assumed people were just price takers; they would come work, and it was easy to get people. I think we all now know, as we try to not only attract the best and the brightest but more importantly to get people to do more than just what you tell them — to actually be engaged, to be part of an organization, to go above and beyond — you need to treat your people like they are participants, like they have a choice of where they should be. I encourage any leader — and certainly this is true anyone who's been involved in open source community knows this — we talk about it a lot: why are people coming in, why are they joining? You think really hard about it, and you make the organization things that people want to join. It has to be — you just kind of back up and say, "Why are the people here? Is it for a paycheck, or is it because they want to be here?" Open source started off this way because there were no paychecks; it was getting people to do it because they wanted to be a part of things. But every organization needs to start off thinking about their people as opt-in members of a community. The second word I want to say is "engages." I've been asked simply, "If you had to put it in one sentence, what are you saying next-generation leaders need to think about doing?" It truly is about creating the context for people to do their best work. That's all about engagement: how do you create that context, how do you engage people to be part of something so they not only want to be a part of it but they know exactly how they need to play a part in that. For Red Hat, we've developed a whole system to run a company that's now 8,000 people, $2 billion in revenue this year, operating in a lot of countries — I don't know the exact number, probably 40 or 50 countries. I'm going to walk through some examples of this, but I want to spend a minute before I walk through this contextualizing it. This isn't quite in the book; I hope at some point you may read the book. Importantly, there is no theory, management 2.0 paradigm out there. When I was writing this book, I got asked often, "Are you describing a new paradigm, a new kind of management theory?" I scratched my head because I never really thought about it, and I've now come to the conclusion about no, I'm not. Here's the simple reason why. Thinking about any type of participative community — this is true of any open source community, I would argue any kind of organization that is adopting open principles — by definition moves you out of a comfort zone of a clear theory, knowledge, paradigm. It's a lot like economics. There are a lot of parallels between classical economics and classical management. They both developed in the late 1800s, early 1900s, about the same time. Economics and management basically developed using the same set of simplifying assumptions. These were social sciences, so this is trying to apply science to people and behavior. The classic way to do that around the turn of the century was, "All right, we got to make it a science, and therefore we have to make the math work, and we have to have generalized theories." So for economics to make the math work, you had to make some simplifying assumptions, like people are always rational, there's perfect information, and markets are in equilibrium. We know none of those things are true. If you've ever taken a microeconomics class, you know the last two lectures the professor said, "Well, we know none of that stuff's true now, but we had to make the simplifying assumptions to make the math work." So upward-sloping supply curve, downward-sloping demand, etc., etc., etc. But we know people aren't always rational. In fact, if you look today, virtually every major university's economics department has a behavioral economics department specialty within that. Behavioral economics basically says, "We know people aren't rational, so let's study that. We know people have all kinds of biases; they are relatively over-optimistic; we typically value today more than tomorrow." Because if we were all rational, we would all weigh exactly what we want to weigh, we would all save exactly how much we want to save for retirement, etc., etc., etc. We know those things don't happen. So we've developed a new kind of set of economics. If you want to read a great book, there's a book called "Freakonomics," and it's a great book that goes through some of the quirky behaviors that human beings have around not being totally rational. Management made the same assumptions that economics made, which is people are rational. This is why — it's more of an aside — but this is why in the literature for the last 50 years, there's been a bifurcation of management and leadership. That was another question I got asked a lot: "Are you writing a book about management or leadership?" I always scratch my head and say, "Well, I'm not sure." If you look out there, you can read tons of things talking about what's the difference between management and leadership. I've come to realize the difference between management and leadership is very simply because management in the way we classically thought of it made the simplifying assumption that people are totally rational — i.e., will only work for a paycheck and do what they're told, etc., etc., etc. That's imbued in all the aspects of management theory. Leadership is the other piece, which realizes people aren't always rational; we are emotional beings. Things like inspiration, morale, etc., matter. But we split those apart. What I think we're starting to see is those things need to come back together. So I would argue that as we go forward, you will see less of a bifurcation of management and leadership. As we've done in open source communities, we recognize we have to coordinate behavior, but these are people who have motivations other than being completely economically rational. People do it because they love it, or because they like being part of a community, because they feel like they're doing good things for the world. Those are all abstracted away in classical economics and in classical management. The reason I spent such a long time talking about that — and I really will walk through a few components of this — is in the same way that there is no grand unifying theory of behavioral economics because the math is too hard. As soon as you say people are irrational, the math gets really hard. So there is no grand unifying kind of economics 2.0, behavioral economics grand theory. There is no grand theory of management. We're all stumbling along trying to figure out how to best inspire, lead, etc. So what the book is about is what Red Hat has done to unlock the potential and the power of our people. It really is the principles of open source. I'm going to walk through a few of them quickly here; obviously happy to engage more through the course of the day, or meet me outside — I think I'm signing books later, we can talk more about it. First off, purpose and passion are critical. I think we all kind of know this, but as managers we often forget this. I talk to CIOs about this all the time. You have to connect what your people are doing every day to the broader purpose of the company. People just forget. They like, "Well, people can go read the mission statement, etc." You have to connect people to the purpose of the company beyond getting a paycheck. I say that over and over again because we all kind of know it, but we all often forget it. For Red Hat, we really work to ignite that with passion. We talk about open source, we talk about what we're doing in the world. We do videos like the ones you saw; those are certainly for external, but they also continue to bring home the power of all the code we give away and what that ultimately does for society. This is one measure of that: how many people in your company have your company's logo tattooed? Those are not fake; those are real tattoos. Those are three Red Hatters that we actually got together at Summit this year or have the tattoos. That is commitment to a brand. So we're not changing our brand. Not to pick on the Google guys, but you read the article — they changed their brand, and there's a guy with a Google tattoo who is upset. So I always threaten these guys: if they piss me off, I'm going to change the logo. Just kidding. But I cannot overestimate that. I think people who are leaders in open source communities recognize the importance of that to attract the best and the brightest to their communities. Next, you really have to engage. Again, I spend a lot of time talking to CIOs about this. When they buy the shiniest, best DevOps tools and fall flat on their face, it's like, "Well, have you really deeply engaged with the people in your organization about the 'why' of what they're doing, what you're trying to accomplish? Have you really engaged and listened to them?" We use very simple tools, by the way. Memo-list is one of our many email lists. Yes, we are a tech company, and we use email lists to basically collaborate, and it works phenomenally well. It works phenomenally well because I contribute and listen; the senior executives are on there listening, contributing. Our people know that if there's an issue that's important, they can post there and everyone in the company is going to see it. Engagement is critical, critical, critical. We certainly in open source communities really deeply make sure the top teams, and then flowing all the way through to all participants, are all working together on the same mailing list, that people understand direction and the what and the why. That is absolutely critical. Meritocracy — let me just tell you one quick story. I put Qumranet up here. Qumranet is the company that had the key developers of KVM, which is the primary hypervisor that underlies OpenStack and is underlying our product. I remember in my first month at Red Hat, I'm in a meeting with my head of products and technology, our CTO and head of engineering, a person who then was running virtualization engineering, and then an engineer in that group. They're talking about why — this was eight years ago — we were supporting Xen as our core hypervisor, and we're kind of going through this. The engineer in there said, "Yeah, yeah, this is what we're doing, but I really think it's wrong. We really need to be behind KVM because a whole bunch of reasons: part of the Linux kernel, etc., etc., etc." I'm sitting here thinking, and the others in the room are arguing with them but very happy to have an open debate in front of the CEO. I remember going home and telling my wife, "At Delta, if an engineer or somebody in a lower part of the organization in front of his boss and his boss's boss's boss and his boss's boss's boss said to the CEO, 'Yeah, I just completely disagree with what those guys are doing,' that guy would have been fired so fast." At Red Hat, we celebrate that. We love it when people disagree. We argue things out; we fight to ultimately get the best solution. By the way, nine months later, we bought that company for $108 million, so I guess he was right. I think this is another important thing, and this is one that I get the most shock when I talk to CIOs about: "How do you build an organization capable of moving faster and innovating faster?" It's not about holding hands and singing "Kumbaya." Any of you involved in productive open source communities know that it often gets heated. Matter of fact, the whole concept of brainstorming, which is what most of us think about, was developed in the 1950s. Tons of research shows it doesn't work. Celebrating everyone's ideas doesn't work. You get better answers if ultimately you have people kind of fighting things out, when you get people saying, "I agree with this," or "I don't agree with this," or "That's a bad idea." If an idea is a bad idea, say it's a bad idea. Unfortunately, the Linux community takes that to an extreme where I think many of us think that it's not fully productive, but recognizing the importance of having the right debate, having frank, open conversations, is a key part in any organization of ensuring that you get the best answer. And then finally, this is our mission statement. I'll spend a second on it. "To be the catalyst in communities of customers, contributors, and partners building better technology the open source way." The first draft of this said, "We aspire to be the leader in..." dot, dot, dot. Our developers came back and said, "Well, that's not true. We don't lead these communities." So we came back with a second version and said, "Our mission is to be an active participant in..." dot, dot, dot. The same developer said, "No, that's not accurate, because we aspire to drive direction." Of course, I said, "Well, are we leaders or are we participants?" They came back and said, "Well, we're neither." This again is a change from the typical bureaucracy. They came back and said, "We are the catalyst in communities, because we are there because of our contributions; we can influence direction." That's why Red Hat — and virtually every community we're involved in, we're the largest or second largest contributor to those communities — because we need to catalyze direction. We don't order people to do things; we catalyze direction. As leaders on our best days, I tell CIOs this all the time: catalyze direction, because ultimately you get better answers, you get more and deeper levels of engagement. If we — meaning all of us in open source, our organizations, for those of you who are enterprise users, broadly for management teams in general — if we are going to maximize the innovation potential of our organizations and ultimately for society as a whole, we have got to adopt a new approach. I got lucky; I was the frog that got thrown in the boiling water. I'm now out there evangelizing: we've got to move to a post-industrial era way that we organize and lead. Open source is just an extraordinary metaphor, example of how to do that at scale. So I'll leave you with one last thought: no organization can predict the future of technology. All of us — a coalition of us — will build it. That's true whether it's being the default choice in next-generation IT infrastructure or more broadly, IoT, or even how we will construct the economy going forward. So I hope you enjoy the next couple of days. We really do appreciate you having us here in our town, and I look forward to getting a chance to chat with more of you along the way. Thank you.