When considering the governance and running of organization such as Mozilla (which we should be doing in the run up to, and during, the Summit), it’s good to think about the relationship between authority and accountability.
Having authority usually requires being accountable. And you can’t make people accountable for something unless they have the authority to affect it. The two go hand in hand.
So: how does Mozilla at the moment (and how should Mozilla in the future) bestow authority on people and hold them accountable? The answer to this question should be the heart of Mozilla’s governance structure.
Mozilla currently de jure (as a matter of law/rules) bestows project authority on people by making them module owners (or by the module owners making them peers). But we also de facto (in practice) bestow project authority on people by hiring them into MoCo (or MoFo), signing a contract, telling them to do a job that advances the project, and holding them accountable. They are accountable because if they stopped doing the job, we would stop paying them and hire someone else. Because of the link between accountability and authority, the fact that they are being held accountable means that they acquire a form of authority. This is sometimes represented by the ability to direct the actions of others within MoCo, but in any case, one can always direct one’s own actions. And other employees, at least, will recognise their role and will support them in carrying out that responsibility.
Historically, Mozilla has said that being hired should make no difference to your position or level of trust within the project. I have been a strong proponent of this view, and we sometimes puts employees to reasonable levels of inconvenience in order to maintain it as a principle. For example, we made a newly-hired release manager wait to join the security-group mailing list, so it did not appear as if he were being given that access as a direct result of being hired, without any community track record.
If Mozilla consisted solely of a community, and people hired out of that community (in order that they could spend additional time working on Mozilla), that system would be entirely suitable. But I now think it starts to break down as soon as you hire people who are not already community members. If those people are hired to direct your engineering, the breakdown is pretty serious. And we have many people hired into roles like that.
Consider: if Mozilla is investing a significant amount of money in an employee (in salary and benefits) then it would make no sense for them not to rapidly become responsible for stuff – to be in some sort of authority, and in turn be held accountable. If this were not true, what would we be paying them for?
At the moment, someone hired by Mozilla from outside the community has authority and accountability within MoCo from day one, but outside MoCo, among volunteers, they have neither. This means that there is tension. How we best resolve that tension is part of the answer to the question initially posed.
At the moment, the tension is too often resolved by that person not seeking to obtain relevant positions of project authority (which may not even exist, because the module ownership system only covers part of Mozilla’s activities), but simply getting on with their assigned task. This results in the marginalization of the Mozilla governance structure as not relevant to many people’s day-to-day activities, and it means the actual working authority structure of the project is undocumented (at least, outside MoCo – the org chart is, unfortunately, confidential) and opaque.
Would it be better to instead accept the logic that we only pay someone when we want them to do something useful, and that therefore sometimes it would be reasonable for someone to acquire some project authority as a direct consequence of being hired by MoCo – which is, after all, the organization we’ve created to hire people to work on the project? Would this, perhaps, actually reduce the divide between volunteers and employees because they would, much more often, both be working within the same, clear, public governance structure?
There are, of course, risks to this approach. Someone might feel that their role has been usurped by a newly-hired person. But I’m not sure these risks are significantly greater than the risk of upset if you hire out of an existing community, and person A gets chosen to become full time over person B, and then ends up, in that additional time, doing some of what person B did.
A possible corollary of the above is the further acceptance that there are some roles which are sufficiently important and time-intensive that Mozilla the organization is not comfortable entrusting them to someone who is not able to give their full time to them. (And that basically, today, means being hired by MoCo or MoFo.) The roles of which this is true will change over time; after all, for the first part of MoFo’s life, there was no MoCo and we had a Chief Lizard Wrangler who had a day job! But I think that, given how big Mozilla is, we have many such roles today. In other words, does it make sense to accept and work with the fact that that some roles within the project will end up being employee-only – not because of a cabal or a glass ceiling, but because of the nature and expectations surrounding the role?
As part of designing a system for running the Mozilla we have in 2013, we need to have a conversation about how we think about employment, and how it relates to authority and accountability, and what consequences that has. This is a start; please contribute.