May 23, 2019 at 11:30 a.m.“Open Organization”: How not to get lost in chaos and rally millions
An important day has come for Red Hat, the Russian open source community and everyone involved - in Russian, Jim Whitehurst’s book, An Open Organization: Passion Brings Fruit, was published . She tells in detail and vividly how we at Red Hat give the best ideas and the most talented people the way, and how not to get lost in the chaos and rally millions of people around the world.
And this book is about life and practice. It has many tips for everyone who wants to learn how to build a company according to the model of an open organization and effectively manage it. Below are a few of the most important principles given in the book, which you can take note of right now.
(Video available with Russian subtitles)
Jim’s employment history with the company is remarkable. It shows that in the open source world there is no fanfare, but there is a new approach to leadership:
“After talking with the recruiter, I expressed interest in the interview, and he asked if I would not mind going to Red Hat's headquarters in Raleigh, North Carolina on Sunday. I thought Sunday was a strange day to meet. But since I was going to fly to New York on Monday anyway, I was on the way, and I agreed. I got on a plane from Atlanta and landed at Raleigh Durham Airport. From there I took a taxi that dropped me off in front of the Red Hat company on the campus of the University of North Carolina. It was Sunday, at 9:30 a.m., and no one was near. The light was turned off, and after checking, I found that the doors were locked. At first I decided that I was being fooled. Turning to return to the taxi, I saw that it had already left. It started to rain very soon, I didn’t have an umbrella.
As soon as I was about to go somewhere to catch a taxi, Matthew Schulick, later chairman of the board of directors and CEO of Red Hat, pulled up in his car. “Hi,” he said. “Would you like a cup of coffee?” This seemed like an unusual start to the interview, but I realized that I definitely needed a cup of coffee. Ultimately, I thought, then it will be easier for me to catch a taxi to the airport.
Sunday in North Carolina is pretty quiet in the morning. It took us a while to just find a coffee shop that would open before noon. The coffee house was not the best in the city and not the cleanest, but it worked and there you could drink freshly brewed coffee. We sat at a table and began a conversation.
About thirty minutes later, I realized that I like how everything goes; the interview was not traditional, but the conversation itself was very interesting. Instead of discussing the intricacies of Red Hat's corporate strategy or its image on Wall Street — that is, doing what I prepared for — Matthew Shulick asked more about my hopes, dreams, and goals. Now I understand that Shulik was evaluating whether I would be in line with the subculture and management style of the company.
After we finished, Shulik announced that he wanted to introduce me to the company’s general counsel, Michael Cunningham, and offered to meet with him now, at an early lunch. I agreed, and we were about to leave. Then my interlocutor discovered that he did not have a wallet with him. “Oops,” he said. - I have no money. And you? ”It took me by surprise, but I replied that I have money and I do not mind paying for coffee.
A few minutes later, Shulik dropped me off at a small Mexican diner where I met with Michael Cunningham. But again, no traditional interview or business meeting followed, but another interesting conversation took place. When we were going to pay the bill, it turned out that the machine for payment by credit card had broken down in the restaurant, and only cash could be accepted from us. Cunningham turned to me and asked if I was willing to pay because he did not have cash with him. Since I was going to New York, I had a lot of cash, so I paid for lunch.
Cunningham offered to give me a ride to the airport, and we drove in his car. A few minutes later he asked: “Do you mind if I stop and refuel? We will rush off at full speed. ” “No problem,” I replied. As soon as I heard the rhythmic knock of the pump, there was a knock on the window. It was Cunningham. “Hey, they don't accept credit cards here,” he said. “Can I lend some money?” I began to wonder if this was an interview or some kind of scam.
The next day, while in New York, I discussed with my wife this interview with Red Hat. I told her that the conversation was very interesting, but I’m not sure if these people seriously intend to hire me: maybe they just needed free food and gasoline? Remembering that meeting today, I understand that Shulik and Cunningham were just open people and treated me like any other person with whom they could have coffee, lunch or refuel with gas. Yes, it’s funny and even funny that they both ended up without money. But for them it was not about money. They, like the world around open source, did not believe in rolling red carpet or in trying to convince the other person that everything was perfect. They simply sought to get to know me better, rather than trying to impress or point out our differences. They wanted to know
My first interview at Red Hat clearly showed me that the work here is different. This company did not observe a traditional hierarchy and a special regime for managers, at least in the form that is accepted in most other companies. Over time, I also learned that Red Hat believes in the principle of meritocracy: it is always worth trying to translate the best of ideas, whether it comes from top management or an intern who has been hired for a summer job. In other words, my first impression of Red Hat introduced me to what the future of leadership looks like. ”
Meritocracy is a core value of the open source community. We don’t care what level of the pyramid you occupy, the main thing is how good your ideas are. Here's what Jim offers:
Enthusiasm and engagement are two very important words in an open organization. In the book they are repeated constantly. But you can’t get enthusiastic creative people to work on and on, right? Otherwise, just do not get everything that their talent can offer. In Red Hat, obstacles to your own projects are leveled as much as possible:
“Companies are trying a lot to drive innovation. Google’s approach is interesting. Since Google began to be known in every home since 2004, executives and ideologists in the Internet business have tried to unravel the company's main secret in order to repeat its impressive success. One of the most well-known, but currently closed programs was that all Google employees were invited to spend 20 percent of their work time on almost anything they wanted. The idea was this: if employees begin to implement their own projects and ideas that they are passionate about besides work, they will begin to create innovations. This is how successful third-party projects came about: GoogleSuggest, AdSense for Content, and Orkut; they all came from this experiment with 20 percent - an impressive list! [...]
We at Red Hat take a less formal approach. We have no established policy regarding how much time each of our employees should spend on “innovation”. Instead of giving people separate time for self-education, we make it so that employees earn the right to spend their time on new things. Frankly, many have quite a bit of this time, but there are those who can spend almost the entire working day on innovation.
The most typical case looks something like this: someone is working on a third-party project (if he explained to his managers the importance of it right at the workplace; or after hours on his own initiative), and later this work may take all his office hours. ”
“Lyrical digression. Alex Fakney Osbourne is the inventor of the brainstorming method, a continuation of which is today the synectic method. It is curious that this idea came about during World War II, when Osborne commanded one of the ships of the American cargo caravan, which was in danger of a torpedo attack by a German submarine. Then the captain remembered the trick that the pirates of the Middle Ages resorted to: if the team was in trouble, all the sailors gathered on the deck to alternately propose a way to solve the problem. There were a lot of ideas, including absurd at first glance: for example, the idea of blowing a torpedo as a whole team. But with a jet of a ship’s pump, which is available on every ship, it is quite possible to slow down the torpedo or even change its course. As a result, Osborne even patented the invention:
Our Jim constantly repeats that in an open organization it is not so easy to work. Even the management gets it, because no one is spared the need to defend their opinion. But just such an approach is needed to achieve an excellent result:
“Online forums [of open source developers] and chats are often filled with lively, and sometimes biting, discussions about everything - starting with how best to fix a software bug and ending with what new features should be considered in the next update. As a rule, this is the first phase of discussions, during which new ideas are put forward and accumulated, but the next round always takes place - a critical analysis. Although everyone can participate in these disputes, a person needs to be prepared to defend his position with all his might. Unpopular ideas are rejected at best, and at worst - ridiculed.
Even Linus Torvalds, creator of the Linux operating system, disagrees with the proposed changes to the code. One day, Linus and David Howells, one of the leading developers of Red Hat, entered into a heated debate about the benefits of the code changes requested by Red Hat, which would help ensure our customers security. In response to Howells’s request, Torvalds wrote: “Frankly, this [unprintable word] is idiocy. Everything seems to revolve around these stupid interfaces, and for completely idiotic reasons. Why should we do this? I no longer like the existing X.509 parser. The idiotic complex interfaces are being created, and now there will be 11. - Linus 9 ”.
Leaving the technical details aside, Torvalds in the next post continued to write in the same vein - and such that I would not risk quoting. This debate thundered so loudly that it even got on the pages of The Wall Street Journal. [...]
This debate shows that in most companies producing proprietary, proprietary software, there is no open debate about what new features or changes they can work on. When the product is ready, the company simply sends it to customers and moves on. At the same time, in the case of Linux, discussions about exactly which changes are needed and, most importantly, why they are needed, do not subside. This, of course, makes the whole process much more messy and time-consuming. "
We cannot foresee the future, so we just have to try:
“We act on the principle of“ early launch, frequent updates. ” The key problem of any software project is the risk of errors or bugs in the source code. Obviously, the more changes and updates are collected in one release (version) of software, the higher the likelihood that there will be bugs in this version. The developers of open source software realized: with the quick and frequent release of software versions, the risk of serious problems with any program is reduced - because we do not bring all updates to the market right away, but in portions for each version. Over time, we noticed that this approach not only reduces the number of errors, but also leads to more interesting solutions. It turns out that continually making minor improvements ultimately creates more innovation. Perhaps there is nothing surprising here.
[...] Much of what we are working on may not be successful. But instead of wasting a lot of time racking our brains on what works and what doesn't, we prefer to do small experiments. The most popular ideas will lead to success, and those that do not work will wither away by themselves. Thus, we can try a lot, and not just one thing, and without much risk to the company.
This is a rational way to allocate resources. For example, people often ask me how we choose which of the open source projects should be commercialized. Although we sometimes initiate projects, most often we just connect to existing ones. A small group of engineers - and sometimes even one person - begins to contribute to one of the open source community projects. If the project is successful and in demand among our customers, we begin to spend more time and effort on it. If not, the developers are moving to a new project. By the time we decide to commercialize the proposal, the project could grow to such an extent that the solution is obvious. A wide variety of projects, including those not related to software, naturally occur throughout Red Hat, until it becomes clear to everyone
Here’s another quote from the book:
“I realized that tomorrow’s leaders must be distinguished by characteristics that they simply don’t pay attention to in order to fulfill such a role. To effectively manage an open organization, the leader must possess the following qualities.
Red Hat lives and works on principles that are very different from a traditional hierarchical organization. And it works, it makes us commercially successful and humanly happy. We translated this book in the hope of spreading the principles of open organization among Russian companies, among people who want and can live differently.
Read , try it!
And this book is about life and practice. It has many tips for everyone who wants to learn how to build a company according to the model of an open organization and effectively manage it. Below are a few of the most important principles given in the book, which you can take note of right now.
(Video available with Russian subtitles)
Jim’s employment history with the company is remarkable. It shows that in the open source world there is no fanfare, but there is a new approach to leadership:
“After talking with the recruiter, I expressed interest in the interview, and he asked if I would not mind going to Red Hat's headquarters in Raleigh, North Carolina on Sunday. I thought Sunday was a strange day to meet. But since I was going to fly to New York on Monday anyway, I was on the way, and I agreed. I got on a plane from Atlanta and landed at Raleigh Durham Airport. From there I took a taxi that dropped me off in front of the Red Hat company on the campus of the University of North Carolina. It was Sunday, at 9:30 a.m., and no one was near. The light was turned off, and after checking, I found that the doors were locked. At first I decided that I was being fooled. Turning to return to the taxi, I saw that it had already left. It started to rain very soon, I didn’t have an umbrella.
As soon as I was about to go somewhere to catch a taxi, Matthew Schulick, later chairman of the board of directors and CEO of Red Hat, pulled up in his car. “Hi,” he said. “Would you like a cup of coffee?” This seemed like an unusual start to the interview, but I realized that I definitely needed a cup of coffee. Ultimately, I thought, then it will be easier for me to catch a taxi to the airport.
Sunday in North Carolina is pretty quiet in the morning. It took us a while to just find a coffee shop that would open before noon. The coffee house was not the best in the city and not the cleanest, but it worked and there you could drink freshly brewed coffee. We sat at a table and began a conversation.
About thirty minutes later, I realized that I like how everything goes; the interview was not traditional, but the conversation itself was very interesting. Instead of discussing the intricacies of Red Hat's corporate strategy or its image on Wall Street — that is, doing what I prepared for — Matthew Shulick asked more about my hopes, dreams, and goals. Now I understand that Shulik was evaluating whether I would be in line with the subculture and management style of the company.
After we finished, Shulik announced that he wanted to introduce me to the company’s general counsel, Michael Cunningham, and offered to meet with him now, at an early lunch. I agreed, and we were about to leave. Then my interlocutor discovered that he did not have a wallet with him. “Oops,” he said. - I have no money. And you? ”It took me by surprise, but I replied that I have money and I do not mind paying for coffee.
A few minutes later, Shulik dropped me off at a small Mexican diner where I met with Michael Cunningham. But again, no traditional interview or business meeting followed, but another interesting conversation took place. When we were going to pay the bill, it turned out that the machine for payment by credit card had broken down in the restaurant, and only cash could be accepted from us. Cunningham turned to me and asked if I was willing to pay because he did not have cash with him. Since I was going to New York, I had a lot of cash, so I paid for lunch.
Cunningham offered to give me a ride to the airport, and we drove in his car. A few minutes later he asked: “Do you mind if I stop and refuel? We will rush off at full speed. ” “No problem,” I replied. As soon as I heard the rhythmic knock of the pump, there was a knock on the window. It was Cunningham. “Hey, they don't accept credit cards here,” he said. “Can I lend some money?” I began to wonder if this was an interview or some kind of scam.
The next day, while in New York, I discussed with my wife this interview with Red Hat. I told her that the conversation was very interesting, but I’m not sure if these people seriously intend to hire me: maybe they just needed free food and gasoline? Remembering that meeting today, I understand that Shulik and Cunningham were just open people and treated me like any other person with whom they could have coffee, lunch or refuel with gas. Yes, it’s funny and even funny that they both ended up without money. But for them it was not about money. They, like the world around open source, did not believe in rolling red carpet or in trying to convince the other person that everything was perfect. They simply sought to get to know me better, rather than trying to impress or point out our differences. They wanted to know
My first interview at Red Hat clearly showed me that the work here is different. This company did not observe a traditional hierarchy and a special regime for managers, at least in the form that is accepted in most other companies. Over time, I also learned that Red Hat believes in the principle of meritocracy: it is always worth trying to translate the best of ideas, whether it comes from top management or an intern who has been hired for a summer job. In other words, my first impression of Red Hat introduced me to what the future of leadership looks like. ”
Meritocracy Cultivation Tips
Meritocracy is a core value of the open source community. We don’t care what level of the pyramid you occupy, the main thing is how good your ideas are. Here's what Jim offers:
- Never say, “This is what the boss wants,” and don't rely on hierarchy. This may help you in the short term, but meritocracy cannot be built like that.
- Publicly acknowledge successes and important contributions to the common cause. This may be a simple thank you email, in a copy of which is the entire team.
- Think: does your authority depend on your position in the hierarchy (or on access to privileged information) or is it the result of the respect you earned? If the first - start working on the second.
- Ask for feedback and collect ideas on a specific topic. Should respond to everything, test - only the best. But do not just take the best ideas and move on with them - use every opportunity to strengthen the spirit of meritocracy, paying tribute to all who deserve it.
- Mark the exemplary member of your team, offering an interesting assignment, even if it does not belong to his usual field of activity.
Let Your Rock Stars Follow Their Passion
Enthusiasm and engagement are two very important words in an open organization. In the book they are repeated constantly. But you can’t get enthusiastic creative people to work on and on, right? Otherwise, just do not get everything that their talent can offer. In Red Hat, obstacles to your own projects are leveled as much as possible:
“Companies are trying a lot to drive innovation. Google’s approach is interesting. Since Google began to be known in every home since 2004, executives and ideologists in the Internet business have tried to unravel the company's main secret in order to repeat its impressive success. One of the most well-known, but currently closed programs was that all Google employees were invited to spend 20 percent of their work time on almost anything they wanted. The idea was this: if employees begin to implement their own projects and ideas that they are passionate about besides work, they will begin to create innovations. This is how successful third-party projects came about: GoogleSuggest, AdSense for Content, and Orkut; they all came from this experiment with 20 percent - an impressive list! [...]
We at Red Hat take a less formal approach. We have no established policy regarding how much time each of our employees should spend on “innovation”. Instead of giving people separate time for self-education, we make it so that employees earn the right to spend their time on new things. Frankly, many have quite a bit of this time, but there are those who can spend almost the entire working day on innovation.
The most typical case looks something like this: someone is working on a third-party project (if he explained to his managers the importance of it right at the workplace; or after hours on his own initiative), and later this work may take all his office hours. ”
More than a brainstorm
“Lyrical digression. Alex Fakney Osbourne is the inventor of the brainstorming method, a continuation of which is today the synectic method. It is curious that this idea came about during World War II, when Osborne commanded one of the ships of the American cargo caravan, which was in danger of a torpedo attack by a German submarine. Then the captain remembered the trick that the pirates of the Middle Ages resorted to: if the team was in trouble, all the sailors gathered on the deck to alternately propose a way to solve the problem. There were a lot of ideas, including absurd at first glance: for example, the idea of blowing a torpedo as a whole team. But with a jet of a ship’s pump, which is available on every ship, it is quite possible to slow down the torpedo or even change its course. As a result, Osborne even patented the invention:
Our Jim constantly repeats that in an open organization it is not so easy to work. Even the management gets it, because no one is spared the need to defend their opinion. But just such an approach is needed to achieve an excellent result:
“Online forums [of open source developers] and chats are often filled with lively, and sometimes biting, discussions about everything - starting with how best to fix a software bug and ending with what new features should be considered in the next update. As a rule, this is the first phase of discussions, during which new ideas are put forward and accumulated, but the next round always takes place - a critical analysis. Although everyone can participate in these disputes, a person needs to be prepared to defend his position with all his might. Unpopular ideas are rejected at best, and at worst - ridiculed.
Even Linus Torvalds, creator of the Linux operating system, disagrees with the proposed changes to the code. One day, Linus and David Howells, one of the leading developers of Red Hat, entered into a heated debate about the benefits of the code changes requested by Red Hat, which would help ensure our customers security. In response to Howells’s request, Torvalds wrote: “Frankly, this [unprintable word] is idiocy. Everything seems to revolve around these stupid interfaces, and for completely idiotic reasons. Why should we do this? I no longer like the existing X.509 parser. The idiotic complex interfaces are being created, and now there will be 11. - Linus 9 ”.
Leaving the technical details aside, Torvalds in the next post continued to write in the same vein - and such that I would not risk quoting. This debate thundered so loudly that it even got on the pages of The Wall Street Journal. [...]
This debate shows that in most companies producing proprietary, proprietary software, there is no open debate about what new features or changes they can work on. When the product is ready, the company simply sends it to customers and moves on. At the same time, in the case of Linux, discussions about exactly which changes are needed and, most importantly, why they are needed, do not subside. This, of course, makes the whole process much more messy and time-consuming. "
Release early, release often
We cannot foresee the future, so we just have to try:
“We act on the principle of“ early launch, frequent updates. ” The key problem of any software project is the risk of errors or bugs in the source code. Obviously, the more changes and updates are collected in one release (version) of software, the higher the likelihood that there will be bugs in this version. The developers of open source software realized: with the quick and frequent release of software versions, the risk of serious problems with any program is reduced - because we do not bring all updates to the market right away, but in portions for each version. Over time, we noticed that this approach not only reduces the number of errors, but also leads to more interesting solutions. It turns out that continually making minor improvements ultimately creates more innovation. Perhaps there is nothing surprising here.
[...] Much of what we are working on may not be successful. But instead of wasting a lot of time racking our brains on what works and what doesn't, we prefer to do small experiments. The most popular ideas will lead to success, and those that do not work will wither away by themselves. Thus, we can try a lot, and not just one thing, and without much risk to the company.
This is a rational way to allocate resources. For example, people often ask me how we choose which of the open source projects should be commercialized. Although we sometimes initiate projects, most often we just connect to existing ones. A small group of engineers - and sometimes even one person - begins to contribute to one of the open source community projects. If the project is successful and in demand among our customers, we begin to spend more time and effort on it. If not, the developers are moving to a new project. By the time we decide to commercialize the proposal, the project could grow to such an extent that the solution is obvious. A wide variety of projects, including those not related to software, naturally occur throughout Red Hat, until it becomes clear to everyone
Here’s another quote from the book:
“I realized that tomorrow’s leaders must be distinguished by characteristics that they simply don’t pay attention to in order to fulfill such a role. To effectively manage an open organization, the leader must possess the following qualities.
- Personal strength and confidence. Ordinary leaders use positional power - their position - in order to succeed. But with meritocracy, leaders must earn respect. And this is only possible if they are not afraid to admit that they have no answers to all the questions. They should be prepared to discuss problems and make quick decisions in order to find the best solutions together with their team.
- Patience. The media rarely tells stories about how “patient” the leader is. But he really has to be patient. When you work to get the maximum effort and results from your team, spend hours talking and repeating something over and over until everything is done correctly - you need to be patient.
- High EQ (emotional intelligence). Too often, we advertise executives' intellectual abilities by focusing on their IQ, when in reality their emotional intelligence ratio, or EQ, needs to be taken into account. Being the smartest person among others is not enough if you are not able to work with these people. When you work with communities of employees involved, like in Red Hat, and you don’t have the ability to order someone, your ability to listen, analytically process and not take everything into your account becomes incredibly valuable.
- Another mentality. Leaders who came from traditional organizations were raised in the spirit of quid pro quo (lat. “Service for service”), according to which each action should receive an adequate return. But when you are going to invest in creating a certain community, you should think long-term. It’s like an attempt to build a finely balanced ecosystem, where any wrong move can create an imbalance and lead to long-term losses that you may not notice right away. Managers must get rid of the type of thinking that requires them to achieve results today and at any cost, and start doing business in such a way that they can get great benefits through investments in the future. ”
And why is this important
Red Hat lives and works on principles that are very different from a traditional hierarchical organization. And it works, it makes us commercially successful and humanly happy. We translated this book in the hope of spreading the principles of open organization among Russian companies, among people who want and can live differently.
Read , try it!