Participation, permission and momentum

Don’t wait for permission. If you have an idea that excites you, a thing you want to prototype, a skill you proudly want to share, an annoying bug you want to fix, a conversation you want to convene: don’t wait for someone else to say yes. Just do it!

This is useful (and common) advice for pretty much any endeavor. But, for Mozilla and Mozillians, it’s critical. Especially right now.

IMG_20150215_131326~2

We’ve committed to building a more radical approach to participation over the next three years. And, more specifically, we ultimately want to get to a place where we have more Mozilla activities happening than the centralized parts of the org can track, let alone control.

How do we do this? One big step is reinvigorating Mozilla’s overall architecture of participation: the ways we help people connect, collaborate and get shit done. This is both important and urgent. However, as we work on this, there is something even more urgent: keeping up the momentum that comes from simply taking action and building great stuff. We need to maintain momentum and reinvigorate our architecture of participation in tandem in order to succeed. And I worry a little that recent discussions of participation have focused a little too heavily on the architecture part so far.

The good news: Mozillians have a deep history of having a good idea and just running with it. With the best ideas, others start to pitch in time and resources. And momentum builds.

A famous example of this is the Firefox 1.0 New York times ad in 2004. A group of volunteers and supporters had the idea of celebrating the launch of Firefox in a big way. They came up with a concept and started running with it. As a momentum built, Mozilla Foundation staff came in to help. The result was the the first high profile crowd-funded product launch in history — and a people-powered kickoff to Firefox’s dramatic rise in popularity.

This kind of thing still happens all the time today. A modest example from the last few weeks: the Mozilla Bangladesh community’s participation at BASIS. Mozilla volunteers arranged to get a booth and a four hour time slot for free at this huge local tech event, something other companies paid $10,000 to get. They then organized an ambitious program that covered everything from Firefox OS demos to contributing to SuMo to teaching web literacy to getting involved in MDN, QA and web app development — they covered a broad swatch of top priority Mozilla topics and goals. Mozilla staff helped and encouraged remotely. But this really was driven locally and from the ground up.

Separated by 10 years and operating at very different scale, these two examples have a number of things in common: the ideas and activities were independently initiated but still tied back to core Mozilla priorities; initial resources needed to get the idea moving were gathered by the people who would make it happen (i.e. initial donations or free space at a conference); staff from the central Mozilla organization came in later in the process and played a supporting role. In each case, decentralized action led to activities and outcomes that drove things forward on Mozilla’s overall goals of the time (e.g. Firefox adoption, Webmaker growth, SuMo volunteer recruitment).

This same pattern has happened thousands of times over, with bug fixes, documentation, original ideas that make it into core products and, of course, with ads and events. While there are many other ways that people participate, independent and decentralized action where people ‘just do something’ is an important and real part of how Mozilla works.

As we figure out how to move forward with our 2015+ participation plan, I want to highlight this ‘don’t wait for permission’ aspect of Mozilla. Two things seem particularly important to focus on right now:

First: strengthening decentralized leadership at Mozilla. For me, this is critical if we’re serious about radical participation. It’s so core to who we are and how we win. To make progress here, we need to admit that we’re not as good at decentralized leadership today as we want or need to be. And then we need to have an an honest discussion about the goals that Mozilla has in the current era and how to build up decentralized leadership in a way helps move those goals forward. This is a key piece of ‘reinvigorating Mozilla’s architecture of participation’.

A second, and more urgent, topic: maintaining momentum across the Mozilla community. It’s critical that Mozillians continue act on their ideas and take initiative even as we work through these broader questions of participation. I’ve had a couple of conversations recently that went something like ‘it feels like we need to wait on a ‘final plan’ re: participation before going ahead with an idea we have’. I’m not sure if I was reading those conversations right or if this is a widespread feeling. If it is, we’re in deep trouble. We won’t get to more radical participation simply by bringing in new ideas from other orgs and redesigning how we work. In fact, the more important ingredient is people taking action at the grassroots — running with an idea, prototyping something, sharing a skill, fixing an annoying bug, convening a conversation. It’s this sort of action that fuels momentum both in our community and with our products.

For me, focusing on both of these themes simultaneously — keeping momentum and reinvigorating our architecture of participation — is critical. If we focus only on momentum, we may get incrementally better at participation, but we won’t have the breakthroughs we need. If we just focus on new approaches and architectures for participation, we risk stalling or losing the faith or getting distracted. However, if we can do both at once, we have the chance to unlock something really powerful over the next three years — a new era of radical participation at Mozilla.

The draft participation plan we’ve developed for the next three years is designed with this in mind. It includes a new Community Development Team to help us keep momentum, with a particular focus on supporting Mozilla community members around the world who are taking action right now. And we are setting up a Participation Task Force (we need a better name for this!) to get new ideas and systems in place that help us improve the overall architecture of participation at Mozilla. These efforts are just a few weeks old. As they build steam and people get involved, I believe they have the potential to take us where we want to go.

Of course, the teams behind our participation plan are a just a small part of the story: they are a support for staff and volunteers across Mozilla who want to get better at participation. The actual fuel of participation will come from all of us running with our ideas and taking action. This is the core point of my post: moving towards a more radical approach to participation is something each of us must play a role in. Playing that role doesn’t flow from plans or instructions from our participation support teams. It flows from rolling up our sleeves to passionately pursue good ideas with the people around us. That’s something all of us need to do right now if we believe that radical participation is an important part of Mozilla’s future.

Comments

  1. Michael Kohler replied on | Reply

    Wow, great post! I really like the way we’re going with Participation. This is exactly what we need right now.

    Regarding your point of “an annoying bug you want to fix”, I quickly have to share something here. I came across a bug in bugzilla a few days ago. I thought that it makes sense and changed the concerned string. When asking for review I got the answer “The current string was already agreed with UX.”. I know that this also has a great impact on partners, so changing strings in EN might be difficult. I fully understand this as long term contributor, but as a new contributor I might ask myself, why there is a bug open on bugzilla that actually doesn’t need to be fixed. I know that it’s difficult to keep up with every bug, but I’m sure we don’t want new contributors to fix “bugs” that actually don’t need to be fixed. This might discourage new contributors after their first contribution and they might never come back.

    I’m not sure if there is any reasonable effort to make here. There are a lot of bugs like this on bugzilla. Josh’s bugsahoy is a great resource for new contributors, but not everyone is looking at it. Further I’m not sure if having a “task force” to close bugs that don’t need to be fixed is the solution here. What do you think?

    We’ll have a German-speaking community meetup coming up next weekend and we’ll also talk about Participation. This blog post is a great resurce to share before! Thanks again for taking the time to write it!

  2. Majken replied on | Reply

    I’m sorry but I have to adamantly disagree with this for several reasons.

    1. Running with an idea on your own only works for a certain type of contributor who has a certain learning style and a certain way of working.

    2. This only seems to work because we only see the success stories. You don’t see the countless wasted hours, or tears of frustration. Some stories are held up as amazing examples of someone running with an idea and it catching on. Stories of great ideas that no one supported just don’t spread the same way.

    3. You can’t decentralize leadership by ignoring it or trying to make an end-run around it. Leadership is granted power by the organization that can’t be wrested away. Leadership needs to learn how to say yes (yes and!) when they see someone passionate with a good idea, instead of leading with reasons why it’s not a good idea right now, or why there aren’t resources to put into the idea.

    4. This contradicts the principle of participation. This is anti-participation. Permission comes in different forms, and most of the time the “permission” that people are waiting for is a commitment of support, of any kind of support. Of “yes, that is a good idea” or “yes, that messaging won’t hurt our brand” or “yes, if this idea takes off, our team can give you resources” or even simply “yes, if you get this set up, I’ll make sure to help tell everyone about it.” And certainly, if we’re going to follow the mandate to work together towards common goals we need to hear “yes, this fits in with our current goals.”

    5. If your idea or project is truly participatory in terms of working with different teams within the org, then you really can’t get anywhere without permission and buy-in from those teams.

    The idea that someone can run with their own idea, and that if it’s a good idea it should just take off is toxic to participation and decentralized leadership. It passes the buck. These projects were only successful because people did step up and say “yes.”

Add a Comment