Last weekend’s Mozilla Summit was inspiring. Here are 7 key recommendations that came out of the “Practicing Open” session David Humphrey and I facilitated in Toronto.
The goal: gather specific suggestions around how to work in the open at Mozilla.
How do we commit to open not just in terms of technology, but in terms of how we work? How do we embrace transparency, encourage innovation without permission, design for participation and agility, and empower community?
Where is that difficult? Where do we need to adapt or improve?
1) Reaffirm open as our default way to work
Working in the open was a defining part of Mozilla’s history and culture. But do we still believe in it the same way? Is it still practical?
Working in the open carries risks. The press closely follows everything Mozilla does. Sometimes individuals’ blog posts are mis-reported as official Mozilla policy. Sometimes early prototypes get treated as product releases. And we have grown exponentially, straining our traditional culture and systems.
Working open can be messy and difficult — but the message coming from Mitchell and others at the Summit was: it’s still essential to our continued success.
Here’s Mitchell in conversation before our “Practicing Open” session at the Summit:
The hidden costs of becoming a conventional organization — and following the best practices of other organizations — are huge. And maybe a silent killer. We can’t just adopt what everybody else does, where no one can say anything publicly. When we do that, we go slow, we lose agility, and we lose the personality that attracts people to Mozilla.
2) Work in our pyjamas, jeans and dress clothes
Working open is not an either/or, or an all-or-nothing. Mozilla is both an open source project and a brand that carries weight and needs protecting. The Mozillians we talked with are very aware of these dual priorities, and hungry to dig into this issue with greater nuance, complexity and specific detail.
Mitchell offered a metaphor that could help us frame this: the “working in your pyjamas vs. bluejeans vs. dress clothes” metaphor.
“When we’re not always polished, we’re taking a risk. But if we’re always in our ‘dress clothes,’ we risk our authenticity. We risk going slow. We risk losing what makes us special.” –Mitchell
There are times when Mozilla needs to present a polished, authoritative face to the world. But there are also times when we need to be more casual, and there are times when we need to be wide open, unguarded and permissionless.
You wouldn’t show up for a job interview in your pyjamas. But that doesn’t mean you spend your whole life in a business suit, either. Sometimes you hang out at home in your pjs. Sometimes you put on a pair of jeans and a t-shirt to walk to the store. And sometimes you dress up in formal businesswear.
As Mozillians, we operate in versions of these three styles every day. When we disagree about where the lines are, it’s helpful to acknowledge the need for all three spaces — and then try to get the nuance right for each. Rather than trying to straitjacket ourselves into working like a traditional organization.
3) Share updated guidelines and best practices
To put that metaphor into practice, we need more specific team-by-team guidelines.
Many of the Mozillians we talked to would like clearer social guidelines around when and how to work in the open — particularly in relation to public relations and media. Its often unclear what those protocols and best practices are. And when things go wrong, it can result in frustration or anger from colleagues.
“When you don’t know where the lines are, it costs you agility.” —Coop
Common questions and scenarios included…
- “I’ve collected a bunch of data from my research. When can I share it on my blog?”
- “I released an early prototype that’s blowing up on Hacker News! What should I do?”
- “I posted something publicly that upset some colleagues. They told me not to do it again. Now I’m unsure of what the rules are.”
These issues are complex, and a natural challenge for an organization as open as Mozilla. But “hand-slapping” or getting mad at people after the fact is not a strategy — it just leaves people feeling confused about what the best practices really are. And it can create a chilling effect that costs us agility.
4) Reinvest in mentorship
“A big part of working open at Mozilla means mentoring and being mentored.” –David Humphrey
Mozillians highlighted mentoring and being mentored as one of the most effective means to put working open into practice. Newcomers (whether staff or volunteers) need meaningful guidance around open culture, social rules, and the human element that makes Mozilla special. Documentation and wikis are no replacement for this human touch.
Sometimes we talk about this in terms of an “on-boarding process” or better manuals and documentation. But a big part of the challenge is seeing how its done. And the best way to do that is to have someone show you.
Informal mentorship has always been one of Mozilla’s strengths. But our rapid growth (how do you provide mentorship to 200 new Firefox OS hires?) and accelerated release cycles have put a strain on the informal mentorship practises that used to happen more often.
“The hurdle is learning the social rules…. All organizations have this — but you can’t just follow standard corporate rules at Mozilla. You are participating in a much different community.” –Maris, MDN
5) Work out specific guidelines for how we share data
Mozillians often gather various kinds of data in their daily work. How do we collect, report and share that data in the right way?
We’re not really talking about personal user data here, which of course stays under lock and key. But what about things like performance data, privacy experiments, Bugzilla contribution data, etc? This issue seems like a recurring sensitivity and was a frequently asked question.
6) Seize the risks of working open to tell our story
Occasionally things deviate from the plan. How do we respond when working in the open triggers unintended consequences or unexpected attention?
“Every time we react to a problem, we train the media. We teach them how to look at Mozilla. We can either train them to look at us as a traditional ‘software company’ — or help them see us as an open source community.” –David Eaves
Our reaction to these instances can guide how others understand and report on Mozilla. When we act like a traditional software company, it may train others to treat us like a software company.
But when we lean into the fact that Mozilla is an open source project, with a broad and diverse community, it could reaffirm the ways in which we’re different. And challenge ourselves to really tell that story. It’s harder to do — but probably worth it in the long run.
7) Work like the web we want
Open doesn’t just mean open in terms of using Bugzilla or GitHub. It’s a frame of mind for both practical market success and long-term mission success. –Mitchell
At the Summit we talked about building the web the world needs: one that’s knowable, interoperable and “ours” — a web that belongs to people, and that people are able to shape and make their own.
Those seem like great principles for building the Mozilla we want, as well: a Mozilla that is more knowable (transparent, friendly, and well-documented), interoperable (collaborating across teams, locales and projects), and ours (built by and for community).
Other organizations belong to owners and shareholders. As a non-profit with a mission, Mozilla belongs to people. To make that meaningful, it’s probably not enough to just serve the public — we have to let them in. That starts at the atomic level, with how we work each week.
Next up: Gather more specific case studies, examples and your feedback. What do you think? How can others help?
- Let’s compare notes. How do these themes compare with the discussions in Santa Clara and Brussels?
- Add a question to the “Working Open at Mozilla” FAQ
- Got a helpful link or resource? Please add it here.
- Got a thought? Get in touch with one of the Practicing Open session facilitators: @OpenMatt @humphd @ioana_cis @SakinaGroth
Matt – love that you called out the opportunity tell a bigger picture story of Mozilla when things go off the rails.
If a prototype blows up on Hacker News or a staff or community member says something on an unofficial channel that’s taken as the official Mozilla stance, it presents a golden opportunity to clarify the situation and add, “We do things a little differently here at Mozilla; we work in the open. While sometimes there are unintended consequences, overall it makes us strong, unique and nimble.”
Standing behind our community when we’re getting unintentional press due to working open:
a) builds confidence internally
b) tells a compelling story about how we value independent thinking and agility
c) indicates that we trust our community, which hopefully attracts good people who are considering joining us
I feel like David and Ben did a great job of what you’re describing here:
https://news.ycombinator.com/item?id=6501731
It’s precisely one of those “prototype mistaken for product” moments. But there they are, patiently responding to each and every comment.