A significant day has arrived for Red Hat, the Russian open-source community, and everyone involved â Jim Whitehurst's book "Open Organization: A Passion That Delivers" has been published in Russian. Moreover, this book is about life and practice. It offers numerous insights for anyone looking to learn how to build a company based on the open organization model and effectively manage it. Below are some key principles from the book that you can take note of right now.
The story of Jim's hiring at the company is noteworthy. It shows that in the world of open source, there are no fanfares, but there is a new approach to leadership:
"After speaking with the recruiter, I expressed my interest in an interview, and he asked if I would mind flying to the headquarters of Red Hat in Raleigh, North Carolina, on a Sunday. I thought that Sunday was a strange day for a meeting. However, since I was going to New York on Monday anyway, it was somewhat on my way, so I agreed. I boarded 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 building on the University of North Carolina campus. It was Sunday, the clock showed 9:30 AM, and there was no one around. The lights were off, and upon checking, I found that the doors were locked. At first, I thought I was being pranked. Turning to go back to the taxi, I saw that it had already left. It started raining very soon, and I had no umbrella.
Just as I was about to go somewhere to catch a taxi, Matthew Szulik, who later became the chairman and CEO of Red Hat, pulled up in his car. "Hi," he greeted. "Would you like to grab a coffee?" I found it an unusual way to start an interview, but I understood that I definitely needed that coffee. In the end, I thought it would make it easier for me to catch a taxi to the airport afterward.
Just as I was about to head out somewhere to catch a taxi, Matthew Szulik, then Chairman and CEO of Red Hat, rolled up in his car. "Hello," he greeted. "Would you like to have a coffee?" I found this to be an unusual start to an interview, but I knew I definitely needed a coffee. Ultimately, I thought it would make it easier for me to catch a taxi to the airport later.
Sunday mornings in North Carolina are quite calm. It took us some time to find a coffee shop that opened before noon. The coffee shop turned out to be neither the best in town nor the cleanest, but it was open and served freshly brewed coffee. We sat at a table and started our conversation.
After about thirty minutes, I realized that I liked how things were going; the interview wasn't traditional, but the conversation turned out to be quite interesting. Instead of discussing the intricacies of Red Hat's corporate strategy or its image on Wall Street â which is what I had 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 company's subculture and management style.
After we finished, Shulik mentioned that he wanted to introduce me to the company's general counsel, Michael Cunningham, and suggested we meet him right then for an early lunch. I agreed, and we started to leave. Then my companion realized he didn't have his wallet with him. 'Oops,' he said. 'I have no money. Do you?' This caught me off guard, but I replied that I had money and didn't mind paying for the coffee.
A few minutes later, Shulik dropped me off at a small Mexican eatery, where I met Michael Cunningham. But once again, there was no traditional interview or business meeting; instead, there was another interesting conversation. When we were about to pay the bill, it turned out that the restaurant's credit card machine was broken, and they could only accept cash. Cunningham turned to me and asked if I was willing to pay, as he didn't have cash on him. Since I was heading to New York, I had plenty of cash, so I paid for lunch.
Cunningham offered to drive me to the airport, and we took his car. After a few minutes, he asked, 'Do you mind if I stop and get gas? We'll be on our way in no time.' â 'No problem,' I replied. As soon as I heard the rhythmic thump 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 really an interview or some sort of scam.
The next day, while in New York, I discussed the interview with my wife at Red Hat. I told her that the conversation was quite interesting, but I wasn't sure if these people were seriously intending to hire me: maybe they just needed free food and gas? Reflecting on that meeting today, I realize that Shulik and Cunningham were just open people who treated me like anyone else they could have coffee, lunch, or get gas with. Yes, it's funny and even amusing that both of them were short on cash. But for them, it wasn't about the money. Like the world of open source, they didn't believe in rolling out the red carpet or trying to impress the interviewee by pretending everything was perfect. They simply wanted to get to know me better, not to make an impression or point out our differences. They wanted to know who I was.
My first interview at Red Hat made it clear that working here is different. This company didn't exhibit the traditional hierarchy or special protocols for leaders, at least not in the form commonly seen in most other companies. Over time, I also learned that Red Hat believes in the principle of meritocracy: it's always worth attempting to implement the best ideas, regardless of whether they come from upper management or an intern hired for the summer. 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 what level of the pyramid you occupy; what matters 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 meritocracy this way.
- Publicly acknowledge successes and important contributions to the common cause. This could be a simple thank you email, with the entire team copied.
- Consider: does your authority depend on your position in the hierarchy (or access to privileged information) or is it a result of the respect you've earned? If it's the former, start working on the latter.
- Ask for feedback and gather ideas on specific topics. You should respond to everything, trying out only the best. But donât just take the best ideas and move forward â use any opportunity to strengthen the spirit of meritocracy by giving due credit to everyone who deserves it.
- Recognize an exemplary team member by offering them an interesting task, even if itâs outside their usual area of expertise.
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 force passionate creative people to work 'from start to finish,' right? Otherwise, you simply wonât get everything their talent has to offer. At Red Hat, obstacles for personal projects are minimized significantly:
To manage innovation, companies try many things. One interesting approach is from Google. Ever since Google became known in every home starting in 2004, leaders and ideologists in the internet business have been trying to decipher the company's main secret in order to replicate its impressive success. One of the most famous, yet currently closed, programs was that all Google employees were encouraged to spend 20 percent of their working time on practically anything they wanted. The idea was this: if employees begin to pursue their own projects and ideas they are passionate about outside of work, they will start to create innovations. This led to successful side projects: Google Suggest, AdSense for Content and Orkut; all of them originated from this 20 percent experiment â an impressive list!
At Red Hat, we take a less formal approach. We donât have a set policy regarding how much time each of our employees should spend on 'innovation.' Instead of allocating specific time for self-education, we enable employees to earn the right to spend their time on new initiatives. Frankly, many have very little time for this, though there are those who can dedicate almost their entire workday to innovation.
The most typical scenario looks something like this: someone is working on an external project (if they explained its significance to their managersâeither at their workstation or in their own time on their initiative), and later this work can take up all of their available hours.
More than just brainstorming
A lyrical digression. Alex Faickney Osborn is the inventor of the brainstorming method, the continuation of which is today's synectics method. Interestingly, this idea emerged during World War II when Osborn commanded one of the ships in an American cargo convoy that was in peril of a torpedo attack by a German submarine. At that moment, the captain recalled a tactic used by pirates in the Middle Ages: when the crew was in trouble, all sailors would gather on deck to suggest solutions to the problem one by one. There were many ideas, including some that seemed absurd at first glance: for instance, the idea of blowing on the torpedo as a whole crew. However, with the ship's pump, which is found on every vessel, you can effectively slow down a torpedo or even change its course. As a result, Osborn even patented the invention: a additional screw mounted to the side of the ship, which drives a jet of water along the hull while the torpedo glides alongside.
Our Jim continually emphasizes that working in an open organization isnât easy at all. Even the leadership feels the strain, as no one is free from the need to defend their opinion. But this approach is precisely what is needed to achieve outstanding results:
"Online forums [open-source developers] and chats are often filled with lively, and sometimes sharp, discussions about everythingâfrom how to best fix a software bug to what new features to consider for the next update. Typically, this is the first stage of discussions where new ideas are proposed and accumulated, but there is always a subsequent roundâcritical analysis. While anyone can participate in these debates, one must be prepared to defend their position vigorously. Unpopular ideas are at best dismissed, and at worst ridiculed."
Even Linus Torvalds, the creator of the Linux operating system, expresses his disagreement with proposed changes to the code. Once, Linus and David Howells, one of the leading developers at Red Hat, engaged in a heated debate over the merits of modifying the code requested by Red Hat, which would help ensure our clientsâ security. In response to Howells' request, Torvalds wrote: "Frankly, this [expletive] is idiocy. Everything seems to revolve around these stupid interfaces, and for absolutely idiotic reasons. Why should we do it this way? I already don't like the existing X.509 parser. Ridiculously complex interfaces are being created, and now there will be 11 of them. â Linus 9."
Leaving technical details aside, Torvalds continued in the same tone in his next messageâand in ways that I wouldn't dare to quote. This dispute garnered so much attention that it even made it onto the pages of The Wall Street Journal. [...]
This dispute shows that in most companies releasing proprietary, non-free software, there are no open debates about what new features or changes they might work on. When a product is ready, the company simply sends it out to customers and moves on. In contrast, discussions regarding what changes are necessary andâmost importantlyâwhy they are necessary, continue to thrive in the case of Linux. This, of course, makes the entire process much messier and more labor-intensive."
Release early, release often
We cannot foresee the future, so we must just try:
We operate on the principle of 'early launch, frequent updates.' The key problem with any software project is the risk of errors or bugs in the source code. Clearly, the more changes and updates accumulate in one release (version) of software, the higher the likelihood that this version will contain bugs. Open-source developers recognized that with rapid and frequent release cycles, the risk of significant issues with any program decreases â as we donât release all updates at once, but rather in batches for each version. Over time, we have noticed that this approach not only reduces the number of errors but also leads to more interesting solutions. It turns out that continually implementing small improvements ultimately generates more innovation. Perhaps thereâs nothing surprising here. One of the key principles of modern production processes, such as Kaizen or Lean, is a focus on small and gradual changes and updates.
[...] Much of what we work on may not succeed. But instead of spending a lot of time trying to figure out what will work and what wonât, we prefer to conduct small experiments. The most in-demand ideas will lead to success, while those that donât perform will fizzle out on their own. This way, we can try many things instead of just one, and do so with minimal risk to the company.
This is a rational way to allocate resources. For example, people often ask me how we choose which open-source projects to commercialize. While we sometimes initiate projects, more often we simply connect with existing ones. A small group of engineers â or sometimes just one person â starts contributing to one of the open-source community projects. If the project is successful and in demand by our clients, we begin to invest more time and effort into it. If not, developers move on to a new project. By the time we decide to commercialize a proposal, the project may have grown to the point where the decision is obvious. A wide variety of projects, including those unrelated to software, naturally arise throughout Red Hat, until it becomes clear that someone will need to work on this constantly.
Hereâs another quote from the book:
I realized that to meet such a role, tomorrowâs leaders must possess characteristics that traditional organizations simply overlook. To effectively lead an open organization, a leader must have the following qualities.
- Personal power and confidence. Ordinary leaders use positional power â their title â to succeed. But in a meritocracy, leaders must earn respect. This is only possible if they are not afraid to admit that they do not have all the answers. They must be willing to discuss problems and make quick decisions to find the best solutions together with their team.
- Patience. The media rarely tell stories about how âpatientâ a leader is. But they truly must be patient. When you are working to get the most effort and results out of your team, engaging in dialogue for hours, and repeating something over and over until everything is done right, you need to be patient.
- High EQ (Emotional Intelligence). Too often, we promote the intellectual capabilities of leaders, focusing on their IQ, when in reality, we need to consider their emotional intelligence quotient, or EQ. Being the smartest person among others is not enough if you cannot work with those people. When you are working with engaged employee communities, like at Red Hat, and you have no authority to command anyone, your ability to listen, process analytically, and not take everything personally becomes incredibly valuable.
- A Different Mindset. Leaders coming from traditional organizations have been raised in the spirit of quid pro quo, where every action must yield a suitable return. But when youâre looking to invest in building a community, you need to think long-term. Itâs like trying to build a finely tuned ecosystem, where any misstep can create imbalance and result in long-term losses that you might not notice right away. Leaders need to shed that type of thinking that demands immediate results at any cost and adopt a business approach that will yield greater benefits through investments in the future.
And why it matters
Red Hat lives and works by principles that are markedly different from traditional hierarchical organizations. And it works; it makes us commercially successful and humanly happy. We have translated this book in hopes of spreading the principles of open organization among Russian companies, among people who want and can live differently.
, try it out!
Source: habr.com
