Community Version 1.0.6
Updated Aug 6, 2024
The Open Decision Framework was created by the Red Hat People team and is maintained by The Open Organization, available under Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0).
- This markdown version of the slides is intended to facilitate easier collaboration and tracking of changes.
- Page numbering corresponds to the LibreOffice (.odp) and PDF files in the repo.
page 2 of 15
What it is
- A flexible, open approach to making business decisions and leading projects
When to use it
For decisions and projects that are likely to:
- impact our culture or
- affect associates beyond your immediate team
How to use it
- Build steps from the Open Decision Framework into your project plan or decision-making process
page 3 of 15
| Transparent | Inclusive | Customer-Centric |
| Explain who is making the decision, what problems you're trying to solve, the requirements and constraints involved, and the process you will follow. | Engage others for feedback and collaborate throughout the decision-making process. Seek out diverse perspectives, including potential detractors. | Think of people as customers with competing needs and priorities. When a decision will help some customers, but disappoint others, manage relationships and expectations while getting stuff done. |
page 4 of 15
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 can learn and use existing information to develop 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. And when we can implement open standards, we enable others to participate in the future.
Release early + often
Rapid prototypes can lead to rapid failures, and that leads to better solutions faster. When you're free to experiment, you can look at problems in new ways and look for answers in new places. You can learn by doing.
Meritocracy
In a meritocracy, good ideas can come from anywhere, and the best ideas win. Everyone has access to the same information. Successful work determines which projects rise and gather support and effort from the community.
Community
Communities form around a common purpose. They bring together diverse ideas and share work. Together, a global community can create beyond the capabilities of any one individual. It multiplies effort and shares the work. Together, we can do more.
Adapted from: https://opensource.com/open-source-way
page 5 of 15
| Principles | → | Practices | → | Outcomes |
|
• Open exchange • Participation • Release early + often • Meritocracy • Community |
→ → → |
• Transparency with internal customers and other stakeholders • Customer involvement • Gain feedback and adapt iterative changes • Ideation with customers • Build trust and respect via collaboration |
→ → → |
• Customer buy-in • Stronger and faster adoption • Best ideas win • Fewer bugs, issues, and unanticipated impacts • Higher associate engagement • Decisions aligned to strategy and culture |
But when you make open decisions, people feel... page 6 of 15
- I understand why the decision was made and how it aligns with 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 clear that the decision-makers understand our values and culture.
- I might be disappointed, but I wasn't surprised.
- My voice was heard and valued.
page 7 of 15
| Steps you can take to be open | Questions to ask | Common flamewar triggers |
|
Lead with transparency • Publish a problem statement and possible approaches • Identify any aspects of the project or decision that cannot be open • Publish your ideation process Build diversity of thought + an inclusive environment |
• What is the potential impact on the organization? On the culture? • Who do we need to include in planning? • Whose problem are we trying to solve? • Who will we need or want help from? • Who else could be impacted? • Who has solved a similar problem? • Who is likely to disagree, dissent, reject, or opt out? Who else may care? |
There are a handful of issues that often generate controversy and upset within organizations, including: • Decisions, policies, or changes that impact associates, such as rewards and wellness programs • Changes to associates' work environment • Implementation of proprietary technology • Use of proprietary formats • Data privacy and sharing If your project or decision involves any of these themes, take extra steps to make your process open, inclusive, and transparent. |
| Key considerations | ||
|
• Confidentiality, privacy, and regulatory requirements • Potential to generate controversy • Impact on culture and future decisions • Roles + responsibilities (OPT model: https://github.com/red-hat-people-team/opt-model/) • Where to publish |
page 8 of 15
| Steps you can take to be open | Questions to ask | |
| Engage customers + collaborators • Gather input from internal customers and those who you will need help from (surveys, interviews, focus groups, etc.) • Make it easy to participate + manage. Ask customers which collaboration tools they prefer to use. Have a plan for consolidating and publishing feedback. • Remain open to new information and perspectives • Consider peer-to-peer feedback and communication options in addition to formal channels Set expectations upfront |
Explain the obvious • Publish the scope of the project or decision, and reiterate often • Publish decision factors and their relative importance • Publish your research, including difficult trade-offs, business requirements • To the extent possible, publish any relevant legal, reporting, or confidentiality concerns Plan the transition |
• How will we make decisions? • What internal customers, stakeholders, and collaborators will we involve? • How will we engage and communicate with them? • What are the open source options? • How might choosing a proprietary technology or format limit our choices in the future? • How does this align with the company strategy and mission? • Where might this conflict with your values and culture? |
| Key considerations | ||
|
• Impact – who, how often, and unexpected • Where and how to collaborate • Roles + responsibilities (OPT model: https://github.com/red-hat-people-team/opt-model/) |
||
page 9 of 15
| Steps you can take to be open | Questions to ask | |
| Build your community • Ask departments who from their team can provide feedback • Socialize decision with customers and stakeholders, especially those that may be more vocal about impacts • Investigate options and accommodations for negatively impacted customers Promote open exchange |
Make it safe to voice concerns • Invite project team and collaborators to raise risks and concerns you've overlooked. • Ask: What might prevent this project from succeeding? What concerns will your team have? What are we missing? • Publish risk and limitations uncovered along the way Conduct a premortem Activate your ambassadors |
• Can we pilot or release early to gather input? • How will we test? • Which internal customers can help test? • Does a cross-functional working group make sense? • Can we build a community of passion around this project or decision? • Have we engaged the people who will have to do the work? • Who do we need more buy-in or support from? |
| Key considerations | ||
|
• Representation of different types of customers • Unexpected impacts and use cases • Unspoken risks and concerns |
||
page 10 of 15
| Steps you can take to be open | Questions to ask | |
| Begin with the end in mind • Demonstrate alignment with strategy, mission, culture, and values • Outline the steps you've taken to make this decision openly • Highlight use of this framework • Tell associates where to find detailed information • Show how feedback shaped the decision or project • Explain how to provide input after launch • Acknowledge when you're not fully satisfied with the decision or know that others will not be • Share your timeline or criteria for revisiting the decision • Stay engaged with those who reject the decision |
Default to open • Reiterate relevant business requirements and constraints • Share relevant legal, reporting, or confidentiality issues • Communicate success criteria and publish relevant metrics Contribute upstream |
• How will we monitor mailing lists and other feedback channels after the launch? • If we have done early releases, will we continue to make incremental improvements based on feedback? • How willing are we to make revisions based on feedback? • What's a reasonable window of time for additional input and refinement? • Did we overlook something important? How do we address it? • Does the decision need to be revisited? • Did open decision-making lead to the desired outcomes? • How can we share our lessons learned and encourage open decision-making? |
page 12 of 15
- Red Hat Multiplier—quick reference sheets on collaboration, transparency, trust, meritocracy, connection
- The Open Source Way guidebook—a way of thinking about how people collaborate within a community to achieve common goals and interests
- The Open Organization—a community-driven project leading a global conversation about the ways open principles change how people work, manage, and lead
- Prioritizing by impact—see grid in Máirín Duffy's "5 UX Tips for Developers"
- Opensource.com—A Red Hat-supported publication focused on how open source principles apply to business, education, government, and more
- The Advice Process—by Daniel Tenner
page 14 of 15
-
Based on principles practiced by open source communities
- Research by Duke University's Fuqua School of Business and Diana Martin (2009 – 2010); additional community resources
-
Developed by the People team, with contributions from cross-functional focus group
- Grew from People team Project Management Office's effort to create an open project management methodology (2012 – 2013)
- Google Calendar memo-list conversations served as a catalyst to share drafts with all associates and invite participation (2014)
- Tested by IT and Engineering, in the Google Calendar bridge working group (2014 – 2015)
-
Updated and maintained by The Open Organization
page 15 of 15
A collection of proven practices that:
- Drive better alignment between business decisions and our company strategy, goals, culture, values, and mission
- Demonstrate "what good looks like" in decision-making and communication
- Offer consistent guidance for teams and leaders on Red Hat cultural expectations, balancing transparency and confidentiality
- Improve associate engagement, signal-to-noise ratio on memo-list