Streamlined quarterly reporting. In a simple spreadsheet template. Details here. TL;DR: all programs will use a simple spreadsheet. With their quarterly goals, key initiatives, and content required for board slides.

Why? No more digging data out of slides, which means opening six different documents. It’ll all live in one spot. Plain text, just the facts. No need to fuss with or argue over slide templates. Plus greater visiblity into what *other* people are writing, to help guide you.

 

What’s the plan, MoFos?

The answer is here: http:mzl.la/plan

This is often too hard to do. Individuals know where there documentation is. But finding them across teams is too hard. (Where’s the most recent Branding Plan document? Where’s the Maker Party roadmap? Where are the quarterly goals we set?)

If it’s not on plan, it’s not the plan. Your Plan of Record needs to be clear, transparent and findable.

To solve for that, I’ve create a simple “Open Book” wiki. Think of it as a simple three-ring binder with tabs. Each of the tabs corresponds to a key initiative. It doesn’t replace the Mozilla wiki, or whatever tools or documents you’re already using. It just links out to them. Through a simple table of contents that make things easier to find.

You don’t have to use it or do anything new. You just have to make sure your key planning links and documentation are there.

It can also embed things like etherpads, Google Docs, spreadsheet, GitHub tickets, etc. This makes it easier to see things with fewer clicks. But the crucial point is: this is not yet another tool or wiki to update and maintain. It’s just a way of collecting stuff that already exists.

I’m excited about this because: it’s too freaking hard to find things. This means you don’t need a million bookmarks or URLs to remember. Just go here:

And click on a key initiative. It should be instinctive to find what you’re looking for. It’s a work in progress and we’ll be adding more. But this is a good first step in making our plans across teams more visible.

 

 

 

 

 

• Resolving key questions and challenges. Program reviews and quarterly planning will routinely reveal question marks or holes. (e.g., Target audience and go-to-market for the Webmaker app. Regional Co-ordinator strategy for Learning Networks team. Branding.) We need smart process for addressing these — in ways that are harmonized for Ops (our senior management team) and TPS (the people planning Heartbeats and leading the work.)

 

Smarter quarterly planning

The key aspects here are:

Standardized across all programs. This template here is what all programs will be required to fill in. We’ll do them in this spreadsheet — not presentation slides — so that:

• It’s plain text. This is about clear data and prose — not dressing stuff up.
• It’s easy to find. Alongside our other plans
• Forces each other to read each others’ goals. For more consistency and learning across teams.
• So that we can copy and paste into our board slides. The Program Review slides failed at this — lack of standardization made this impossible.

I don’t think we should semantically conflate “Program Review” with quarterly planning. We can still do quarterly gut checks on plan without doing “Program Review”  — whic has come to mean a particular cross-Mozilla process that involves peers, a slide template, an invitation list, facillitation, etc. Program Review is a potential tool for doing smart quarterly planning. But its just one piece in a larger puzzle.

“Minimum Viable Plan”

We need to simplify and standardize

Everybody plans in their own way. But the lack of a standardized planning template is holding us back. Coming out of the 2015 planning process, Program Review template, and learning from Q1, here’s the Minimum Viable Plan for MoFo. Emphasis on: minimum. Good plans include more; but what’s the essence?

Minimum Viable Plan = yearly goal, quarterly goals, key initiatives

1. Yearly goal and KPI. e.g., “250K Monthly Active Users.” or “500 cities with sustained learning activity.”  These will increasingly focus on building long-term relationships, in line with Mozilla’s organization-wide north star KPI. This is a long-term north star that we can all plan around in a stable, multi-year way.
2. Quarterly goals. No more than three. (e.g., “Launch Coral project. Launch Webmaker for Android. Grow to 100 Clubs. Train 10 Regional Co-ordinators.)
3. Your key initiatives. With a status update for each. The key initiatives are the bones or key pistons in your program’s engine. They’re the things you’re building or driving to reach your goals. Often they last more than a single year. Clearly list what they are, in simple prose, and give a quick status update on each of them.

There’s a fourth thing that’s important to call out: dependencies and cross-team collaboration. Areas where you need explicit help from other teams, access to shared resources, or have a clear dependency on something else happening first. (e.g., “Dependent on access to snippet and marketing channels. Dependendent on closing funding from Acme. Blocked on hiring a contractors. Dependent on marketing support from communcations team.”)

What’s the point of “Minimum Viable Plan?” Getting to the meat sooner.  Understanding each other faster. And lifting up out of the weeds of semantics and story to get to the substance of plan.

Key initiatives are key

Clear key initatives are at the heart of your plan. They’re the program architecture. They’re like modular pieces in the machine you’re building. Or the lungs, nervous system and muscles in your program body.

I’m increasingly of the opinion that clear key initiatives are the quickest way to cut through baloney and get to the substance of plan quickly. They unlock a lot of efficiencies.

What do we mean by key initiatives? Let’s use the Learning Products, Learning Networks and Open News teams as examples, drawing from their program reviews:

 

 

Key learnings:

• They unlock clarity. The key initiatives are the program X-Ray.  It’s too easy to get lost in rhetoric. The easiest way to see what a program is doing — what we’re spending money and time on.
• They’re modular. Open source projects use modules. Any project with a rapid pace of development develops modules.
• They mitigate risk. One key initiative can fail without scuttling the entire program.
• They make for clearer roadmapping. Each key inititiative has its own plan.
• They persist over extended periods of time. Goals and KPIs can change. But often the key initiatives represent long-term bets and investment. Building sytems and infrastructure over time, that come back in next year’s plan. (e.g., MozFest, Fellowships, Clubs, etc.)
• They’re bullshit-testers. You can tell when a program isn’t right-sized for its budget and staff when it has too many key initiatives.
• They unlock distributed leadership. Each module or key initiative can have its own leader who’s accountable and empowered to go fast.
• They pave the way for focus. MoFo runs a lot of programs. This means we often struggle to maintain focus. Zeroing in on
• They unlock shared learning and collaboration. Many programs have the same or similar key initiatives. e.g., “Fellowships” or various forms of “Training.” These can align and learn from each other.

Yes, they all overlap. Some people object to this way of thinking. They say: “but wait — don’t they all need to overlap and connect with each other?” The answer is: of course. That’s their job. If the steering assembly doesn’t connect and overlap with the chassis, you’re literally dead. The point is not to carve the world up into fiefdoms. Modules are not fiefdoms. They’re a way to mitigate risk and go faster. Carve up the modules, design the interfaces between them, and go faster.

During the recent program review presentations, it felt to me like the audience was the least interested in this. Key initatives aren’t sexy. They don’t tell an inspiring Ted Talk story. But who cares? Story can be over-rated in the planning process. These are the blueprint for the house we are building — not the brochure. People over-rotate on the story or the brochure — what’s the photo of the house look like? What’s the headline or poetry you’re using to describe it? What is the house’s theory of change? Blah blah blah. Sure that stuff is important — but: provided we agree on the program strategy (which in some cases, we probably don’t)  the program architecture is what matters most.

Managing ambition with focus

A laundry list shows you’re “busy;” fewer goals shows you’re focused.

Having fewer quarterly goals is the key to focus. If you have more than three quarterly goals, it’s just a laundry list. It means you haven’t really made tough choices or chosen something. You might make small, incremental progress on a bunch of stuff — without really achieving a significant change of state.

Having a single quarterly goal is fine

Interestingly, right now the Learning Products team has just *one* quarterly goal. Centered on *one* key initiative (mobile): Ship Webmaker for Android. (With an accompanying metric for what success means, focused on retention.) One goal is great. They didn’t struggle to come up with more. What’s wrong with having a single clear goal per quarter? Nothing. Similarly, the Learning Networks team has three clear goals: grow the number of Hives and Clubs (with targets for each,) and train REgional co-ordiantors to help drive those goals forward. They feel clear.

Don’t get me wrong: that’s a huge lift. It’s a ton of work. But it’s a ton of work focused on one thing.

That’s an exception — other programs have more active key initiatives and a broader set of goals. My point is to push back against a natural psychological and organizational bias: to try and look “busy” or “ambitious” by creating laundry lists of tasks or goals. This doesn’t work. One fully-cooked meal in your kids stomach produces immediate energy and value. It helps someone. But 20 half-baked meals produce no value at all; they don’t feed anybody. And are therefore worthless.

This is a key lesson from agile and scrum: most organizations are really good at generating backlogs of worthwhile things to do. But so what? Good ideas are cheap. What’s hard is phasing and prioritization. Pick a few of the right ones and get them done. (What makes this hard at MoFo, as with everywhere, is we have no shared visual view of the backlog. Consequently, when we agree to take on new work, we have no way to see what it’s competing with. And therefore, struggle to priroritize. But more on that another time.)