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.

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?”

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.

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.

Categories: Mozilla, Thought Process

16 comments for “Pilot Working Group on Decision-Making”

1
Andre said on March 28th, 2016 at 10:11 pm:

I consider decision making as an overrated task in most organizations but each decision actually has an audience that requests a decision. Even more so decisions may manifest without decision taking. A lot of decisions at Mozilla are taken in either an implicit way or by routines. Cultural expectations may differ across country and work culture, there is no universal code.

A perfect servant does not bother you with decisions to be taken, he does what you expect from him.
2
jim stinson said on March 29th, 2016 at 12:27 am:

Not to change the subject…I just tried to register to vote using firefox…failed 5 time…switched to chrome…. made me research who firefox is… curious what your politics are? Ooops sorry to interrupt the conversation. Just I am obviously not tech savey.
Thanks
Jim
3
jim stinson said on March 29th, 2016 at 2:35 am:

Check out Nebraska Sec of State registration site. ” landmine” steering….gee I really would trust that Internet voting process…
4
karl said on March 29th, 2016 at 5:21 am:

In the first point, you touched upon “This is — identify the actual decision that needs to be made.” If you could expand on this point it would be interesting. There are many types of decisions. And obviously the bigger the size of the impacted group (not the group taking the decision) is, the harder the decision is. I had my shares of struggles in both being the “consumer” (this is interesting by itself aka the word consumer as opposed to participant) of a decision and the “leader” (hmm chilling word) of a decision. Both roles are difficult at some time.

To rebound on the “Decision-Making is hard at Mozilla.”, my impression is slightly different, it is not that it is hard—Consensus takes time and it’s ok. It’s part of the community process. It’s in this time and slow friction that we create culture.—so… not hard, more unsettling at time. Not understanding why a decision was made, its history documented, etc. Some decisions seems to be dropped upon a group without all the rationales which have been into play during a certain time.

At the same time, as a group participant (if we want to avoid the leader term), it’s sometimes difficult to not have a clear set of rules to guide in the decision process. The rules are here as a toolbox for documenting, communicating, defining the edges, etc in the discussion and thought process, basically to grease where things can become emotional because of culture, history, preferences background. They help to re-calibrate the passion in a more participatory tone.

Are your progress on this working group documented somewhere? It seems super interesting.
5
Tony said on March 30th, 2016 at 12:52 pm:

I would like to highlight a few basic project management skills that can help address some of the points in the blog.

Firstly, there is the frequent uncertainty about who is the actual decision-maker. It can be helpful to think of the various parties as “stakeholders”, where a stakeholder is any single person, or group, which is in some way affected by the decision being taken. When considered in this way, it is possible to identify all affteded parties, their respective motivations and opinions; and to then understand the impact on them from the decision. As stated, Stakeholders are in some way impacted by a project or a decision (hence they need to be consulted), but they are not ultimately decision-makers.

One special stakeholder is the decision maker or Project Sponsor , usually the person with designated responsibility and budget control – Division head, department head etc.

Putting the above in to context, a project manager’s role typically requires them run a project whose purpose is to deliver a set of specific objectives or outcomes. The objectives need to be defined at the outset, and agreed with the project sponsor / decision maker. The objectives can evolve during the execution of the project, but are always written down (generally in a documnet known as the “Project Charter”). By defining the objectives clearly and concisely in the Project Charter, the decision process is simplified greatly. The Project Charter provides the framework for decision making.

In my experience, it is essential to define (in writing) the project’s objectives and to identify / consult the stakeholders. Without doing these two important tasks, we arrive at the situation of not knowing who the decision maker is, and for each party to have their own interpretation of the obejctives of the task/project. This is an all-too-frequent occurance, not only in Mozilla but in other organisations too.

Referring to point 1. in the blog….”Item 0…….This is — identify the actual decision that needs to be made”. The even more fundamental point is to clearly define (stress again – in writing) what the objective(s) are. Decisions can then be taken in the context of the pre-defined objectives.

In the Decison-making diagram above, there is a missing step (let’s call it Step 1A) which is to identify the Stakeholders.
6
Michael Saunby said on March 30th, 2016 at 2:40 pm:

From experience elsewhere I’d say that –

Hierarchies lead to decision making bottlenecks with long delays for approval.

A common response is self vetting of ideas, so only those with high chance of approval get passed up the chain. The end result is leadership nearly always approve the decisions presented to them and are perhaps unaware of more interesting but more risky alternatives.

Another response is to appoint panels to make decisions in particular domains. Panels will tend to be composed of specialists and without appropriate guidance the specialists will use their veto over their specialism to reduce risk. Without exposure to some risk, be it financial, reputation, or technical it’s hard for projects to bring about any real change.

I don’t have answers, just an awareness that such problems are common place, and a part of how professionals are conditioned to work in organisations.
7
Michael said on March 30th, 2016 at 2:44 pm:

Agree with karl. Virtually nobody at Mozilla I know of was aware that there was even a debate going on about pulling B2G. Not much chance of building consensus and reaching an open and informed decision if it’s made in near secrecy. Or are we only supposed to have a contribution in low level decision making?
8
Chandi Tome said on March 30th, 2016 at 4:31 pm:

Frederic Laloux in his popular leadership book “Reinventing Organizations” talks of the future of successful organizations as those that breathe human consciousness into every bit of decision made. For example, before making a decision, be sure to consult those whom the decision is intended and those whom it will affect. “These decision-making mechanisms give everyone affected by a decision a voice (the appropriate voice, not an equal voice), but not the power to block progress.”
9
Trevor said on March 30th, 2016 at 6:38 pm:

I tend to think most decisions should be made by getting a consensus that some thing is the right thing to do. So yeah that can take a while, but I’m not sure I would say its exactly hard. Well ok it can be if people don’t agree, but then maybe the right answer is to not decide that.
10
Mitchell Baker said on March 31st, 2016 at 3:37 pm:

Andre, i see your point if one is looking for servants. We’re looking for something different here, so the needs and approach is different. We’re looking for individuals who are using all their skills and dreams and expertise to be leaders in moving our mission forward.
11
Mitchell Baker said on March 31st, 2016 at 3:41 pm:

Karl

Yes, we need some clearer guidelines for a decision to be legitimate and to feel legitimate. And to get to this point with as little churn and unneded difficulty as possible. On the consensus side, the consensus I’m interested in is that a correct process was followed and the decision has legitimacy. I’m not thinking that the actual decision-making is by consensus. Our idealized model has always been an identified decision maker. And I have learned that one of the key roles of a leader is to be able to figure out wha to do where there is *not* consensus, and still provide inspiration and cohesion.
12
Mitchell Baker said on March 31st, 2016 at 11:51 pm:

Karl

re your question about “identify the actual decision” I’ll give one example here. I was working with someone who had the question “what’s the most cost efficient way to do Activity X?” And the most cost efficient way was to do less of Activity X. That seems pretty obvious. But there was no way to make a decision about cost efficiency without first figuring how the set of Stakeholders as Tony mentioned for Activity X, and then the value of Activity X for the Stakeholders. Cost decisions couldn’t be made without understanding the underlying value Activity X decided.

That’s pretty obvious when described this way. But not always so obvious when one is responsible for a decision that’sbeen formed and socialized in a particular way.
13
Mitchell Baker said on March 31st, 2016 at 11:55 pm:

Chandi

Yes, exactly. There’s something about dealing with press-worthy topics at scale in a setting of ambiguity that makes it easy to lose sight of basic grace and relationships with individuals. Actually I think this is one of the big problems with large organizations — humans beings as a species aren’t nearly as decent at large scale as we are when we have individual relationships and accountability with people.

That’s a bigger question than Mozilla. We’re actually not that large an organization so we should be able to make progress here.
14
Rami said on April 1st, 2016 at 7:14 am:

Mitchell,
From my experience with organization similar to Mozilla (Non-Profit and diverse), decisions making are structured to let everybody participate in way or another on a micro and macro level.
I will give an example.
Decision Bodies are:
Headquarter: The main body of the organization who run the business and the vision of it.

Member states: The members of the organizations where they help to decide the priorities and headlines for the coming year (based on the vision) for the organization, they meet once or twice a year.

Executive council: It is regional representation of the member states, they meet each quarter to oversee and decide correction of actions for the running projects. The members rotate based on different factors such as type of the projects.

Delegates: Each member states has their delegates – contact/focal points – where they can reach to the organization anytime to convey their issues, to give feedback about a project or to have insight about the impact of a decision on their area.

Decisions are made based on this structure using voting system in each layer, a quick example, headquarter decided to go and do X Action, inside the HQ there is a mechanism. The head is the director, once the decision is made in on this level, it is communicated to all delegates to get a feedback about it. Then it is pushed to the council to further study it and to take a decision about it. If the decision has a big impact, the council can decide to push this decision further to all member states in order to approve it and move forward.

Of course after the decision is made, the different layers start their second roles which is monitoring the impact and executing the decision from bottom-up and report that again to the member states.

The other level for decision making is micro level by creating a Project based structure.

Each project consists of the following:
An owner of a project who is most affected with the project and has the ultimate power in a dispute. In addition, the owner is the chair of the project panel.
A Project manager reports to the project panel.
A Project Panel consists of representative from Users, “Supplier”, Departments representatives that affected by such project.
Project executors who actually run the project.
Project manager always report to the project panel for the status of the project and they can recommend a course of actions or approve/disapprove actions.
Project owner report back to the HQ, then macro level decision making process is invoked.
This is just a brief description how decision making happen in my world, I hope this will be helpful and sorry for the long post 🙂
15
André Jaenisch said on April 1st, 2016 at 10:08 pm:

Hello, Mitchell,

I was poking around some ideas with fellow Mozillians the last days and want to share them here as well. Note, that I’m only ~2 years in the web development community (Went to school + university before).

It turns around the term “mainstream”.
What is that? I mean, caught in one’s bubble it is hard to imagine that the vast majority don’t share your mindset. Be it Net Neutrality, Free Software, aesthetics or whatever. Can we measure it, so we can base our decisions on data? How many people are needed to form a “mainstream”? (Absolutely or in percent).

This yields the question whom to ask (in terms of surveys). And how to ask, since one can distort the results with manipulative questions (I assume, you have experience enough to net fell into this trap).

For me, I cannot imagine IoT going through the roof (sorry). I expect at least one data leak scandal with a loss in trust in technology as result. On the other hand, Mozilla is a trustworthy brand (IMHO) and it saddens me deeply to see its impact decrease.

So the question comes down to where to spend Mozilla’s limited resources best.

I adore the noble goal to bring people online and hence was excited about Firefox OS on smartphones (and became one of the first buyers with the launch in Germany). It was an affordable phone from a brand I trust in.
Moreover people in Africa and South East Asia could get online for the very first time! Android software wasn’t optimised to run on such limited hardware, so Firefox OS had a good stance here.
Connecting people can be only the first step, though. It’s important to teach users how the web works and how to produce content on their own (“prosumer”). So I’m looking closely at Mozilla Learning Network (and translated educational content into German).

To sum up, I expect the Mozilla staffers to fed their decisions with data and show them. Something like “We know, this decision is unpopular, but look at these charts! The impact in X is decreasing, but Y looks promising so we should look after being able to play a role in there.” (like MozVR). Maybe a semi-annual report of finances could help here, too. Especially comparisons over the past and annotating of important events (end of life of contract with Google search comes to my mind).

Hope it sparks some ideas in the community,

André
16
Philipp Schmidt said on April 25th, 2016 at 8:54 pm:

This is such an important topic, not just for Mozilla, but for all open projects (and beyond that all organizations really). I find the RACI model useful to support decision-making. It works at the level of projects, or decisions. Each project has a number of roles:

Responsible – Someone who is responsible for actually making it happen.
Accountable – Someone who is on the hook if it goes wrong (in more traditional organizations this is typically a more senior person, who would sign off on a decision, but it can be the same person as R in open organizations)
Consulted – People who are deeply affected by the decision need to have an opportunity for meaningful input and consultation. That doesn’t mean they get to make the final decision, or veto a decision, but their voices must be genuinely heard (and their valid concerns taken into account).
Informed – People who need to know that a decision is going to be made, and that a decision was made. Gives people who should be in C a chance to put up their hands, in case they weren’t on the radar. And makes sure the process is open.

I have found that one of the biggest problems is vague ownership / authority. If it’s not clear who has authority to make the decision, or–even worse–authority to make the decision keeps getting moved around, it undermines the people involved and the process.