IBM and the Open Organization

On October 28, 2018, IBM announced plans to acquire Red Hat. The CEO of Red Hat is Jim Whitehurst, and Mr. Whitehurst released a book titled "The Open Organization" in 2015. The book details a management philosophy Mr. Whitehurst acquired when he joined Red Hat in 2007. The book is broken down into three parts: why, how, and what. Here I attempt to distill the contents of those sections into my favorite quotes.

Forward

Nearly the first 20% of the book is the forward, and it is worth picking up for that content alone. In that section you will find Mr. Whitehurst's definition of the "open organization."

An “open organization” — which I define as an organization that engages participative communities both inside and out — responds to opportunities more quickly, has access to resources and talent outside the organization, and inspires, motivates, and empowers people at all levels to act with accountability.

Why: Motivating and Inspiring

What is the purpose of your organization? In the developer relations group that I manage, we have one purpose: Make developers heroes for what it is that they are trying to achieve. While I would love to claim credit for that purpose, it comes from John Sheehan while at Twilio. It does not define what we do per se, but certainly says why we do what we do, which is a distinction that Mr. Whitehurst makes about open organizations.

Purpose is often misunderstood. It’s not what a group does but why it does what it does. It’s not a goal but a reason—the reason it exists, the need it fulfills, and the assistance it bestows. It is the answer to the question every group should ask itself: if we disappeared today, how would the world be different tomorrow?

Igniting Passion

Passion is a topic that comes up repeatedly throughout the book, not just in this section. In my experience, passion is often replaced by metrics. The message is clear - do not go after what you passionately think will help our company, but rather, go after what I tell you will help our company. In short: You do not know, I do, shut up and do what I say. That is perhaps the quickest path to destroy passion.

What sets open organizations apart, and what gives them a true competitive advantage, is that they also have embraced the idea that they need to activate the emotional passions and desires among their workers to actually reach that ultimate destination as defined by their purpose.

But ... metrics! You might be inclined to think that the metrics-driven approach would seem to obviously have a negative impact on igniting passion. And that subsequently, management would catch on and more carefully consider their approach. Yet, metrics persist. This is not a fault of their own, but rather what is taught.

In management science, the simplifying assumption is that people are rational, value-maximizing, unemotional cogs.

As Mr. Whitehurst notes, the open organization should have metrics. To me it is about how those metrics are applied. Are they applied to drive behavior, or to measure the effectiveness of the purpose? In developer relations, we are all well aware of the unintended consequences around "vanity metrics." If I tell my team to blog n-times, then often I will end up with n-amount of half-baked posts. Conversely, what happens if we frame the goals of the organization in the context of content that helps developers be heroes?

When you have passion inside your organization ... a leader and manager’s role becomes more about creating context and reinforcing what purpose and end goal the organization is working toward.

Building Engagement

Engagement lies at the core of developer relations. You can hire an army of advocates, but reaching the 23 million developers in the world is something you can simply not do by yourself. Developer relations organizations must find those developers outside of the organization and engage them directly - igniting their passion.

Additionally, the most engaged community members have taken on the role of community moderators and are leading the continued evolution of the site. These volunteer moderators don’t work for Red Hat, but have a personal interest in the open source way. They contribute their time to write articles, engage with commenters, and spread the word about content on social media.

How then does one engage developers? Mr. Whitehurst starts internally and then expands to outside of the organization. Many of his stated principles however apply equally. First things first, we need to let people know that they are not cogs - that we, as representatives of a given company, and thus the company itself, actually care.

People need to believe that the company and its leaders care about them.

We then need to let them know what we are about. Many companies shy away from talking about roadmaps, but in successful open source projects, the roadmaps are transparent. I am a big fan of having product teams openly blog about what they are thinking, why they are thinking about those interests, and establishing an open dialog on social channels.

People thirst for context; they want to know the whats and whys of their company’s direction, and they want to be part of making it successful.

Of course talking about yourself (your company) all the time can easily become what I like to call a marketing "megaphone". When you are IBM, with hundreds of thousands of employees, that megaphone is extremely loud. Talking about yourself all the time does not a relationship [engagement] make. We must also be willing to listen, and act.

You won’t hear employees if you’ve delegated the task of listening.

In my opinion, feedback is a gift.

The worst possible thing is if employees contribute their best ideas and nothing happens. Listening is simply not enough.

These all talk of the company/employee relationship, but I think it is equally applicable to the company/customer relationship.

How: Getting Things Done

As a fan of the "Getting Things Done" (GTD) methodology, the title of this part of the book drew me right in, and I kept on reading. Alas, this section is not about that methodology. It is about how you get things done if you have all these pieces (non-company developers) moving around and doing things based on their passions.

To be a member of the Athenian politeia, according to the authors of A Company of Citizens, meant that you thought, argued, and acted with your fellow citizens, and that you learned through the practice of civic life.

It might seem that this is chaos to most managers. As Mr. Whitehurst argues repeatedly, the financial success of Red Hat would suggest otherwise.

Meritocracy Not Democracy

As an American, I am pretty bullish on democracy, or at the very least, the republic, so the title of this section had me concerned at first. There is substantialresearch to show that meritocracy can become institutionalized class warfare. As I read through the concepts presented however, a strong case is made for the application of meritocracy within the open organization.

But the path to building influence really is about quality over quantity.

Who does not want a quality product? Quality documentation? Quality engagement? Another John Sheehan concept is to make sure you have good product first and foremost. The argument made by The Open Organization then is that, via meritocracy, we must let those with the best knowledge of the product be free to innovate.

Freeing up the thought leaders and rock stars can jumpstart innovation, something every company and business is trying to bottle.

You may have heard of 20% time (or 10% time, or other value) in which developers get time to work on whatever it is that inspires them. I have long held the view that advocates spend more like 80% innovating on gaps to lower barriers to entry with a given product - this can take the form of SDK development, or in an open source world, contribution directly to the code base. Mr. Whitehurst seems to agree, and rather than just leave this to advocates, opens it up across the entire organization.

We want the people who have proven to be great innovators to spend all of their time innovating, not just 20 percent of it.

What about that Vice President of XYZ that dictates a specific direction - specific work to be done? Senior Vice President? Executive Vice President? The suggested answer to this seems to center around meritocracy - specifically, has that person earned the respect, or are they managing by title?

Ask yourself if you command respect because people have to respect you or, rather, because you’ve truly earned respect.

When people respect you only because of your authority, they will give you the minimum effort.

From my days in the military, I would coin this as "leadership by example" rather than meritocracy. Do not give me crap about the polish of my boots if yours do not look like they have been polished since they were issued.

Turning back to developer relations, internally you should be weary of demanding specific action if you cannot or have not demonstrated your ability to deliver on said action. Externally, we cannot expect non-company developers to be engaged with the product if we ourselves are not engaged. Eat your own dog food.

Letting Sparks Fly

Now firmly back in the realm of developer relations, many organizations want to control the conversation of their product. This reminds me of one of my favorite Harvard Business Review (HBR) articles on Coca-Cola, where the company lets go of brand ownership, and effectively reignites financial success. Among my favorite lines from the article is "accept that you don't own your brands; your consumers do". Whoa!

Our findings show that debate and criticism do not inhibit ideas but, rather, stimulate them relative to every other condition.

In developer relations, if developers are talking about your product, especially in a critical manner, then they have just opened the door for engagement. This is the chance to share the decisions you have made, and why you chose them. However, you must be prepared to be wrong, and to take corrective action. This cannot be simply more "megaphone".

One of the biggest threats any executive faces is the notion that he or she is only hearing the good stuff about the business.

A colleague of mine at IBM, who shall remain nameless, once told me that monthly management reports excel at "turning shit into diamonds". This is a very real danger for developer relations. If what you are experiencing with non-company developers, or product, is shit, then you need to report it that way. If you polish it up, then those above you polish it up, then those above them, and so on. By the time it reaches the top of the organization, that shit shines like diamonds. Executive in turn think everything is going great, and make decisions that do no work in the best interests of the company.

But you don’t want to strip away differences in trying to get to consensus, because that can lead to groupthink, poor decisions, and stalled innovation.

If there is more truth in the hallways than in meetings, you have a problem.

What: Setting Direction

Putting people first, pursuing excellence, embracing change, acting with integrity, and serving our world.

I think I just heard managers in traditional hierarchical organizations just throw up in their mouths a little. Yes, let us all just gather round and hug one another now. How can I be expected to lead if we are all gathered around singing "Kumbaya"? This is where The Open Organization turns next, as it seeks to close out this persuasive argument on a structure markedly different than the traditional top-down approach

Inclusive Decisions

From a developer relations perspective, how well does your company listen to developer feedback? Has it altered or changed its plans based on feedback coming from outside its walls?

Getting people to engage in the decision-making process doesn’t have to be at just the corporate level. It’s a mind-set that leaders throughout the organization should wholeheartedly embrace.

Developers are risk averse. Changing your product can have monumental impacts on their lives - and financial livelihood of the companies for which they work. When you engage your customers in the conversation, you achieve results that are best for them, and in turn best for you. In lieu of having established a good dialog with developers, advocates are a great place for product teams to find out how their changes will impact their customers.

... when you take the time to make your decision-making process transparent, you can still drive progress and get things done, even when your decision is an unpopular one.

If your product team is not actively engaging the developer relations team(s) then you have a problem. If you are on the product side, I get it - including advocates may seem as though you are inviting dissent. Advocates are there to help - after all they have a vested interest in seeing the product succeed as well. Nobody wants to get up on stage at a conference knowing full well that the product just pissed off a percentage of the audience - or is about to.

"Lance recognized that solving the problem was not about holding endless discussions or answering every concern before we took action,” DiMaio said. “It was more about acknowledging people’s concerns and then putting an exit plan in place if things didn’t work out."

Catalyzing Direction

Advocates come in all "shapes and sizes". That is to say that some are master networkers, while others posses unparalleled insight into how the source code works. Both can contribute in their own ways. It is a matter of how they approach that work that impacts how well it relates to engagement.

We contribute to our communities, doing what we believe is in their best long-term interest, by building up positions of thought leadership within.

By having capable, engaged people recognize the importance of the goal and then expecting them to solve it in their own way, thousands of small tweaks can be made across the company. That’s much richer and subtler than the handful of big initiatives that a top-down planning process would generate.

With engagement in place, Mr. Whitehurst turns to experimenting your way to success. Any experienced advocate knows this process well - any developer, really. You think you can implement your solution in one way, only to find gaps that make you have to explore another direction. It is these gaps that developer relations should, through experimentation, seek out and fill.

When the bosses make the decisions, decisions are made by politics, persuasion, and PowerPoint. When you make decisions through experiment, the best idea can prove itself.

The important implication for management is in fostering the culture that allows that experimentation to happen in the first place.

I believe the new skill in leadership is leadership by experiment.

Epiloge

The epilog of The Open Organization focuses on the journey once you have decided to embrace the presented concepts. It can get pretty touchy-feely at points, but contrary to what traditional management science may suggest - you unemotional cog - I think it really gets to the core of what an open organization is about, and frankly how developer relations organizations should function.

We at Red Hat beat our competitors to market and react more quickly to threats and opportunities not because we pedal faster, but because the organization taps into powerful energy sources like purpose, passion, and community that make it move faster.

Next Steps

I have clearly taken a very developer relations-centric view on The Open Organization. After more than a decade of working in developer relations, I have experienced many of the concepts presented first-hand - and I know all too well the traditional management perspective that just does not "get it." To me The Open Organization was almost a formalizing of those lessons, presented by an old-school traditional manager. A thoroughly enjoyable read.

Time will tell what the acquisition of Red Hat by IBM will mean to the cultures of both companies. If The Open Organization is any indicator of what might be expected, then I think the combined forces have a great chance at success.