Archive for the “Thought Process” Category

All Change, All the Time

April 5th, 2016

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.

Pilot Working Group on Decision-Making

March 28th, 2016

Decision-Making is hard at Mozilla.  We often face inertia and ambiguity regarding who owns a decision.  It can feel as if many people can say “no” and it’s hard to figure out who can and will say “yes.”  Our focus on individuals as empowered leaders can make it hard to understand how to make a decision that is accepted as legitimate.  This impacts everything from deciding what platforms or tools to use, saying yes or no to projects, to the role of  volunteers and supporters in our work.  I hear that decision-making at Mozilla is hard regularly, and I’ve experienced it myself.

A few months back I decided to get involved directly.  I decided to develop case studies of how to make decisions well, using the decision-making model I presented during Mozilla’s Portland gathering as a guide.  The slide is below.

If you’d like to spend 20 minutes or so listening to this part of the presentation go to minute 1:35 here.


I started by recruiting Jane to do the project management and make this a more consistent project than I would do on my own.  The next step was asking a few people if they have decisions they are struggling to get made and if they would be interested in piloting this plan with me.  I started with people who know me well enough to be comfortable with give-and-take.  In other words, a few people who aren’t so intimidated by my role and can tell me things I don’t really want to hear :-).  I’ll widen the circle over time.  There is also a set of people I think of as “standing members.”  This latter group currently includes:

   — Jane Finette, for project design and management;
   — George Roter, for his participation focus;
   — Larissa Shapiro, to help build inclusion of diverse voices into our decision-making; and
   — me.

We’ve learned a few things already, even though we’re not far enough to have a case study yet.  Here’s what we’ve learned so far.

  1. The decision-making model is missing at least one key element.  It’s so key that we currently call it “Item 0.”  (We’ll probably rename it item 1 at some point.)  This is — identify the actual decision that needs to be made.  This sounds obvious.  But the actual decision may be very different than the question as first presented.  For example, in one case the initial question was something like “what’s the most cost effective way to do X?”  But in reality the decision turns out to be things like “How important is this product feature?”
  1.  We need a shared understanding of what “community” means and how we think about our volunteers and community when we make decisions.   We need a way of doing this that respects the work being done and that simultaneously allows us to decide that not every activity should be supported forever.  George Roter is our point person for this.
  1.  We decided to create something I dubbed  the “Map of the Land Mines.”  This will start as a list of questions that tend to stop forward momentum and leave us paralyzed.  Our starting list here is:

— How public should we be? When is open appropriate / when is it not?
— Are we collecting data?
— Is it important we choose open source for our tools?
— How do we think about supporters and volunteers?

Of course we’ll want more than a list.  We’ll want tools for how to approach these topics so we can all get unstuck and stay unstuck.

We’ll meet every 2 weeks or so.  Steps 3, 4 and 6 of the decision-making model are about communication, participation and documentation.  So expect to hear more, both about the process and the decisions areas we’re using to build case studies.

Comments and suggestions are welcome, either here or via other channels.

Inviting Conversation

March 28th, 2016

I feel a strong need for more conversations with people who care about the Open Internet, Mozilla and Mozilla’s mission.  I’ve noticed that my blog has become pretty “official.”  By this I mean most of the posts are more one way and don’t invite conversation the way I’d like.

I’m going to try returning to blog posts that are  more about topics in process, and see if this helps spark good conversations about what we want to see happen and the decisions we want to make going forward.

I’ll tag these posts as “thought process” to be very clear they aren’t intended as decisions or announcements.  We’ll moderate comments on these posts.  Hopefully after-the-fact if possible but if we see too much spam or flame-throwing or trolling we’ll change that plan.

Skip past the sidebar