Applying an Open Decision Framework

The Open Decision Framework is a tool for making collective decisions in a transparent and inclusive way. It is useful for open leaders who seek to build open organizations or communities. Build steps from the Open Decision Framework into your project plan or decision-making process.

Many organizations grapple with the challenges of fostering and maintaining an open organizational culture. To assist with this work in a practical way, the Open Organization community helped create and continues to maintain this flexible, iterative framework for applying open principles to organizational decision-making processes. It’s designed to help decision makers and leaders seek out diverse perspectives and collaborate across teams and geographic areas to facilitate better decisions. The Open Decision Framework began as a Red Hat project. Over time, it has grown to reflect the collective intelligence and ongoing research of the Open Organization project and community.

What is the Open Decision Framework?

It’s a flexible, open approach to making decisions. While it’s effective for decisions that impact the organization, using it for every decision might overcomplicate your processes. But for decisions that impact the people in the organization, community, or culture, it is particularly valuable.

The Open Decision Framework originated in 2009 within the Red Hat People team and a cross-functional focus group. It was built on research and materials from Duke University, Diana Martin, and various community resources.

The purpose was to create a method for aligning business decisions with the needs and values of the people, thereby helping to preserve our culture. This framework demonstrates best practices and offers guidance to teams and leaders on balancing transparency with confidentiality. This approach was essential both for maintaining the culture as the company grew and for onboarding new employees. There was, and still is, a long tradition of discussions in our internal communication channel, the memo-list. It’s an open mailing list discussing, well, everything. This framework aimed to guide more structured discussions when needed, to improve associate engagement and sort out the signal-to-noise ratio.

In 2012, the Project Management Office adopted the framework as part of their effort to create an open project management methodology. In 2014, it spread to IT and engineering when there was a suggested move to Google Calendar. These conversations served as a catalyst for sharing drafts with all associates and inviting their participation. Using the Open Decision Framework would support and guide those discussions and lead to a more transparent and inclusive decision. As an open source company, Red Hat naturally published the framework to the community in 2016, hoping it would be valuable for other organizations or communities.

After a period of diminished use, the community version of the framework was picked up by the Open Organization community who took ownership and maintenance responsibilities of the framework in 2024.

What is an Open Decision?

At Red Hat, we have a long-standing culture of open source principles. This includes open emails and debates, such as the internal mailing list, ‘memo-list’, mentioned earlier. This practice of sharing information to ensure transparency and gather diverse feedback directly translates into making open decisions:

Transparent. Transparency is key to building trust and ensuring informed participation. People need to be aware of existing problems and ongoing decisions, know who is responsible for making decisions, understand the requirements and constraints, and be clear on how they can contribute.

Inclusive. Inclusivity is equally important. Those impacted by decisions should have a voice in the process. Actively seeking diverse perspectives ensures more comprehensive and effective outcomes.

Customer-centric. Think of people involved or affected as customers with competing needs and priorities. When a decision benefits some but may disappoint others, focus on managing relationships and expectations while maintaining productivity.

(Uicons by Flaticon)

Open decisions are made using open source principles

We use open source principles to make open decisions. These principles include:

Open exchange: Whether you’re developing software or trying to solve a business problem, open exchange begins when you share your “source code” with others. A free exchange of ideas is critical to creating an environment where people are empowered to learn and use existing information toward creating new ideas.

Participation: When we are free to collaborate, we create. We can solve problems that no one person may be able to solve on their own. Those most impacted by the change can help influence it by identifying misconceptions, filling data gaps, and course correcting as needed.

Release early and often: As with our software development practices, we want to release early and often to get crucial feedback. Rapid prototypes can lead to rapid failures, which are valuable learning opportunities that accelerate the development of better solutions. When experimentation is encouraged, you can look at problems in new ways and look for answers in new places. You can learn by doing.

Community: Communities are formed around a common purpose. Communities bring together diverse ideas and share the work, allowing us to create beyond the capabilities of any one individual. By multiplying efforts, we can achieve more together than we could alone. As the proverb goes, “If you want to go fast, go alone. If you want to go far, go together.” Forming communities around the decision-making process builds trust in the process itself, regardless of the final outcome.

Open source principles lead to better decisions

Open source principles not only lead to better decisions but also result in better outcomes. The process also fosters buy-in for the decision. Making an open decision might take longer than a top-down approach. However, it will result in much stronger and faster adoption, making subsequent steps easier and quicker. In open source communities, when decisions are made without community agreement, we’ve seen members spin off to a new project or simply walk away.

Open decisions lead to outcomes that can be implemented, realized, and acted upon more quickly because people are already aligned. The strength of this approach lies in the evolution of the best ideas. This means you are not restricted by predetermined notions. While you might have a general direction, the openness of the process allows for innovative ideas that might not have been considered otherwise. The diverse perspectives within the group bring fresh ideas that you might not have anticipated.

Higher associate engagement helps to identify potential issues or unanticipated impacts early on, ensuring that decisions are aligned with both strategy and culture.

You can’t please everyone

But when open decisions are made, people can say:

• "I understand why the decision was made and how it aligns to our strategy, goals, and mission."
• "There was visibility to the business requirements, research, and evaluation criteria."
• "The decision-making process was inclusive and transparent."
• "Although I wasn’t the decision maker, I was able to contribute to the process."
• "I may not agree with the decision, but it’s obvious that the decision makers understand our values and culture."
• "I might be disappointed, but I wasn’t surprised."
• "My voice was heard and valued."

You will never get a perfect decision that 100% of people agree with, but everyone has a chance to feel heard. They gain an understanding of why the decision had to be made, as well as insight into the requirements, constraints, research approach, and evaluation criteria. They have the opportunity to challenge, discuss, and contribute to the decision-making process. This understanding helps people accept the decision, the next steps, and participate—even if they don’t agree with every aspect.

The four phases of the Open Decision Framework

The Open Decision Framework consists of four phases, which do not necessarily follow a linear progression. The phases may overlap or need to be revisited, depending on the decision-making process and the lessons learned along the way:

1. Concept, Define, Ideate

• Lead with transparency.
• Define a Problem Statement.
• Identify who will contribute and who will sign off.
• Build diversity of thought and an inclusive environment.

This phase involves defining the problem statement in clear, concise language to ensure we address the right problem and stay focused. Make sure to revisit the problem statement throughout the process to maintain clarity. It’s important to carefully scope the decision, as not all aspects may be open. For example, financial constraints might limit our ability to hire external resources, so we must work within the available people and resources. Constraints might also dictate viable approaches, such as regulatory requirements that mandate certain procedures. Such constraints need to be well communicated to maintain openness and avoid misunderstandings.

The next step is to identify who will contribute to the decision and who will ultimately be responsible for it. For example, the CFO might be responsible for releasing funds, or the CEO sets the strategic direction, but again, these are clearly articulated, have clear boundaries, and ensure that any rejections can be explained, maintaining transparency.

2. Plan, Research

• Gather input.
• Make it easy to participate.
• Explain the obvious and publish your research.
• Remain open to new information and perspectives.

In this phase, we conduct research, engage with the organization, and gather both qualitative and quantitative data to collect as much relevant information as possible. A key aspect of this phase is reducing barriers to participation. For example, avoid scheduling calls at times that are inconvenient for participants in different time zones.

In an open source community, challenges like language barriers must be addressed. Consider strategies to make it easier for non-native English speakers to participate and ensure their voices are heard. Also, consider different ways of communicating. While some people might find it easier to talk and discuss, others might need time to reflect and choose to respond in writing. Don’t limit participation to a single format.

Clearly define the type of feedback you are seeking, and consider peer-to-peer communication options in addition to formal channels. Plan the transition, gather feedback, and think through how you will respond to those who may be unhappy with the chosen direction.

3. Design, Develop, Test

• Build your community.
• Promote open exchange.
• Make it safe to voice concerns.
• Publish progress in an open place.

As we move from the previous phase into Design, Develop, and Test, we have formed our hypothesis and potential decisions. Now, we focus on building a community around these ideas. Ensure that people have opportunities to provide feedback through the appropriate channels, and make sure to evaluate and acknowledge it. A simple acknowledgment like “Thank you for your feedback! We really appreciate your input.” goes a long way in making people feel heard. When a suggestion isn’t feasible, explain why. If a suggestion is implemented, highlight the change and credit the person who contributed. This approach demonstrates the incremental evolution of the decision.

As an exercise, pretend it’s launch day, and people are surprised or upset. What could have triggered this reaction? Identify any changes or clarifications that could prevent this reaction, and address them proactively. Engage your ambassadors and equip the community with the tools they need to address misinformation and misunderstandings.

4. Launch, Deploy, Close

• Begin with the end in mind.
• Show how feedback shaped the decision.
• Default to open.
• Contribute upstream.

Finally, it’s time to launch. Ensure that the decision aligns with your strategy, culture, mission, and values. Clearly demonstrate how feedback influenced the decision and explain how people can continue to provide input after the launch. Acknowledge any gaps or concerns, we’re human, there are going to be gaps. There may be fears and concerns, and as we discover them, it’s important to address them openly. This might require a follow-up or even a separate Open Decision Framework (ODF) process. It’s important to acknowledge when you’re not fully satisfied with the decision, or when you know that others may not be. Stay engaged with those who disagree and continue the dialogue.

These four phases function as feedback loops rather than following a strict waterfall approach. As new information arises, we may need to revisit earlier phases to adjust our approach. We typically timebox the phases to maintain momentum and ensure progress.

Contribute!

I hope the Open Decision Framework has inspired you and opened up new possibilities. I encourage you to test it out—see what works for you and what doesn’t. Share your experiences and feedback to help the broader community understand what might need to be changed or improved. Your contributions are vital. Together, we can continue to refine and enhance the framework.

Let’s work together to make the Open Decision Framework even better!