In a start-up organization, anticipating how a decision will impact the people you work with is relatively easy. If you don’t know, you just ask them, then make adjustments accordingly. Open conversations like these are an intuitive and expected practice in most start-up environments.

Yet as an organization grows to include more and more people, sustaining that open, flexible, and inclusive culture becomes difficult. Those sorts of practices begin to fade away if you don’t deliberately work at cultivating and scaling them.

As the organization becomes bigger and more complex, closed, siloed behaviors tend to creep in and become entrenched in the organization. You see one of two reactions to this cultural change:

1. Some people accept this loss of transparency and engagement with a pragmatic shrug. They say, “Well, we’re not a startup anymore, and we can’t act like one forever.”
2. Others leave the organization and say that the culture is too “corporate” for their liking. They pack up their belongings and their talents, and they begin anew with another startup.

At Red Hat, we’ve struggled with the same issue over the years, and we’ve seen our share of both reactions. After all, our company has grown from two guys in a townhouse to nearly 10,000 associates around the world.

Fortunately, our company is strongly rooted in the open source movement, where acting openly is the norm and the expectation. When we were a startup, many of our associates came from open source communities, and many of our new hires today continue to come from open source communities. That’s created, essentially, a cultural mandate: to figure out how to sustain and scale what makes our company special, as we continue to bring in newcomers from many different backgrounds.

Understanding our own best practices

We’ve developed one effective tool for doing this: the Open Decision Framework, a collection of best practices for making decisions and leading projects at Red Hat.

The Open Decision Framework contains the collective wisdom of Red Hatters, compiled into a flexible framework that helps our decision makers and leaders seek out diverse perspectives and collaborate across teams and geos, to make better decisions.

Open source principles like transparency and collaboration are the building blocks for these principles. In true open source fashion, we’ve come to realize that many of the practices originated in or were adapted from open source projects and communities to which Red Hatters contribute.

When you apply the practices in the Open Decision Framework to decision-making and project leadership, you get better ideas and a clearer understanding of the impact of your decisions–while building trust and respect between teams. You’re able to tap into the passion and creativity of your organization–while keeping the process productive and maintaining accountability for decision-making and execution. You get faster and broader adoption of changes. And you retain much of the transparency, inclusivity, and agility that most organizations lose as they grow–while sustaining speed of execution and delivering extraordinary results.

The power of open

You can find the Open Decision Framework on GitHub, where it’s available under a Creative Commons CC-BY-SA 4.0 license. We chose to publish the framework on GitHub because it’s a place where many open source enthusiasts congregate—and is a place where anyone can download a copy, remix it, translate it into another language, make suggestions for improvements, track the changes that we make to the upstream version and others make to their own “forked” versions over time, and more.

When you apply the practices in the Open Decision Framework to decision-making and project leadership, you get better ideas and a clearer understanding of the impact of your decisions—while building trust and respect between teams.

We’re seeing project managers and leaders download, adapt, and use it in interesting ways within their own organizations and communities.

At Greenpeace International, Staff Engagement Advisor Laura Hilliger had long been an advocate for open culture and leadership practices. She remixed the Open Decision Framework and presented it to the steering committee working to overhaul the organization’s international web presence, Greenpeace.org, which reaches millions of visitors each year.

“The Open Decision Framework helped me convince them to run the project, which includes everything from user research to development to content, using open practices,” Laura said. “It presents the whys and hows of open in a practical way.”

The project’s stakeholders include the entire community of Greenpeacers (more than 4,000 staff members and tens of thousands of volunteers), the site’s visitors, and potentially anyone who is interested in seeing how Greenpeace evolves their web presence for the future.

Laura put some thought into the ways she’d need to adapt words from the framework to fit her industry and organization’s lingo. For example, while an open source company like Red Hat often uses the word “contributor” to describe members of our projects and communities, that word has a different meaning in the nonprofit world.

“The Open Decision Framework helped me define how an open method is different from the ‘regular’ Greenpeace way of working, in a short and accessible way,” Laura said.

Laura also wove a communications plan into her remixed version of framework, to help the steering committee see how it could be used within their project.

Another benefit that comes from leading an open and collaborative process is that it increases people’s engagement and interest in your work.

As Laura explained, “The excitement has been building since the green light was given, and the team is promoting open while learning how to be open. Inspiring!”

Accelerating innovation and organizational change

Meanwhile, within Red Hat, we continue to see benefits using the Open Decision Framework to identify and share our own best practices across our open organization.

Within our engineering organization, for example, Vice President of Products and Technologies Operations Katrinka McCallum leads a team whose work regularly impacts every other department and many teams within each. Not surprisingly, Katrinka’s team were contributors to–and early adopters of–the Open Decision Framework.

At the 2016 Red Hat Summit, Katrinka and Jay Ferrandini, Red Hat’s Senior Director of Worldwide DevOps, presented “Lessons learned on the DevOps front,” where they shared their experience with practicing open decision making.

A few years ago, the leader of one of the Red Hat’s engineering development teams explained that Jay’s operations team had a problem. “We come to you, asking for a banana,” the leader explained. “And your team works within a black box, and after a while, you deliver us a pickle.”

A pickle?

Katrinka explained, “We were really good at working through problems. We would spend months working on a problem, and then we’d deliver this beautiful pickle. We would deliver it with fanfare, with prideful joy that we were solving their problems.”

The development team would look at the pickle in surprise and say, “Well, that’s sort of what we wanted . . . except it’s not yellow. And we wanted something sweeter. And we can’t peel a pickle.”

Jay and Katrinka realized that they needed to make some fundamental changes to their team’s process for and mindset about working with other teams. They realized they could apply open source principles–like transparency, collaboration, open communication, and participative decision-making–to bring the development and operations teams together and deliver better solutions.

So the DevOps transformation and enablement team was born.

Jay’s team adopted a number of practices documented in the Open Decision Framework:

• transparency with internal customers and other stakeholders
• customer involvement
• gaining feedback and adapting iterative changes
• building trust and respect via collaboration

For example, the team began to make customer participation a requirement for working on a project. When a development team asks his team to solve a problem, Jay explained, “We’ll probably say ‘yes,’ but only if you give us one of your people to sit in our meetings with us.”

Now, instead of gathering requirements and vanishing into a “black box” for six months to build a solution, Jay’s team brings members of the development team into the process along with those business requirements.

“At minimum, we might need just 15 minutes a week, where our business partners are participating in our meetings and scrums,” Jay said. “But we’re finding that often, these folks have the appetite and interest to get right in there and work on the code with us. It’s a way more fun and productive environment, and people want to come work with us.”

This open, inclusive, embedded model helps the team ensure, from start to finish, that they’re solving their customers’ problems. In other words, it helps them consistently build and deliver bananas, rather than pickles.

The team started out as a service organization, essentially “a call center,” according to Jay. By practicing open decision making, the team became known as a trusted business partner.

Jay’s team also decided early on to be transparent about their own challenges and limitations–another best practice found in the Open Decision Framework. This inspired other people to raise their hands and volunteer to help the newly formed team succeed.

As Jay explained, “People came out of the woodwork with offers to help. We went from closed to completely open, and almost overnight, people saw that we were human, and they began to trust us.”

The team’s open approach has helped them became a catalyst for collaboration and improved decision-making across the larger Products and Technologies organization.

In one instance, they brought four disparate groups together, helped them let go of four different message bus technologies, and aligned everyone’s requirements onto a single, shared message bus.

“We had these teams using four different modes of communication, you could think of it as speaking in four different languages,” Katrinka said. “Once we got everyone to standardize on this one common infrastructure element, we saw all kinds of benefits. Bugs were getting fixed that had never been addressed before.”

In essence, the Products and Technologies organization moved from all speaking different languages within their teams–and employing translators when they needed these teams to work together–to speaking in a common language.

This was a much more efficient system and freed up thousands of person-days of work per year, so the teams could spend more time on higher value-add tasks.

None of this would have been possible without an open and inclusive approach to making that technology decision. As Katrinka said, “Being open and transparent is a smoother way to operate.”

The experiences of the Products and Technologies Operations team are just a few of the sources of wisdom found within the Open Decision Framework, and the team has made improvements based on other teams’ contributions to it, as well.

Katrinka said, “If we’ve learned anything from open source, it’s that even if you’re the smartest person in the room, you aren’t smarter than the whole room. Solving problems together builds lasting partnerships that allow you to solve even bigger problems together in the future.”

The Open Decision Framework offers insights on how to scale that kind of open and inclusive approach, and it’s a key component in Red Hat’s leadership development system for our open organization.

(This is the fourth article in our “Open Leadership Development” series. Don’t miss the other parts. An earlier version of this article appeared in the Open Organization Leaders Manual.)