Mozilla is in a time of change. For those of us deeply involved with Mozilla, we see this everywhere we turn. Projects are changing, organizational structures are changing, product direction is under constant discussion, process is changing. Even more disorienting, the changes often don’t seem to be well connected. And even within a particular group the changes are not always consistent — sometimes there is change after change in direction within the same group.
This amount of change can feel bad. For many, it’s deeply destabilizing. Nevertheless, it is required. We need to be doing this, and the degree of change will not slow down anytime soon. At least I hope not. We need massive change to build openness into the next era of the internet and online life. A working principle for us these days is that change will be a constant.
Ongoing change is the iteration process through which we test ideas, iterate, change direction (“pivot” in Silicon Valley lingo), take what works, discard what doesn’t and repeat. On the product side, this is classic Silicon Valley product and idea exploration. We are also doing the same thing with our tools, engineering processes, organizational structures and skillsets —everything from how we build our software, to our toolchain, to how volunteers and employees interact, to how we build our values into software.
This process to test, iterate, magnify what works and drop what doesn’t can feel inconsistent. If something doesn’t work well today, then tomorrow we won’t be doing it and we’ll be trying something else. The new idea you just got used to is gone and now it’s time to talk about a different idea. And next week there might be yet another focus.
This is where Mozilla is today. For example, the Firefox team is testing ideas for what keeps Firefox great today. I like their ideas today better than their ideas nine months ago, or six months ago. (They probably do too .) That doesn’t mean the previous ideas were bad. It means they are trying things, iterating, taking what they learn and trying new things.
We should expect this everywhere for a while. It’s how we design the future.
We can do a better or worse job of execution during this time of change. There is a whole genre of literature on start-up iteration, “change management,” and leadership. So here I’ll note two things I find particularly important for Mozilla.
Mozillians identify with the mission, and with the sense of more people having more ability to affect our own lives. As a result, building grass-roots and distributed understanding and engagement is extremely important and effective at Mozilla. That in turn requires a bunch of things, which we can dive into shortly. The key will be finding ways to do this that are also quick and nimble and allow rapid iteration, especially when we don’t have a consensus.
Second, change that is happening *to* me feels different than change that is happening *by* me. Given Mozilla’s goals of distributed leadership and engagement, I predict that making the change process itself inclusive and empowering is also particularly important and effective at Mozilla.
That’s more change. I’m excited about these kinds of activities; they should make life better for all of us. I’ll be working on this, with the work on decision-making as a first step.
Simultaneously I encourage each of us to think about our own adaptive capacity — how do we assess and respond to change, both internal and external? How do our teams, and how does and should Mozilla? This is a rich topic for exploration and culture development.