Tag Archives: open

Working open: 7 recommendations from Mozillians

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.

Jlin fully embracing the spirit of the weekend. (cc @kathrynmeisner @Mozilla) #mozsummit

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.

Moz Summit Sunday

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.

We've got you, Firefox. #mozsummit

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

Open Badges session with post-its

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.

Crazy for the Open Web

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?

“Why I love working open”

CC by br1dotcom

That’s the title of an extremely thoughtful post Eugene Eric Kim was kind enough to share with me today. It’s part of a dialogue that began after my own “How to Work Open” post a couple weeks back.

Writing about the Packard Foundation‘s experiment in sharing knowledge through an open, public wiki for the past year (they call it a “see through filing cabinet”), Kim writes:

So what has the impact been? I know that they’re constantly asking themselves that question… because they’re doing that openly as well.

I also know that, generally, one of the big hopes / expectations around doing something like this is that others will join in as well. I think this is reasonable, but I also think it’s overstated in terms of value.

Of greater value, in my opinion, is the ability to do what [the Packard Foundation] did. You want to know what we learned? You want to know what we’re thinking? Easy. Go here. Doing your knowledge work openly allows you to reuse this knowledge in useful ways — repackage it, redistribute it, refactor it, with the ongoing possibility of others joining in as well. Beautiful.

Eugene Eric Kim has helped clients like NASA, the Institute for International Education, Socialtext, and the Wikimedia Foundation.

I think that nails it. It’s a breakthrough moment I’m struggling to share with other organizations curious about working open and its real, no-b.s. value.

It’s true we work open to enable participation from others. But it’s also true that even if our goals were far more modest, even if we were simply seeking to decrease the collaboration cost, stress, overflowing inboxes, and general noise and cognitive static involved in daily work, we’d still work open. To collaborate more effectively and creatively with our co-workers across the room or down the hall. Let alone with those beyond the walls of the organization.

Or as Mark Surman put it recently: “the best internal communication is public communication.”

cc by opensourceway

Eugene also writes about some work he’s currently doing with the leadership team at a Fortune 500 company around more effective global collaboration:

Most consultancies do this sort of thing in a very closed way: Talk to a bunch of people, gather some data, then go off in a corner and think really hard by yourselves until you come up with something smart to say.

We don’t work this way. For us, participation isn’t constrained to “input” and “feedback.” It’s about learning collectively, which leads to activation. That means opening up our process, sharing our artifacts, and allowing the client to see our thought process with all of its inevitable warts and missteps.

cc by opensourceway

He hastens to add that its not automatic or magic, or as simple as flipping a switch from closed to open. Like everything, it depends on how well you do it:

It’s a tricky balance. Our client is busy. We can’t expect them to sit in on all of our meetings or to look at everything we’re looking at. So we’re strategic about designing our process to maximize the time we have with them. But, we also create opportunities for emergence by making our artifacts available and by inviting (but not requiring) participation whenever possible.

I sometimes question whether trying to work open — and encouraging others to take the leap as well — is really worth it. Whether it’s all just a nice idea that doesn’t actually work very well in reality. Or simply too difficult for traditional organizations to embrace. Do the benefits actually outweigh the effort and cost at the end of the day?

Experiences like Eugene’s give me confidence that there really is significant “there there.” And that smart people around the world are conducting similar experiments with similar results. It’s heartening, and proof positive that Mozilla’s way of working is something worth learning, evolving and sharing with others.