So, You Have Your 20-Page Open Source Strategy Doc. Now What?

You’ve got a huge Open Source strategy document in hand and you’re feeling pretty good. Get cross-functional teams to align on executing that strategy and you’ve got a major success on your hands.
Just one question: How?

The answer is to set the stage for buy-in before the first meeting with those teams ever happens. You’ll meet every stakeholder and write a simple one-page charter that clearly defines your team’s responsibilities. Then you’ll introduce an iterative, outcome-based approach backed by simple-as-possible guidelines, clear communication, and an objectives and key results (OKR) structure that’s already familiar to each team.

After sharing team charters between groups,  you’ll be ready for the next crucial step in the process. You’ll bring the teams together to collaboratively develop key results (KRs) that align across teams, with each group knowing exactly what piece they own based on their individual charters.

A quick aside about perfectionism

I have to call out this common quagmire. Some organizations will spend hours perfecting every word within their new strategy document for aligning open source and business goals across departments—while skipping past the careful listening and adaptive execution it takes to make those efforts actually succeed.

My advice, as someone who has been involved in many of these docs: genuinely inspiring teams to unite around the (amazing) opportunities of Open Source is never going to happen because of a strategy doc’s page count, flawless wording, or crossing every t and dotting every i (though if a computer’s not doing that part for you…there might be bigger problems). While those 20 pages may be brilliant, what matters at the team level is understandable objectives, such as those a simple one-page charter can provide. These objectives provide the basis for creating KRs that align with the charter and that won’t cause a team to take on more responsibilities than it should own.

Start from a strong foundation

At the very beginning of the planning phase for a new Open Source strategy, there’s tremendous value in talking to every single stakeholder across the business, asking questions, and building trust and credibility out of the gate. 

For example, for one of the most recent charters I drafted, I first met with more than 30 stakeholders and asked them all the same questions about their experience with Open Source, how they currently do things, their expectations and how they would define success with the initiative. These conversations are also an opportunity to clear up misconceptions: some had the notion that we’d execute a major takeover and introduce an OSPO immediately (where in truth we envisioned taking very deliberate baby steps). It’s a lot of meetings, yes, but being able to communicate with stakeholders, win buy-in and shape charter objectives around their needs from the start provides a rock-solid foundation from which to grow.

Strategy execution

Now that you have a 20-page open source strategy doc prepared, here’s what happens at the first meeting where you need to get marketing, engineering, product and other teams on the same page: the first chunk of the meeting is taken up by people reading the document for the first time. 

What happens next could be chaos if each team pursued its own misaligned practices. However! It won’t, because you came prepared with a well-defined charter and stakeholder buy-in. I recommend writing a charter with about three top-level objectives. Then at the meeting with all the teams that must align, define the KRs each team is responsible for, ensuring that they thread together to make those top-level objectives actually happen. Focus on clarity, simplicity, and brevity. Then, meet again once a month, have every team report on progress, and make iterative adjustments that improve teams’ ability to pursue the charter’s main objectives.

To be clear, objectives must be high-level enough that each team can recognize its role in achieving them, and each team owns its separate KRs. KRs should use the same metrics already familiar to their teams—marketing metrics for marketers, engineering metrics for engineers, and so on—which leaders can easily plug into their management chains and team practices. 

While it’s always a tall task to get siloed stakeholders who aren’t often in the same room to all pull in the same direction, I’ve seen this approach bring together otherwise siloed teams and align efforts—quickly and enduringly—around open source initiatives.

Where things go awry

I’ll share some warnings on where Open Source strategy alignment initiatives can encounter hiccups. Key needs can fall through the cracks when teams that aren’t in the loop must suddenly own part of the initiative. If they weren’t brought in on the initial meeting and don’t understand the importance of their role, it’s likely worth making a special effort to get them on board and up to speed.

Operating in alignment with teams distributed across the globe is another key challenge. Building a charter that makes needs and expectations clear even across time zones, languages and cultures will pay dividends.

Open Source teams should report to Open Source people

Finally, Open Source teams must report to Open Source-focused managers who understand their goals and motivations. For example, on engineering teams with a mix of Open Source and proprietary-product-specific personnel, the product inevitably becomes the priority, with Open Source workers borrowed for product work. Without strong Open Source leadership, Open Source workers find themselves trying to prove the value of what they do, which isn’t fun.

This speaks to the larger point that within an organization: Open Source cannot thrive in a vacuum. By introducing and maintaining a charter as a living document that lets every team know their role and expectations, organizations can demonstrate the same seamless strategic collaboration that gives Open Source itself its power.

This article is part of our series on Practical Open Source (POSI) program. POSI aims to facilitate discussions about doing business with and for Open Source. The 2024 edition consists of blog posts on OpenSource.net and a panel at All Things Open in October. More details and how to pitch on the POSI 2024 page.