Defaulting to five open principles

The challenges of decoding open source DNA

Not everyone "defaults to open." Demonstrating how it's possible is a humbling and instructive challenge.

sharing open ideas
Image by : 
Opensource.com
x

Subscribe now

Get the highlights in your inbox every week.

In 2018, I surpassed a few personal milestones. In February, I celebrated 15 years of working at Red Hat. Then, in May, I turned the big 40—so you can imagine why I might be feeling more reflective of life in general these days.

Marking both these occasions made me realize I've spent a large part of my life growing up in an open organization—and that the open source way is firmly embedded in my DNA. That means my default behavior is different from that of others who might have spent any number of years at a traditional organization. While working with people at other companies, organizations, and nonprofits, I've discovered just how strikingly different my work habits can be. How I approach collaboration stops many people in their tracks. It's more noticeable now that I'm aware of it this rift.

We have this mantra at Red Hat: "Default to open." It translates, more or less, into something like: We must have an affirmative reason—be it legal or a matter of privacy or some other legitimate reason—to "close" information. Defaulting to open has many advantages, but it introduces challenges as well—especially when it introduces differences in the way people work together.

I'd like to explore these differences by taking a look at the five principles of an open organization, describe how I apply them to my work, and decode some of this open source DNA. These principles are key to understanding why working with other organizations can be challenging and many times frustrating. Knowing that I may have to translate the DNA of open source has been a huge help in alleviating some of those pain points.

Let's go under the cultural microscope to see what we can discover.

Transparency

Transparency is scary and empowering at the same time. One of my favorite things to highlight is how transparency creates accountability. The fact that you can share information with your team, department, or your entire organization creates a sense of obligation. Whether you're ahead or behind on a goal, having others see your progress toward a commitment helps you remain accountable for outcomes.

Transparency means sharing information and giving equal access to those who need to access to said information. This is the opposite of hoarding information and knowledge because you think it gives you some sort of power or an upper hand. This might be true in some cases, but not in a organization where knowledge sharing is highly valued. I've experienced countless moments in which I've stumbled upon information about a project or found the answer to a problem I was trying to solve because someone took the time to write it down and share it.

There is more power to freely sharing knowledge, information, and details as broadly as possible, at the right time, and in the right place. The flip side is that working in an open organization often means sifting through lots of information when seeking a definitive answer to a question.

Inclusivity

Being inclusive takes work. As a white dude in a world becoming increasingly diverse, the most important thing I can do is be intentional about being inclusive. This means seeking out opinions from people who don't look like me or have the same background as me. It means being intentional about selecting participants and collaborators who bring different perspectives, experiences, and opinions to projects.

When we're working in the fast-paced environments typical of open organization, we might often find it easier to ask for help or input from someone we already know, someone that probably looks and thinks a lot like us, to join a new project or team. Seeking to be more inclusive often means taking more time to make a decision. You'll find that you will take more time seeking input from others and finding different avenues to gather feedback. When you do this, you'll find that once you make a decision, you'll have a lot more support for that decision—because you put more work up front to gather input from people who aren't like you.

Adaptability

Being agile is probably the most important skill to have in our ever-changing world. Much of the material I'm reading now stresses being prepared to react to situations as opposed to making a three, five, or even 10 year plan. The days of preparing a long-term strategy are gone. As Jim Whitehurst, author of The Open Organization says, "long-term planning is dead." Today's world demands a different approach: creating a framework and guiding principles, then letting those guide quick and timely decisions. Having a willingness to try, learn, and modify in an iterative way—and embracing a culture of continual learning—are also keys to adaptability.

Being adaptable is really about understanding the landscape, the possible scenarios, the risks, and the opportunities always present in any situation. It's about being agile enough to react, respond, and make a decision even if you don't have all the information you think you "need" in order to decide. Being ready to react to situations is better than having a plan that will fail you in the wrong situation.

One of the biggest challenges I face when working with others not "fluent in open" is that they're typically not change ready.

One of the biggest challenges I face when working with others not "fluent in open" is that they're typically not change ready. To combat this, I introduce the idea of rapid prototyping and releasing early and often. This helps prepare people for change, so if you need to pivot, they are more likely to be onboard with the change of direction.

Collaboration

I know for a fact that I'm not the smartest person in the room, which is why one of my favorite aspects of working in an open organization is working with others outside of my core team to collaborate and discover better solutions. I enjoy this even more so when I get to work with people in other companies and organizations.

Here's an example: I was working with a small team of people to help plan the first ever Open Organization Week at Red Hat—an entire week dedicated to celebrating the ideas, values, and evolution of The Open Organization over the years. I had a fantastic opportunity to work with other leaders in the organization including internal communications, the office of the CEO, marketing, and others.

As the planning matured and we got closer to the event, the planning team continued to grow. We brought in others to help. The team was diverse with people, gender, tenure, and ideas. We were naturally collaborative, but team members also would shoot down bad ideas or be realistic about resources and other constraints. I really enjoyed working and learning with these leaders in our organization to determine the best outcome for this particular project. (Spoiler alert: It was a huge success.)

Here's another example: Outside of my day job, I get to collaborate with some amazing people in the civic tech space. One of my passions is to help plan an event series that focuses on the intersection of open data, open government, and citizen involvement. In helping to lead this effort, I get a change to teach people how we can successfully plan an event using an open source approach. Once it clicks with people, the results are very powerful. How we work together—how we collaborate—becomes efficient and fun.

Community

The idea of community is to value participation from people who share a common goal and vision. This cannot be understated. As a seasoned community manager, I've realized community is all about people. Having engaged community members speaks volumes when you're trying to accomplish a common mission.

The idea of community is to value participation from people who share a common goal and vision. This cannot be understated.

For example, I've been building an Opensource.com DevOps Team since November of 2017. Interest in being involved in this community is strong, but converting that interest into outcomes isn't as easy as it seems. It's my job to nurture participation, reinforce desired behaviors, and reward accomplishments, such as publishing and curating articles. Community is fluid, dynamic, and very much an interaction with humans—which is why I love it so much.

But for people not familiar with the value of building a community or participating in one, it can be difficult to translate the importance and the value. I've found that getting a better understanding of people's passions can help me align their interests to a projects needs.

Conclusion

One of the most valuable tools in my quiver as I strive to be a leader in an open organization The Open Decision Framework. This framework brings together all five principles mentioned above and puts them into practice. While it highlights transparency, inclusivity, and stakeholder engagement (community), being collaborative and adaptable are key attributes to executing a project effectively.

Again, when working openly on a project, you'll spend more time up front gathering input and feedback. But once you make a decision, you can execute quickly. This is the value of working openly and inclusively: People who might disagree with the decision felt like they were consulted and should have a clear understanding of why the decision was made.

As I think about my interactions with people who don't yet have a strand of open source DNA in their work cultures, I recognize an opportunity to demonstrate a better way. An open source way. There is a huge opportunity for today's leaders to open their thinking and understand that open organizations are the future. This is why I'm trying to decode and translate openness to as many people as I can.


This article was inspired by The Power of Community webcast. It's chock full of knowledge from the open organization ambassadors. I highly recommend watching it.

What to read next

open source button on keyboard

Learn how to create a book using the Open Decision Framework.

About the author

Jason Hibbets
Jason Hibbets - Jason Hibbets is a senior community architect at Red Hat which means he is a mash-up of a community manager and project manager for Opensource.com. He primarily works with the DevOps Team and Open Organization community. He is the author of The foundation for an open source city and has been with Red Hat since 2003. Follow him on Twitter: @jhibbets for a fun and shareable feed of his open source (and other)...