Catalyzing Direction
The purpose of the new management model called the open organization is to build an organization capable of thriving in the new economy—an organization that can respond quickly to external changes without relying on running things up the chain of command. An open organization encourages and fosters initiative and creativity among its members rather than, as Andrew McAfee of the MIT Center for Digital Business puts it, running operations based on “HiPPO—the highest-paid person’s opinion.”1 The new model that is evolving also appeals to a new generation of employees whose expectations are vastly different from those of people who preceded them in the workplace.
A core function of management systems that I’ve yet to discuss is setting direction. Traditionally, direction is set at the top. The typical structural solution at most companies includes a strategy or strategic planning department. These organizations typically have a handful of bright MBAs with skills and training in strategic frameworks, planning, and the like. Working with senior management and perhaps a few consultants, they help craft the core strategies that the organization ultimately follows. Strategic directives are then handed down for execution throughout the company. It’s simply assumed at most companies that the senior executive team and the board of directors set strategy.
Obviously, top-down directives don’t do well in open organizations. So, given this new type of organization, if you have all these engaged and passionate people ready to take on the world, how do you, as a leader, set the direction in which the company is going? If you can’t just issue an order and say, “We’re going to take that hill!” then how do you get the organization to do different things, or do things differently? How do you as a leader get everyone in a participative company to change or to move together in the same direction?
Introducing the Catalyst in Chief
After my first year at Red Hat, I began to wonder what my role as the president and CEO truly was. By that point I’d begun to understand and appreciate both the power and the subtlety of Red Hat’s culture and participative management model. Clearly, continuing to drive and reinforce the system was job one. But what was less clear to me was the role I needed to play in driving changes in strategic direction. I’m sure many other Red Hat leaders have asked themselves that same question.
The answer came to me as I reflected on our mission statement. As you might remember from chapter 6, it reads: “To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way.” The more I thought about this, the more I realized that the answer was right in front of me. My role as a leader was to be the catalyst for the organization itself.
One of the most difficult and subtle parts of fine-tuning that statement was settling on the right word (or words) to describe the role Red Hat aspires to play in the open source communities in which we operate. In early drafts, we used the word “leader.” But many people involved in the process quickly pointed out that this word wasn’t entirely accurate. Leadership, in their view, implies a level of control that we at Red Hat do not have, nor aspire to have, within our communities. We treasure the concept of meritocracy, and calling Red Hat the leader seemed to imply that somehow the rules didn’t apply to us.
We next tried substituting the phrase “active participant.” That was softer and more accurately described how we contribute to the communities in which we’re involved, but again, it wasn’t quite right. We aspire to do more than just contribute; we want to influence the direction of these communities, yet not control them either.
Ultimately, we arrived at the word “catalyst”—“an agent that provokes or speeds significant change or action”—and I think it best describes how Red Hat provides leadership in the communities in which we operate. We contribute to our communities, doing what we believe is in their best long-term interest, by building up positions of thought leadership within. In that way, Red Hat serves as an agent that provokes or speeds change or action in the open source communities in which we operate. The more I thought about it, the more I realized that this concept also provides a good model for the role of leaders in the twenty-first century.
Leaders have many opportunities to act as an “agent.” We have the ability to call meetings and talk about what we think is important, to ask questions and get answers, and to structure areas of work. All are opportunities to catalyze direction. I’m not a chemist, so a good mental image for me is to think about a dock piling at an ocean shore. Look at any piling and you’ll see an abundance of sea life attached to it. Barnacles attach to the piling and then attract additional sea life, which feeds on the barnacles and might also make a home there. Before you know it, there’s an entire mini-ecosystem around that piling. But if the piling were not there, none of that sea life would have chosen to grow at that exact spot. The piling created the context and vehicle for life to congregate. Simply by being there, it fosters a new community, which is a key dynamic of catalyzing an open organization.
But there are also moves—some subtle, others more overt—that you can take to sway the kind of actions that your participative community undertakes.
The Leader’s Role: Leverage Your Soap Box
One of the benefits of being a leader is that you have the power to create venues for bringing people together, and you have the power to set the agenda for a range of conversations throughout the organization. After being at Red Hat for several years, I hope that I have personally earned the right to be heard in our meritocracy. But even in our culture, my title certainly helps. Generally, because of my role, people will make the time to listen to me, and they will seriously consider what I’ve said. I get their attention. When and how I, as a leader, use those venues can be a powerful way for me to influence the direction of the company.
When I address the company either in a formal way, say, at a quarterly company meeting, or in more informal settings, like the ad hoc town hall–style Q&As I hold in our global offices, what I talk about, the questions I ask, and the issues I raise foster discussion and debate throughout the entire company. I have the opportunity to light little sparks and see what passionate fires erupt from there. But because I am only offering a spark, it’s the subsequent conversations people have with their peers throughout the organization that truly result in things happening.
I am not talking about announcing formal initiatives that have already been fully vetted and decided upon. That’s nothing more than personally delivering a top-down decision. Rather, I use these opportunities to poke and prod on issues that I believe are important to Red Hat. The subsequent conversations and activities around the company will ultimately coalesce into the appropriate initiatives. My job as catalyst is to stir the debate and ignite the conversations. From there, our associates, through their own conversations and debate, will drive the ultimate actions.
For instance, Red Hat has emerged as a leader in the field of cloud computing. We are the leading contributors to and sellers of the infrastructure software used to run public and private clouds. The specific initiatives to establish that position didn’t emerge from a top-down strategy process. They came from the senior team at Red Hat describing how important it was for Red Hat and open source to emerge as the default choice for next-generation IT infrastructure. That’s as directive as we needed to be. Myriad debates have subsequently raged within the company over specific technologies, markets, and business models. Those debates have and are leading to much better execution than we could ever have prescribed from the top down. Frankly, the market changes so rapidly that any structured plan would be obsolete in months. Instead, the people closer to the facts and activities in the marketplace are making the decisions on the specifics. And they are empowered to react quickly, which keeps our strategies from getting stale.
Whole Foods operates in a similar way. Since the company continues to expand rapidly, it now has four hundred stores but has a goal of eventually operating twelve hundred.2 It couldn’t possibly hope to keep up with all the trends and tastes of those local markets through a centralized command system. Rather, CEO John Mackey has made it clear that regions and stores have the freedom to experiment with a mix of non–Whole Foods–branded products as they see fit. That’s especially true when it comes to how those stores support the burgeoning local foods movement, says Mackey, “which allows a constant supply of new and innovative products to bubble up from local sources, with the most successful ones eventually spreading across the company.”3 To put that another way, Mackey allows his leaders at the regional and store levels to essentially chart the future mix of products for the entire company as a whole because he trusts that they know and care about the company’s purpose and mission. That’s powerful stuff.
Obviously, leveraging a soapbox requires that venues exist where leaders are interacting with their employees. Having a regular cadence of opportunities for these types of interactions is critical. At Red Hat, we have quarterly company meetings, though because of our size and global spread, most associates dial in by phone or via their computer to access them. We do, however, have vehicles for associates to e-mail questions or ask during conference calls. I still find face-to-face interactions are most productive. Time zones and distance can be barriers, so the senior team and I try to schedule town hall meetings when we visit locations worldwide. Within Red Hat, I’m not alone. Many Red Hat managers and leaders create similar forums within their own organizations. Every company is different, but regardless, ensuring that venues for interaction exist should be a priority.
Selling Half-Baked Thoughts
Often leaders have a general sense of where they want to lead the company, but have not yet nailed down the specifics. Unfortunately, too often leaders are uncomfortable sharing plans that aren’t complete. They worry that they are not setting clear goals or that ambiguity will cause more harm than good. In a participative organization, this is a great time to engage. It often means articulating aspirational goals (as long as they are consistent with the purpose and values) without specifics on how to get there. Particularly when the specific implementation steps aren’t yet clear, involving associates early is a great way to help identify priorities and create alignment throughout the organization. The goal, in short, is to make the most of the knowledge and skills of the broader organization to fill in the details. As Daniel Goleman, author of the influential book Emotional Intelligence, describes in his definition of “primal leadership,” there is an emotional dimension to leadership where a leader’s primary task is to “articulate a message that resonates with their followers’ emotional reality, with their sense of purpose—and so to move people in a positive direction. Leadership, after all, is the art of getting work done through other people.”4
For example, as I’ve described throughout the book, Red Hat has built an extremely successful business by catalyzing open source communities. It’s deep in our DNA and is our source of competitive advantage. It allows the company to deliver cutting-edge technology at dramatically lower prices than our competitors can provide. In short, our competitive advantage is built around a capability to leverage open source. Since we do deliver such a great value proposition, customers generally like us. Surveys suggest that we have very high levels of customer satisfaction, and we receive very high Net Promoter scores—a high percentage of our customers say they will recommend Red Hat to friends or other potential customers.
However, as Red Hat has grown and the customer base has expanded beyond the early adopters who are technology savvy and value the technical merits of our solutions, I’ve worried about whether the company is truly focused on the needs of our mainstream customers. While organizations like the New York Stock Exchange Euronext and DreamWorks care about the performance of our products, most mainstream IT customers care more about issues like ease of use and quality of documentation. In addition, as Red Hat has become a larger part of our customers’ IT infrastructure, and as they begin to use more of our products, they expect us to understand their businesses. They expect us to offer solutions to their problems, not just offer great technology.
So clearly Red Hat needs to become more customer focused as it grows. The question is where to start. Some areas are clearly apparent, like making products easier to install. No one would disagree with that. Other areas are subtler. For instance, we need to ensure that our product road maps meet the needs of customers, such as by including ease-of-use features. But that’s not necessarily what open source focuses on. Open source is known for driving great technical solutions, and developers pride themselves on offering tremendous flexibility to the user. But they frankly don’t worry as much about whether the resulting products are simple to use. It’s almost a badge of honor to “drop to the command line,” which is techno-speak for using a text-based, terminal window that looks like it’s from circa 1970. So while I clearly want Red Hat to listen to customer needs and be responsive, I also recognize our core source of competitive advantage is built on using the power of open source.
In a conventional organization, the answer to my desire to improve customer focus would be to form a team to develop recommendations on a plan. The team would analyze products and processes and would develop a set of recommendations for where to improve customer focus. The team would also look at areas of potential conflict, like customers’ desire for ease of use. It would recommend specific initiatives and actions. I would then announce a “focus on the customer” initiative that would be rolled out across the company.
At Red Hat, I can effect the same result by simply talking about it. Using my stage, I “sold” the idea that this is an important thing for us all to address. I explained how, by listening to and working more closely with our customers, we might make the technology even more powerful and the company more successful as a whole. I also explained my concerns about the trade-offs of staying on the bleeding edge of technology and also being responsive to mainstream customers. But that was it. I didn’t lay out any specifics about how we could go about making ourselves more customer focused. I didn’t charter a team. Rather, I laid out the context that helped illustrate how critical moving in that direction could be for the future of the company. In that way, what I was selling was a “half-baked” idea.
What happened was that people throughout the organization began to do things to improve engagement with customers. Multiple initiatives emerged across the company. For instance, Marco Bill-Peter, who heads Red Hat’s global support organization, took up the challenge in his own way. Without any direct orders issued from me, he created a unique approach to solving customers’ problems. Rather than the conventional approach in which a customer calling with a complex problem would be bounced around before he or she would finally connect with the expert who could actually solve the issue, Bill-Peter and his team came up with the concept of a “swarm,” which comprised cross-departmental teams of service reps and engineers with different levels of knowledge capable of handling just about any kind of issue. That meant that any time a customer called in, he or she was connected with a team that was motivated to find a solution rather than just punting the ball farther down the line.
Just as importantly, the introduction of the swarm doubled the number of customers who engaged with us, while simultaneously cutting the cost of support as a percentage of the company’s overall revenue. The results earned Bill-Peter and his team accolades from around the industry and from publications like The Economist, which wrote a case study about Red Hat’s innovative solution to delivering enhanced customer service. The swarm approach to connecting and engaging with customers has become so effective that teams across the business—from product documentation to legal—are starting to form and join swarms. “As a company, we see this collaborative model going into other fields,” Bill-Peter told The Economist. “It leads to innovation across the business and makes people think about how they do things.”5
More to my point in this chapter, Bill-Peter heard me and went about connecting the dots in his own way to tie Red Hat more closely to customers, which is something he admits he would not have had the freedom to do at his former employer, the tech giant Hewlett-Packard. That’s a great thing, because I’m not sure I would have been able to think of doing such a thing myself and then trying to get someone else to implement it. Again, Bill-Peter wasn’t following an order; he made up his own mind that it was an important task to undertake, and he and his team came up with their own unique way to implement a solution.
I am convinced that the resulting activities that we’ve undertaken are better than we would have identified with a formal team. I’m comfortable admitting that I just don’t have all the answers, and that no ad hoc team can fully specify all the appropriate activities. By having capable, engaged people recognize the importance of the goal and then expecting them to solve it in their own way, thousands of small tweaks can be made across the company. That’s much richer and subtler than the handful of big initiatives that a top-down planning process would generate. And things happen much, much faster throughout the organization than if I wanted to control every decision that was made on a regular basis.
Establishing the Right Amount of Structure
Part of the art of leading a self-directing, engaged organization is to spark the organization to action. The specificity of those goals and targets can vary along a spectrum from ultra-specific numeric targets against discrete objectives to very macro-level, subjective notions like “We need to improve.” If your aim is too precise, you might turn people off or send them in the wrong direction by giving them too much direction. At the same time, if you make the goals too broad, you might not inspire any action whatsoever or be left with utter chaos as people run off in multiple directions at the same time. So the goal is to try and create enough structure around the organization’s actions without creating too much. Finding the balance is a real art.
W. L. Gore is noted for its complete lack of hierarchy, despite having nine thousand associates spread among thirty countries. The company intentionally keeps its teams small, two hundred people or fewer, as a way to foster creativity and innovation. Gary Hamel has written extensively about the company and about its founder Bill Gore, who wanted his company to have a “lattice” as its base for a corporate structure where there were “no layers of management, information would flow freely in all directions, and personal communications would be the norm. And individuals and self-managed teams would go directly to anyone in the organization to get what they needed to be successful.”6 In a conversation with Hamel, Terri Kelly, Gore’s CEO, talked about how its teams, not the leaders at the top, make the decisions that drive the company forward because they are trusted to act in the best interests of the company:
First of all, there are norms of behavior and guidelines we follow . . . Every associate understands how important these values are, so when leaders make decisions, people want to understand the “why.” They know they have the right to challenge, they have the right to know why this decision is the right one for the company . . . [O]ur leaders have to do an incredible job of internal selling to get the organization to move. The process is sometimes frustrating, but we believe that if you spend more time up front, you’ll have associates who are not only fully bought-in, but committed to achieving the outcome. Along the way, they’ll also help to refine the idea and make the decision better.7
In the example I shared about Red Hat’s increased customer focus, we as a management team were intentionally broad when introducing the concept. Everyone should have a sense for how his or her role ultimately translates to customer value, so it should resonate with everyone. In addition, I had no specific areas that I wanted to ensure were addressed. So we simply stated the problem and asked the organization to respond. There are other times when adding a bit of structure can be helpful. Take, for example, efforts to increase the share of users who opt to pay for Red Hat Enterprise Linux, versus choosing another paid or free Linux distribution. This was a key opportunity that we identified in our strategic planning process. We believe that we add tremendous value in our paid-for subscription version. Since Linux is free, however, there are obviously many alternatives in the marketplace for which users don’t have to buy a subscription.
From research, we knew that there were three major areas of opportunity: people using our product but without an active subscription, people who had used to subscribe but let their subscriptions lapse, and people using free, community versions of Linux. Maybe the organization could address all three areas from a simple high-level challenge to address “free to paid,” but I worried that some areas might not realize their importance in solving the problem. Without a doubt, engineering and sales would jump in and begin working to better communicate our value proposition and improve usability, but my team and I realized that much of the work required to address unpaid usage of the product and renewals would come from other areas of the business. So the team worried that, without a bit more direction, a broad statement of “free to paid” would send some groups scurrying, while others would feel it was not relevant to their area.
Renewals are a great example. Obviously, for a subscription business, renewals are a key value driver. Much of what drives renewals is hard-core operational work. Because our products are often sold preloaded on a manufacturer’s hardware or sold in less developed areas through multiple distribution levels, we often do not know who the end customer is. Improving renewals entails working on myriad operational and legal issues. It involves substantial IT work to improve internal data. We have to work with partners to encourage and motivate them to drive renewals and write tighter contracts with distribution partners to share end-user information where appropriate. Without providing a specific initiative—around which to catalyze this work—many of our operations associates would not have recognized the vital role that they play every day in ensuring customers continue to enjoy the benefits of Red Hat subscriptions.
A similar dynamic of people and activities exists in addressing customers who were using subscriptions without paying for them. So the solution we came up with—to ensure that we addressed all the major areas of “free to fee”—was to break the larger issue down into three more manageable ones:
Subscription education: Developing programs to identify and educate organizations that are using subscriptions but not paying us for them.
Renewals: Focusing on many operational, technical, and process issues to ensure that we know what subscriptions are about to expire and that someone at Red Hat or a partner is asking that customer to renew.
Community-to-enterprise: Improving products and better communicating the value of a relationship with Red Hat relative to other alternatives.
Once we identified these groups, internal teams tackled the specifics of how to solve them, and they did an amazing job. The results have been fantastic. Again, the goal was to find that sweet spot at which we could create enough structure so that people knew where we wanted to make progress, while also having the freedom to come up with their own ideas for meeting their goals.
Avoiding the Big Mistakes
Many people who read about this distributed—and let’s face it, chaotic—approach to driving strategy might think that it sounds like a recipe for disaster. Obviously, all of the various initiatives that emerge haven’t been fully analyzed and vetted in the way that top-down initiatives typically are. Isn’t that risky? Won’t many fail? The simple answer is yes. Some of the things we try fail, though I’m not sure the failure rate is higher than with top-down initiatives. I feel pretty certain that it’s lower. Still, without proper top-down vetting, how do we know if we are taking undue levels of risk? How do we identify efforts that aren’t working before we squander large amounts of resources on them?
Open source development communities solve this problem by focusing on making many small, incremental changes rather than a few large ones in what’s typically referred to as “release early, release often.” A key issue in any software project is the risk of errors, or bugs, in the code. Obviously, the more changes are lumped together in one release of software, the greater the likelihood that the release will also introduce bugs. So open source developers have found that by releasing early and often, they can reduce the risk that any release has major problems. Over time, we’ve observed that this methodology not only reduces the risk of bugs, but also leads to greater innovation. It turns out that making many small improvements continuously ultimately creates more innovation. Perhaps this shouldn’t be surprising. One key tenet of modern manufacturing process methodologies, like kaizen or lean, is to continually focus on small, iterative improvements.
As Clay Shirky, author of Here Comes Everybody, comments about open source: “Because anyone can try anything, the projects that fail, fail quickly, but the people working on those projects can migrate just as quickly to the things that are visibly working. Unlike the business landscape, where companies have an incentive to hide both successes (for reasons of competitive advantage) and failures (to forestall any perception of weakness), open source projects advertise their successes and get failure for free.”8
Like so many other aspects of its management system, Red Hat has adopted this same principle for internal initiatives. We call our internal corollary to release early, release often “failing fast.” Failing fast recognizes that many things we try may not work. But rather than spending tons of time trying to analyze which will work and which will not, we allow many small experiments. Those that gain momentum continue to grow, while those that don’t are allowed to wither away. In this way, we can try many things without any single one creating too much risk for the company.
This is a powerful way to allocate resources. For example, people often ask me how we decide which open source projects to commercialize. Though we sometimes initiate projects, most often we simply become involved in existing ones. A small group of engineers—sometimes a single person—begins contributing as an open source community. If the community begins to thrive and our customers begin to get involved, we increase our effort. If not, the engineers move to a new project. By the time we decide to commercialize an offering, the project has grown to the point where the decision is obvious. Projects of all kinds, beyond just software, naturally emerge throughout Red Hat until it’s obvious to everyone that someone needs to work on it full-time.
The concept of making small, incremental advances and failing fast aren’t unique to open source and Red Hat. Scott Cook, founder of software company Intuit, which makes Quicken and TurboTax, among other products, once said, “When the bosses make the decisions, decisions are made by politics, persuasion, and PowerPoint. When you make decisions through experiment, the best idea can prove itself.” I was so taken with that notion that I searched and found more about his philosophy. “I believe the new skill in leadership is leadership by experiment,” Cook once told an audience. “In other words, decisions made by having a hypothesis that you then test.”9
That concept is also related to what electronics giant National Instruments (NI) calls “ooch by ooch.” “To “ooch” things means to sort of inch them along, taking small, incremental steps, while avoiding unnecessary risks,” NI CEO James Truchard has commented. “You don’t need a home run, just persistence.”10
Unanswered Questions Remain
While Red Hat’s leadership and management system evolved organically out of the open source software movement, it remains a work in progress. We continue to seek ways to tweak and improve it to meet the demands of running, in our case, a twenty-first-century public company. An area of particular interest for me is how to be the best leader possible in this new environment. As we have begun to think of leaders more as catalysts than dictators or generals, I’ve learned firsthand how leaders—including CEOs—need to adapt to the new dynamics involved in leading participative communities if they want to reap the benefits of speed and innovation from them.
For example, in my role as catalyst, I strive to encourage debate and discussion about the direction in which we want to move as an organization. But a key question then becomes, “How long do you let debates rage?” Or even, “How decisive should a leader be?” Those questions are tough to answer, especially at Red Hat where debates can last literally for months on end, maybe even years if they involve anything related to open source versus proprietary software.
But while it might seem clear that a debate that goes on for too long becomes unproductive and a drain on time and resources, it’s a constant struggle not to step in too soon and create serious engagement issues as a result. The truth is that I’m not sure there is a right or wrong answer to the question of how long you allow debates to continue. It almost comes down to a gut feeling, an intuitive sense that the time has come to finally make a decision. Debates usually resolve themselves, though. Typically, after a few days, people run out of things to say on memo-list or others start saying, “Enough already!”
Even then, once there is a resolution, challenges arise that involve getting on board with support for that decision and implementing it even if people still personally disagree with it. In my early days at Red Hat, I struggled when I heard how people continued to voice their disagreement with a decision we made, even after many of us had already moved on. I still struggle with it. That kind of dynamic is unfathomable in a more conventional organization. Most people would rather say, “I’m on board” with the decision, even if they aren’t. That doesn’t happen at Red Hat—people tell you what they think—which can really cut in two directions when you’re trying to get something accomplished.
When you add up challenges like these, you can see how difficult it is to not just throw up your hands occasionally and say, “Just do it. I am the CEO and I’m telling you that I want this order followed.” Admittedly, this kind of thing still happens sometimes, especially with time-sensitive decisions involving regulations, budgets, or some such where we don’t have time to let the debate flame out before we act. In 2008, as the Great Recession hit us, we needed to reduce budgets without soliciting much input on how to do it. But when this does happen, most of our leaders do a pretty good job of saying, “I hear what you’re saying, and I agree, that aspect isn’t ideal. But for Red Hat right now, these other factors are outweighing that issue, and although I know this isn’t the direction you want us to go in, it is what we’re going to do. And you might be right—I might be making a mistake here—but I’m the one who needs to make this call, and if I’m wrong, we’ll circle back and figure out how to correct it.”
We also understand that whenever we operate outside the lines in this way, it damages our culture by some degree. It’s like walking through a bed of perennial flowers: you don’t always know what kind of subtle damage or change you can bring about with just a single footstep. So while it might seem as if you’re opening yourself up to more problems by working inclusively, at Red Hat, we truly believe the benefits of facing challenges like these far outweigh the costs. It’s a balancing act that requires constant care and attention.
It remains important for us to embrace the notion of “on our best day,” where we strive to operate on the key principles we espouse in running an open organization, while also knowing we aren’t perfect. We will stumble from time to time. But, in the end, Red Hat is a stronger organization as a result.
Jim’s Leadership Tips
1.Find or create a venue in which to discuss areas where you would like to see your team make progress.
2.Tell your team members about a problem you are trying to solve. See how they respond, and if they are able to help solve it.
3.In an area where you would like to see progress, ask questions of your team rather than request action. Most likely, action will occur.
4.Create some space for your team to innovate by purposely leaving some ambiguity in your direction on a specific process or task.
5.Ask your team to come to you with ideas and proposals. Engage and discuss them, regardless of whether you move forward with them.