An important day has come for Red Hat, the Russian open source community and all those involved - in Russian it was released . She tells in detail and vividly how we at Red Hat give way to the best ideas and the most talented people, and also 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 a lot of advice for anyone who wants to learn how to build an open organization and manage it effectively. Below are some of the most important principles in the book that you can take note of right now.
Jim's employment history with the company is remarkable. She shows that there is no fanfare in the world of open source, but there is a new approach to leadership:
“After speaking with the recruiter, I expressed interest in an interview and he asked if I would mind flying to Red Hat 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 generally on my way, and I agreed. I boarded a plane from Atlanta and landed at Raleigh Durham Airport. From there, I took a taxi, which dropped me off in front of the Red Hat building on the campus of the University of North Carolina. It was Sunday, at 9:30 am, and no one was around. The lights were off and on checking I found the doors were locked. At first I thought I was being fooled. Turning to return to the taxi, I saw that it had already left. It started to rain very soon and I didn't have an umbrella.
Just as I was about to go somewhere to hail a cab, Matthew Shulik, later Chairman of the Board of Directors and CEO of Red Hat, pulled up in his car. “Hi,” he greeted. “Do you want to drink coffee?” It seemed like an unusual start to an interview, but I knew I definitely needed coffee. Ultimately, I thought, then it will be easier for me to catch a taxi to the airport.
Sunday mornings in North Carolina are fairly quiet. It took us a while just to find a coffee shop that opened before noon. The coffee shop was not the best in the city and not the cleanest, but it worked and you could drink freshly brewed coffee there. We sat down at a table and started talking.
After about thirty minutes or so, I realized that I liked the way things were going; 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 was prepared for—Matthew Shulik asked more about my hopes, dreams, and goals. Now I understand that Shulik was assessing whether I would fit into the subculture and management style of the company.
After we finished, Shulik said he wanted to introduce me to the company's general counsel, Michael Cunningham, and suggested that I meet him now for an early lunch. I agreed and we got ready to leave. Then my interlocutor discovered that he did not have his wallet with him. “Oops,” he said. - I have no money. And you?" This took me by surprise, but I replied that I had the money and didn't mind paying for coffee.
A few minutes later Shulik dropped me off at a small Mexican diner where I met Michael Cunningham. But again, there was no traditional interview or business meeting, but another interesting conversation took place. When we were about to pay the bill, it turned out that the credit card machine in the restaurant broke down, and we can only accept cash. Cunningham turned to me and asked if I was willing to pay because he had no 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. After a few minutes, he asked, “Do you mind if I stop and fill up? We will run at full speed." “No problem,” I replied. As soon as I heard the rhythmic thud of the pump, there was a knock at the window. It was Cunningham. "Hey, they don't accept credit cards here," he said. “Can I borrow some money?” I started to wonder if this was a real 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'm not sure if these people are serious about hiring me: maybe they just needed free food and gasoline? Looking back at that meeting today, I realize that Shulik and Cunningham were just open people and treated me like any other person they could have coffee, lunch or gas with. 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, didn't believe in rolling red carpets or trying to convince someone that everything was perfect. They just wanted to get to know me better, not trying to impress or point out our differences. They wanted to know who I am.
My first interview at Red Hat clearly showed me that the work here is of a different nature. In this company, there was no traditional hierarchy and special treatment for managers, at least in the form that is customary in most other companies. Over time, I also learned that Red Hat believes in the principle of meritocracy: it's always worth trying the best idea, whether it comes from senior management or a summer intern. In other words, my first impression of Red Hat introduced me to what the future of leadership looks like.”
Tips for Cultivating Meritocracy
Meritocracy is the core value of the open source community. It doesn't matter to us which level of the pyramid you occupy, the main thing is how good your ideas are. Here's what Jim suggests:
- Never say, "That's what the boss wants," and don't rely on hierarchy. This may help you in the short term, but you can't build a meritocracy that way.
- Publicly recognize successes and important contributions to the common cause. It could be a simple thank you email with the entire team on copy.
- Think about it: is your authority based on position in the hierarchy (or access to privileged information), or is it the result of the respect you have 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 test - only the best. But don't just take the best ideas and move on with them - use every opportunity to bolster the spirit of meritocracy by giving credit to all who deserve it.
- Recognize a model 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 their passion
Enthusiasm and engagement are two very important words in an open organization. They are repeated throughout the book. But you can't get passionate creative people to work hard, right? Otherwise, you simply won't get everything their talent has to offer. At Red Hat, obstacles for own projects are leveled as much as possible:
“To drive innovation, companies try a lot. Google's approach is interesting. Ever since Google became known in every home since 2004, leaders and ideologues 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 asked to spend 20 percent of their working time on almost whatever they please. The idea was this: if employees begin to implement their own projects and ideas that they are passionate about outside of work, they will begin to create innovations. This is how successful third-party projects arose: GoogleSuggest, AdSense for Content and Orkut; they all came from this 20 percent experiment - an impressive list! […]
We at Red Hat take a less formal approach. We don't have a set policy on how much time each of our employees should spend on "innovating". Instead of giving people a separate time for self-education, we make sure that employees earn the right to spend their time on new things. To be honest, many people have quite a bit of such 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 side project (if he explained to managers its importance - right at the workplace; or after hours - on his own initiative), and later this work can take all his attendance hours.
More than brainstorming
"A lyrical digression. Alex Fakeney Osborne is the inventor of the brainstorming method, the continuation of which is the synectics method today. It is curious that this idea appeared during the Second World War, when Osborne commanded one of the ships of an American cargo caravan that was in danger of a torpedo attack by a German submarine. Then the captain remembered the trick used by the pirates of the Middle Ages: if the crew got into trouble, all the sailors gathered on deck to propose a solution to the problem one by one. There were a lot of ideas, including at first glance absurd ones: for example, the idea of blowing on a torpedo with the whole team. But with a jet of a ship's pump, which is available on every ship, it is quite possible to slow down a torpedo or even change its course. As a result, Osborne even patented an 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 alongside.
Our Jim keeps saying that it's not easy to work in an open organization. Even the leadership gets it, since no one is spared the need to defend their opinion. But this is exactly the approach you need to achieve an excellent result:
“Online [open source] forums and chat rooms are often filled with lively and sometimes biting discussions about everything from how best to fix a software bug to 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 anyone can participate in these disputes, a person needs to be ready to defend his position with all his might. Unpopular ideas are at best rejected, at worst ridiculed.
Even Linus Torvalds, the creator of the Linux operating system, has expressed his disagreement with the proposed code changes. One day, Linus and David Howells, one of the lead developers at Red Hat, got into a heated argument about the benefits of changing the code that Red Hat asked for, which would help keep our customers safe. In response to an inquiry from Howells, Torvalds wrote: “Frankly, this [unprintable word] is idiotic. 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. Stupid complex interfaces are being created, and now there will be 11. - Linus 9.
Leaving technical details aside, Torvalds continued to write in the same vein in the next message - and in such a way that I would not dare to quote. This dispute thundered so loudly that it even made it to the pages of The Wall Street Journal. […]
This debate shows that most proprietary, nonfree software companies have no open debate about what new features or changes they might be working on. When the product is ready, the company simply ships it to the customers and moves on. At the same time, in the case of Linux, discussions about exactly what changes are needed and - most importantly - why they are needed, do not stop. This, of course, makes the whole process a lot more messy and time consuming.”
Release early, release often
We can't 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 are collected in one release (version) of the software, the higher the likelihood that there will be bugs in this version. Open source software developers have realized that with the rapid and frequent release of software versions, the risk of serious problems with any program is reduced - after all, we do not bring all updates to the market at once, but one portion for each version. Over time, we noticed that this approach not only reduced the number of errors, but also led to more interesting solutions. It turns out that constantly making small improvements ultimately creates more innovation. Perhaps there is nothing surprising here. One of the key tenets of modern manufacturing processes like kaizen a or lean b is a focus on small and incremental changes and updates.
[…] A lot of what we are working on may not be successful. But instead of spending a lot of time figuring out 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. This way we can try many things, not just one thing, and without much risk to the company.
This is a rational way of allocating resources. For example, people often ask me how we choose which open source projects to commercialize. While we sometimes initiate projects, most of the time we just tap into existing ones. A small group of engineers—sometimes just one person—begins to contribute to one of the projects in the open source community. 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 move on to a new project. By the time we decide to commercialize the proposal, the project may have grown to such an extent that the solution is obvious. Projects of all kinds, including non-software, naturally spring up 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 in order to qualify for this role, tomorrow's leaders must have characteristics that are simply overlooked in conventional organizations. To effectively lead an open organization, a leader must possess the following qualities.
- Personal strength and confidence. Ordinary leaders use positional power—their position—to achieve success. But in a meritocracy, leaders must 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 willing to discuss problems and make decisions quickly 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 must be patient. When you're working to get the best out of your team, talking for hours and repeating things over and over again until you get it right, you need to be patient.
- High EQ (emotional intelligence). Too often we advertise the intelligence of executives by focusing on their IQ, when what really needs to be taken into account is their emotional intelligence quotient, or EQ score. 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 engaged employees, like at Red Hat, and you don't have the ability to order anyone, your ability to listen, process analytically, and not take everything personally becomes incredibly valuable.
- Another mentality. The leaders who came from traditional organizations were brought up in the spirit of quid pro quo (quid pro quo in Latin), according to which every action should receive an adequate return. But when you're going to invest in building a particular community, you need to think long term. It's like trying to build a delicately balanced ecosystem, where any wrong move can create imbalances and lead to long-term losses that you may not notice right away. Leaders must get rid of the mindset that requires them to achieve results today at any cost and start doing business in a way that will allow them to reap greater rewards by investing in the future.”
And why does it matter
Red Hat lives and works on principles very different from the traditional hierarchical organization. And it works, it makes us commercially successful and humanly happy. We have translated this book in the hope of spreading the principles of open organization among Russian companies, among people who want and can live differently.
, try!
Source: habr.com