You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
index.md 18KB
index.md 18KB
title: Open Decision Framework
url: https://github.com/red-hat-people-team/open-decision-framework/blob/master/ODF-community.md#open-decision-framework
hash_url: 272e63c4d3
Community Version 1.0.4
Updated Apr 10, 2017
© 2014-2017 Red Hat and contributors | The Open Decision Framework was created by the Red Hat People team and is available under Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). Red Hat and the Shadowman logo are trademarks of Red Hat, Inc. registered in other countries. Modified versions must remove all Red Hat branding.
Notes
- 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.
Contents
Overview
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
What is an open decision?
| 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. |
Open decisions are made using open source principles
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 allowed 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. 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 are formed 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
How open source principles lead to better decisions
| 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 |
You can’t please everyone.
But when you make open decisions, people feel…
- I understand why the decision was made and how it aligns to Red Hat’s 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 Red Hat’s values and culture.
- I might be disappointed, but I wasn’t surprised.
- My voice was heard and valued.
Open Decision Framework
Phase or activity: Concept, Define, Ideate
| 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 • Engage internal customers and stakeholders early on, especially those who may disagree • Seek out diverse and underrepresented perspectives (geographies, ethnicity, departments, job levels, gender, age, etc.) • Champion collaboration and provide channels for feedback • Address risks, limitations, and potential cultural impacts, especially with historically controversial issues |
• 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 Red Hat, 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 Red Hat's culture and future decisions • Roles + responsibilities (OPT model: https://github.com/red-hat-people-team/opt-model/) • Where to publish |
Phase or activity: Plan, Research
| 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 • Be specific about what type(s) of feedback you're looking for + who is making the decision(s) • Publish decision process and project plan, with roles, dates, constraints |
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 • Develop and gather feedback on communication, change management, and adoption plans • Think through how you could respond to upset individuals (on memo-list and other channels) |
• 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 Red Hat's 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/) |
||
Phase or activity: Design, Develop, Test
| 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 • Evaluate, acknowledge, and incorporate feedback • Highlight changes made in response to feedback • If a suggestion isn't feasible, explain why • Publish progress in an open place • Provide regular updates to sponsors, customers, and stakeholders |
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 • Pretend it's launch day, and people are surprised or upset. What triggered it? • Identify changes you would make or points you might clarify in response, and make them proactively instead Activate your ambassadors • Equip the community to help you clear up misinformation and misunderstandings |
• 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 |
||
Phase or activity: Launch, Deploy, Close
| Steps you can take to be open | Questions to ask | |
| Begin with the end in mind • Demonstrate alignment with Red Hat's 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 • Publish your methods, lessons learned, communications, and decision criteria to the archive, so others can review past decisions, learn why a decision was made, and see how leaders have responded to similar issues in the past • Offer guidance to others on open decision making and choosing collaboration tools |
• 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 at Red Hat? |
Resources
- Red Hat Multiplier – quick reference sheets on collaboration, transparency, trust, meritocracy, connection
- The Open Source Way handbook – guide to creating and nurturing communities of contributors
- The Open Organization (book + online community)
- 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 can be applied to business, education, government, and more
- The Advice Process (Daniel Tenner)
Appendix
History: Where the Open Decision Framework came from
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 Rebecca Fernandez (rfernand@redhat.com)
Why the framework exists
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