The Portland Coincidental Work Week is next week and we’ll be working on our plans for 2015. One of the things we want to include in our planning is Mitchell’s question about what does radical participation look like for Mozilla today?
Everyone who is interested in this question is welcome to join us next Thursday and Friday for the Participation work week. Please come with ideas you have about this question. Here is one idea I’m thinking about that feels like an important part of a radical participation plan.
Slow Down
I’ve worked at small software start-ups and I’ve worked at large volunteer-based organizations. There are many differences between the two. The speed that information reaches everyone is a major difference.
For example, I worked at a small start-up called Alphanumerica. There were a dozen of us all working together in the same small space. Here’s a picture of me in my corner (to give you an idea of how old this photo is it was taken on a digital camera that stored photos on a floppy disk.)
To make sure everyone knew about changes, you could get everyone’s attention and tell them. People could then go back to work and everyone would be on the same page. In this setting, moving fast and breaking things works.
Information doesn’t spread this quickly in a globally distributed group of tens of thousands of staff and volunteers. In this setting, if things are moving too fast then no one is on the same page and coordinating becomes very difficult.
Mozilla is not a small start-up where everyone is physically together in the same space. We need to move fast though, so how can we iterate and respond quickly and keep everyone on the same page?
Slow Down To Go Fast Later
It might seem odd, but there is truth to the idea that you can slow down now in order to go faster later. There is even research that backs this up. There’s a Harvard Business Review article on this topic worth reading—this paragraph covers the main take-aways:
In our study, higher-performing companies with strategic speed made alignment a priority. They became more open to ideas and discussion. They encouraged innovative thinking. And they allowed time to reflect and learn. By contrast, performance suffered at firms that moved fast all the time, focused too much on maximizing efficiency, stuck to tested methods, didn’t foster employee collaboration, and weren’t overly concerned about alignment
For Mozilla, would radical participation look like setting goals around alignment and open discussions? Would it be radical to look at other large volunteer-based organizations and see what they optimize for instead of using start-ups as a model?
I’m very interested to hear what people think about the value of slowing down at Mozilla as well as hearing other ideas about what radical participation looks like. Feel free to comment here, post your own blog and join us in Portland.
davidwboswell 
I can’t tell you how much I would love to slow down. For years I’ve been hearing that this industry simply moves too fast for us to go slow. Even if going “slower” (whatever that could end up meaning), results in “more” (perhaps more throughput?) down the road, how do get by in the meantime?
Ben, that’s a good question. I do think slowing down would provide a long-term benefit, but how do we address any consequences from slowing down in the short-term? I’m not sure what the answer is, but we should be having an open discussion about it.
One potential answer is that there wouldn’t be a big fallout since we’d save time by not having to clean up the mistakes that happen in a ‘move fast, break things’ model. Even if there would be real short-term consequences, I would hope that we could choose to accept a trade-off of long-term benefit for some short-term pain.
Love it.
It resonates with something that I would maybe call “the time for culture”. The excerpt says: “In our study, higher-performing companies with strategic speed made alignment a priority”. I read it as “shared values and culture”. Growing a culture in a company, a project, having the same understanding of the way we want things to evolve and how to build a process around it takes time, a lot of times.
The issue with going fast all the time is that we make mistakes but we have no time to understand these mistakes. It’s a bit like writing this comment right now. There’s a time associated with it. I have already rewritten 2 or 3 times some sentences. I have almost written about it a couple of hours ago and I thought “no, no, leave time for it so it can sink inside me, it can make more sense. That it triggers memories.”
Taking time as a group or taking time individually, yes definitely. Another hint could be also mistaking speed for efficiency.
Thanks for these thoughts, which will take more time to evolve until Portland.
Hi David, thanks for this post. This really stuck out for me: “if things are moving too fast then no one is on the same page and coordinating becomes very difficult.”
I also agree with what karl says in terms of having a shared values and culture. I’m reading a lot of comparative mythology during my personal digital hiatus (http://bit.ly/BelshawBlackOps14) and it’s interesting that even in secular societies, telling the story is extremely important for cohesion.
What’s my point? I agree. Mozilla is a global community with a mission that has products in the market to further this. That means there’s going to be times and places in the organization set up for paid contributors that means speed is of the essence. However, it shouldn’t be our default way of operating.
I’m all for slowing down if that means greater intentionality and bringing along the (growing) community as we do so.