"Open Organization": How not to get lost in the chaos and rally millions
It is an important day for Red Hat, the Russian open source community and all those involved - the open organization Jim Whitehurst’s book Open Organization: A Passion Bringing Fruit in Russian . She tells in detail and vividly how we in Red Hat give the best ideas and the most talented people the way, and also how not to get lost in the chaos and rally millions of people all over the world.
And also this book is about life and about practice. It has a lot of advice for anyone 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 listed in the book that you can take note of right now.
')
(Video available with Russian subtitles)
Jim's job history in the company is remarkable. It shows that there is no fanfare in the open source world, but there is a new approach to leadership:
“After talking with a recruiter, I expressed interest in the interview, and he asked if I would be opposed to flying to Red Hat’s headquarters in Raleigh, North Carolina on Sunday. I thought Sunday was a strange day to meet. But since I was still going to fly to New York on Monday, in general I was on the way, and I agreed. I boarded a plane from Atlanta and landed at Raleigh Durham Airport. From there, I took a taxi that landed me in front of the Red Hat building on the campus of the University of North Carolina. It was Sunday, at 9:30 in the morning, and no one was near. The light was turned off, and, 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. Very soon it started to rain, I did not have an umbrella.
Only I was going to go somewhere to catch a taxi, like Matthew Schulick, later Chairman of the Board of Directors and CEO of Red Hat, drove up in his car. “Hi,” he said. “Would you like to drink coffee?” It seemed like an unusual start to the interview, but I understood that I definitely needed to drink coffee. Ultimately, I thought, then it would be easier for me to catch a taxi to the airport.
Sunday in North Carolina is pretty quiet in the morning. It took us some time to simply find a coffee shop that would open before noon. The coffee shop was not the best in the city and not the cleanest, but it worked and there you could drink freshly brewed coffee. We sat down at the table and began a conversation.
After about thirty minutes or so, I realized that I like how everything goes; the interview was not traditional, but the conversation itself was very interesting. Instead of discussing the subtleties of Red Hat's corporate strategy or its image on Wall Street — that is, doing what I was prepared for — Matthew Schulick asked more about my hopes, dreams, and goals. Now I understand that Shulik assessed whether I would fit 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 going to leave. Then my interlocutor discovered that he did not have a wallet with him. “Oops,” he said. - I have no money. Do you? ”It took me by surprise, but I replied that I had money and I did not mind paying for coffee.
A few minutes later Shulik dropped me off at a small Mexican diner, where I met up 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 restaurant had a machine for credit card payment, and we could only accept cash. Cunningham turned to me and asked if I was ready 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 lift to the airport, and we drove his car. A few minutes later he asked: “Do you mind if I stop and refuel? We rush at full steam. ” “No problem,” I replied. As soon as I heard the rhythmic knock of the pump, there was a knock at the window. It was Cunningham. “Hey, credit cards are not accepted here,” he said. “Can I borrow some money?” I began to wonder if this was really a job interview or some kind of scam.
The next day, while in New York, I discussed this interview with my wife at Red Hat. I told her that the conversation was very interesting, but I am not sure whether these people seriously intend to hire me to work: maybe they just needed free food and gasoline? Recalling that meeting today, I understand that Shulik and Cunningham were simply open people and treated me like any other person with whom they could drink coffee, have lunch or gasoline. Yes, it is funny and even funny that both of them were out of money. But for them it was not about the money. They, like the world around open source, did not believe in rolling out red carpet paths or trying to convince the other person that everything was perfect. They just wanted to get to know me better, and not try to impress or point out our differences. They wanted to know who I was.
My first interview at Red Hat clearly showed me that the work here is of a different nature. This company did not observe the traditional hierarchy and special treatment for managers, at least in the form that is common in most other companies. Over time, I also learned that Red Hat believes in the principle of meritocracy: you should always try to embody the best of ideas, regardless of whether it comes from senior management or from an intern taken on a summer job. In other words, my first impression of Red Hat introduced me to what the future of leadership looked like. ”
Meritocracy is the main value of the open source community. We do not care what degree of the pyramid you occupy, the main thing is how good your ideas are. Here is what Jim offers:
Enthusiasm and involvement 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 “from and to”, right? Otherwise, just do not get everything that can offer their talent. In Red Hat, obstacles to their own projects are leveled to the maximum:
“To manage innovation, companies try a lot. Interesting is the approach of Google. Since Google, since 2004, has become known in every home, leaders 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 famous, but currently closed programs was that all Google employees were offered to spend 20 percent of their work time on almost everything they wanted. The idea was the following: if employees start implementing their own projects and ideas that they are passionate about besides work, they will start creating innovations. So there were successful third-party projects: 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 do not have an established policy regarding how much time each of our employees must spend on “innovation”. Instead of devoting people separate time for self-education, we do so that employees earn the right to spend their time on new things. If frankly, then many of such time is quite small, but there are those who can spend on innovation almost the entire working day.
The most typical case looks like this: someone is working on a third-party project (if he explained to managers its importance - right in the workplace; or during non-working time - on his own initiative), and later this work may take all his present hours. ”
“Lyrical digression. Alex Faiky Osborne - the inventor of the brainstorming method, which is a continuation of the method of synectics today. It is curious that this idea appeared during the Second World War, when Osborne commanded one of the ships of the American cargo caravan, which was in danger of a torpedo attack of a German submarine. Then the captain remembered the method to which the pirates of the Middle Ages resorted: if the crew was in trouble, all the sailors would gather on the deck in order to propose a solution to the problem in turn. There were a lot of ideas, including absurd ones at first glance: for example, the idea to blow a torpedo with the whole team. But the torpedo can be slowed down or even changed its course by the jet of the ship's pump, which is available on every ship. As a result, Osborne even patented the invention: an additional screw is mounted on the side of the ship, which drives a jet of water along the side, and the torpedo slides nearby. ”
Our Jim constantly repeats that it’s not so easy to work in an open organization. Even the leadership gets, because no one is spared from having to defend their opinions. But exactly this approach is needed to achieve a great result:
“Online forums [open source developers] and chat rooms are often filled with lively and sometimes caustic 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 there is always the next round - critical analysis. Although everyone can participate in these disputes, a person needs to be ready to defend his position with all his might. Unpopular ideas, at best, rejected, at worst - will be ridiculed.
Even Linus Torvalds, the creator of the Linux operating system, disagrees with the proposed changes in 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 changing the code Red Hat was asking for to help ensure our customers safety. In reply to Howells' request, Torvalds wrote: “Frankly speaking, this is [unprintable word] idiocy. Everything seems to revolve around these silly interfaces, and for totally idiotic reasons. Why should we do that? I no longer like the existing X.509 parser. Idiotic complex interfaces are being created, and now there will be 11. - Linus 9 ".
Leaving the technical details aside, Torvalds in the next message continued to write in the same vein - and such that I would not venture to quote. This dispute thundered so loudly that it even hit the pages of The Wall Street Journal. [...]
This debate shows that in most companies producing proprietary, non-free 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 which changes are necessary and — most importantly — why they are needed, do not calm down. This, of course, makes the whole process much more erratic and time consuming. ”
We cannot foresee the future, so we should just try:
"We operate 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 going in one software release (version), the higher the likelihood that there will be bugs in this version. The developers of open source software realized that with the rapid and frequent release of software versions, the risk of serious problems with any program decreases, because we don’t bring all updates to the market right away, but in portions to 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 the continuous introduction of minor improvements ultimately creates more innovation. Perhaps there is nothing surprising. One of the key principles of modern manufacturing processes, such as kaizen a or lean b, is to focus on small and gradual changes and updates.
[...] Much of what we work on may not bring success. But instead of spending a lot of time, puzzling over what works and what does not, we prefer to conduct small experiments. The most popular ideas will lead to success, and those that do not work will wither by themselves. Thus, we can try a lot, not just one, and without much risk for the company.
This is a rational way of allocating resources. For example, people often ask me how we choose which of the open source projects to commercialize. Although we sometimes initiate projects, more often we simply connect to existing ones. A small group of engineers - and sometimes one person - begins to contribute to one of the open source community projects. If the project is successful and in demand from 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 may have grown to such an extent that the decision is obvious. A variety of projects, including those not related to software, naturally arise throughout Red Hat, until it becomes clear to everyone that now someone will have to work with this all the time. ”
Here is another quote from the book:
“I realized that to meet such a role, tomorrow’s leaders should be distinguished by characteristics that in ordinary organizations simply do not pay attention. To effectively lead an open organization, a manager must have the following qualities.
Red Hat lives and works on principles that are very different from the traditional organization with hierarchical subordination. 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!
And also this book is about life and about practice. It has a lot of advice for anyone 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 listed in the book that you can take note of right now.
')
(Video available with Russian subtitles)
Jim's job history in the company is remarkable. It shows that there is no fanfare in the open source world, but there is a new approach to leadership:
“After talking with a recruiter, I expressed interest in the interview, and he asked if I would be opposed to flying to Red Hat’s headquarters in Raleigh, North Carolina on Sunday. I thought Sunday was a strange day to meet. But since I was still going to fly to New York on Monday, in general I was on the way, and I agreed. I boarded a plane from Atlanta and landed at Raleigh Durham Airport. From there, I took a taxi that landed me in front of the Red Hat building on the campus of the University of North Carolina. It was Sunday, at 9:30 in the morning, and no one was near. The light was turned off, and, 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. Very soon it started to rain, I did not have an umbrella.
Only I was going to go somewhere to catch a taxi, like Matthew Schulick, later Chairman of the Board of Directors and CEO of Red Hat, drove up in his car. “Hi,” he said. “Would you like to drink coffee?” It seemed like an unusual start to the interview, but I understood that I definitely needed to drink coffee. Ultimately, I thought, then it would be easier for me to catch a taxi to the airport.
Sunday in North Carolina is pretty quiet in the morning. It took us some time to simply find a coffee shop that would open before noon. The coffee shop was not the best in the city and not the cleanest, but it worked and there you could drink freshly brewed coffee. We sat down at the table and began a conversation.
After about thirty minutes or so, I realized that I like how everything goes; the interview was not traditional, but the conversation itself was very interesting. Instead of discussing the subtleties of Red Hat's corporate strategy or its image on Wall Street — that is, doing what I was prepared for — Matthew Schulick asked more about my hopes, dreams, and goals. Now I understand that Shulik assessed whether I would fit 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 going to leave. Then my interlocutor discovered that he did not have a wallet with him. “Oops,” he said. - I have no money. Do you? ”It took me by surprise, but I replied that I had money and I did not mind paying for coffee.
A few minutes later Shulik dropped me off at a small Mexican diner, where I met up 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 restaurant had a machine for credit card payment, and we could only accept cash. Cunningham turned to me and asked if I was ready 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 lift to the airport, and we drove his car. A few minutes later he asked: “Do you mind if I stop and refuel? We rush at full steam. ” “No problem,” I replied. As soon as I heard the rhythmic knock of the pump, there was a knock at the window. It was Cunningham. “Hey, credit cards are not accepted here,” he said. “Can I borrow some money?” I began to wonder if this was really a job interview or some kind of scam.
The next day, while in New York, I discussed this interview with my wife at Red Hat. I told her that the conversation was very interesting, but I am not sure whether these people seriously intend to hire me to work: maybe they just needed free food and gasoline? Recalling that meeting today, I understand that Shulik and Cunningham were simply open people and treated me like any other person with whom they could drink coffee, have lunch or gasoline. Yes, it is funny and even funny that both of them were out of money. But for them it was not about the money. They, like the world around open source, did not believe in rolling out red carpet paths or trying to convince the other person that everything was perfect. They just wanted to get to know me better, and not try to impress or point out our differences. They wanted to know who I was.
My first interview at Red Hat clearly showed me that the work here is of a different nature. This company did not observe the traditional hierarchy and special treatment for managers, at least in the form that is common in most other companies. Over time, I also learned that Red Hat believes in the principle of meritocracy: you should always try to embody the best of ideas, regardless of whether it comes from senior management or from an intern taken on a summer job. In other words, my first impression of Red Hat introduced me to what the future of leadership looked like. ”
Cultivation tips for meritocracy
Meritocracy is the main value of the open source community. We do not care what degree of the pyramid you occupy, the main thing is how good your ideas are. Here is what Jim offers:
- Never say: “So the boss wants” - and do not rely on the hierarchy. This may help you in the short term, but you cannot build a meritocracy.
- Recognize successes and important contributions to the common cause. This may be a simple thank-you email, in a copy of which is the whole team.
- Consider: does your authority depend on the 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. It is necessary to react to everything, to approve - only the best. But don't 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 an exemplary member of your team by offering an interesting assignment, even if it does not belong to his usual field of activity.
Let your "rock stars" follow your passion.
Enthusiasm and involvement 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 “from and to”, right? Otherwise, just do not get everything that can offer their talent. In Red Hat, obstacles to their own projects are leveled to the maximum:
“To manage innovation, companies try a lot. Interesting is the approach of Google. Since Google, since 2004, has become known in every home, leaders 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 famous, but currently closed programs was that all Google employees were offered to spend 20 percent of their work time on almost everything they wanted. The idea was the following: if employees start implementing their own projects and ideas that they are passionate about besides work, they will start creating innovations. So there were successful third-party projects: 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 do not have an established policy regarding how much time each of our employees must spend on “innovation”. Instead of devoting people separate time for self-education, we do so that employees earn the right to spend their time on new things. If frankly, then many of such time is quite small, but there are those who can spend on innovation almost the entire working day.
The most typical case looks like this: someone is working on a third-party project (if he explained to managers its importance - right in the workplace; or during non-working time - on his own initiative), and later this work may take all his present hours. ”
More than brainstorming
“Lyrical digression. Alex Faiky Osborne - the inventor of the brainstorming method, which is a continuation of the method of synectics today. It is curious that this idea appeared during the Second World War, when Osborne commanded one of the ships of the American cargo caravan, which was in danger of a torpedo attack of a German submarine. Then the captain remembered the method to which the pirates of the Middle Ages resorted: if the crew was in trouble, all the sailors would gather on the deck in order to propose a solution to the problem in turn. There were a lot of ideas, including absurd ones at first glance: for example, the idea to blow a torpedo with the whole team. But the torpedo can be slowed down or even changed its course by the jet of the ship's pump, which is available on every ship. As a result, Osborne even patented the invention: an additional screw is mounted on the side of the ship, which drives a jet of water along the side, and the torpedo slides nearby. ”
Our Jim constantly repeats that it’s not so easy to work in an open organization. Even the leadership gets, because no one is spared from having to defend their opinions. But exactly this approach is needed to achieve a great result:
“Online forums [open source developers] and chat rooms are often filled with lively and sometimes caustic 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 there is always the next round - critical analysis. Although everyone can participate in these disputes, a person needs to be ready to defend his position with all his might. Unpopular ideas, at best, rejected, at worst - will be ridiculed.
Even Linus Torvalds, the creator of the Linux operating system, disagrees with the proposed changes in 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 changing the code Red Hat was asking for to help ensure our customers safety. In reply to Howells' request, Torvalds wrote: “Frankly speaking, this is [unprintable word] idiocy. Everything seems to revolve around these silly interfaces, and for totally idiotic reasons. Why should we do that? I no longer like the existing X.509 parser. Idiotic complex interfaces are being created, and now there will be 11. - Linus 9 ".
Leaving the technical details aside, Torvalds in the next message continued to write in the same vein - and such that I would not venture to quote. This dispute thundered so loudly that it even hit the pages of The Wall Street Journal. [...]
This debate shows that in most companies producing proprietary, non-free 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 which changes are necessary and — most importantly — why they are needed, do not calm down. This, of course, makes the whole process much more erratic and time consuming. ”
Release early, release often
We cannot foresee the future, so we should just try:
"We operate 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 going in one software release (version), the higher the likelihood that there will be bugs in this version. The developers of open source software realized that with the rapid and frequent release of software versions, the risk of serious problems with any program decreases, because we don’t bring all updates to the market right away, but in portions to 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 the continuous introduction of minor improvements ultimately creates more innovation. Perhaps there is nothing surprising. One of the key principles of modern manufacturing processes, such as kaizen a or lean b, is to focus on small and gradual changes and updates.
[...] Much of what we work on may not bring success. But instead of spending a lot of time, puzzling over what works and what does not, we prefer to conduct small experiments. The most popular ideas will lead to success, and those that do not work will wither by themselves. Thus, we can try a lot, not just one, and without much risk for the company.
This is a rational way of allocating resources. For example, people often ask me how we choose which of the open source projects to commercialize. Although we sometimes initiate projects, more often we simply connect to existing ones. A small group of engineers - and sometimes one person - begins to contribute to one of the open source community projects. If the project is successful and in demand from 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 may have grown to such an extent that the decision is obvious. A variety of projects, including those not related to software, naturally arise throughout Red Hat, until it becomes clear to everyone that now someone will have to work with this all the time. ”
Here is another quote from the book:
“I realized that to meet such a role, tomorrow’s leaders should be distinguished by characteristics that in ordinary organizations simply do not pay attention. To effectively lead an open organization, a manager must have the following qualities.
- Personal strength and confidence. Ordinary leaders use positional power - their position - in order to succeed. But during a meritocracy, leaders are required to earn respect. And this is possible only if they are not afraid to admit that they do not have all the answers. They must be prepared to discuss problems and make quick decisions in order to find the best solutions with their team.
- Patience. The media rarely tell stories about how “patient” a leader is. But he really has to be patient. When you work to get maximum effort and results from your team, you 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 the intellectual abilities of managers, focusing on their IQ, when in fact their emotional intelligence factor, 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 involved employees, like in Red Hat, and you do not have the ability to order someone, your ability to listen, analytically process and not take everything into your account becomes incredibly valuable.
- Another mentality. Executives who came from traditional organizations were brought up in the spirit of quid pro quo (lat. "Quid pro quo"), according to which every action must 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 need to get rid of the type of thinking that requires them to achieve results today and at any cost, and to begin such business management, which will allow to obtain greater benefits through investment in the future. "
And why is this important?
Red Hat lives and works on principles that are very different from the traditional organization with hierarchical subordination. 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!
Source: https://habr.com/ru/post/453088/
All Articles