You’re Not Really Looking For An Extrovert For That Position

After I left Mozilla earlier this year, I took a break from blogging. I’ve gotten back into writing recently and am ready to be blogging more regularly. This first new post is going back to earlier this summer and linking to an article I wrote on LinkedIn.

I’ve been reading many job descriptions for community roles recently and wrote a post called You’re Not Really Looking For An Extrovert For That Position about that experience. I’ve seen several descriptions that explicitly ask for extroverts to apply, but there are many talents associated with introversion that often get overlooked that are needed for someone to be a great community manager.

I enjoyed using an old All Is Well cartoon for an image in the article. When I was going back through things I saw several other cartoons that would be good images to use for other articles about community topics. The next one I think I’ll use is the giant chicken cartoon for an article about community metrics—an obvious fit, right?

Becoming a Mozilla volunteer again

I got involved with Mozilla as a volunteer in 1999 because I was excited about the idea of an open project that gave people the opportunity to contribute to a cause they believe in.

Since 2007, I have had the privilege to work here and help many other volunteers pursue their passion and get involved with Mozilla.

This Friday, the 13th, will be my last day as an employee and I will return to being a Mozilla volunteer.

I hope to stay in touch with both the staff and volunteers who I have met during my Mozilla journey. Please feel free to reach out—my contact information is on my Mozillians profile.

Radical Participation Idea: Slow Down

The Portland Coincidental Work Week is next week and we’ll be working on our plans for 2015. One of the things we want to include in our planning is Mitchell’s question about what does radical participation look like for Mozilla today?

Everyone who is interested in this question is welcome to join us next Thursday and Friday for the Participation work week. Please come with ideas you have about this question. Here is one idea I’m thinking about that feels like an important part of a radical participation plan.

Slow Down

I’ve worked at small software start-ups and I’ve worked at large volunteer-based organizations. There are many differences between the two. The speed that information reaches everyone is a major difference.

For example, I worked at a small start-up called Alphanumerica. There were a dozen of us all working together in the same small space. Here’s a picture of me in my corner (to give you an idea of how old this photo is it was taken on a digital camera that stored photos on a floppy disk.)

To make sure everyone knew about changes, you could get everyone’s attention and tell them. People could then go back to work and everyone would be on the same page. In this setting, moving fast and breaking things works.

Information doesn’t spread this quickly in a globally distributed group of tens of thousands of staff and volunteers. In this setting, if things are moving too fast then no one is on the same page and coordinating becomes very difficult.

Mozilla is not a small start-up where everyone is physically together in the same space. We need to move fast though, so how can we iterate and respond quickly and keep everyone on the same page?

Slow Down To Go Fast Later

It might seem odd, but there is truth to the idea that you can slow down now in order to go faster later. There is even research that backs this up. There’s a Harvard Business Review article on this topic worth reading—this paragraph covers the main take-aways:

In our study, higher-performing companies with strategic speed made alignment a priority. They became more open to ideas and discussion. They encouraged innovative thinking. And they allowed time to reflect and learn. By contrast, performance suffered at firms that moved fast all the time, focused too much on maximizing efficiency, stuck to tested methods, didn’t foster employee collaboration, and weren’t overly concerned about alignment

For Mozilla, would radical participation look like setting goals around alignment and open discussions? Would it be radical to look at other large volunteer-based organizations and see what they optimize for instead of using start-ups as a model?

I’m very interested to hear what people think about the value of slowing down at Mozilla as well as hearing other ideas about what radical participation looks like. Feel free to comment here, post your own blog and join us in Portland.

What does radical participation look like?

I recently got back from my first Mozilla Festival and I’ve been thinking about what I experienced there. There is too much to fit in one post, so I want to focus on the question that came up in Mitchell’s keynote: What does radical participation look like?

What was radical when Mozilla started is standard practice today (for example, Microsoft now runs open source communities). We can’t win by doing the same thing others are doing, so how can Mozilla invite people to participate in ways that no one else is able or willing to do?

I have some thoughts about this and I’m interested in hearing what other people think. To get the conversation going, I’ll share one idea about what it would look like for Mozilla to have radical participation today.

Staff as scaffolding

In most areas of Mozilla, staff are directly doing the work and volunteers are involved with those teams to differing degrees. We have good metrics for coding and we can see that volunteers are committing around 40-50% of the patches.

For a comparison with another volunteer-based organization, at the American Red Cross volunteers constitute about 90% of the workforce. The Red Cross staff are mostly supporting those volunteers rather than doing the work of responding to disasters themselves.

We should measure the percentage of tasks done by volunteers across the whole project and set goals to get it closer to the example set by the Red Cross. Some areas, like SUMO and Location Services, are close to this today. Let’s take the knowledge they’re gaining and bring it to other teams to help them scale contributions.

There will certainly be challenges doing this and it might not make sense for all teams. For instance, with the coding example above it might not be productive to have more volunteers submitting patches. This is an assumption that should be tested though.

For example, Dietrich Ayala has had great results bringing in many students to help work on long-term features on the Firefox OS roadmap. Their work is removed from the day-to-day of staff developers shipping the next release, so he avoids the Mythical Man Month problem.

Image from Ian Forrester

We could use Dietrich’s model to support large groups focused on innovating in areas that will be relevant to us 2 or 3 years out, such as looking into how we can shape an open Internet of Things. We couldn’t hire 1,000 staff to focus on an Internet of Things research effort, but we could build a community of 1,000 volunteers to do that.

Wikipedia says that there are about 1,000 employees of Microsoft Research. I’m assuming Microsoft wouldn’t be willing to close that department and replace their R&D efforts with volunteers.

So having volunteers do more of the tasks with staff focused on supporting them feels to me like one part of radical participation. What do you think? What else could we be doing to get to a point of radical participation?

Please complete and share the contributor survey

We are conducting a research project to learn about the values and motivations of Mozilla’s contributors (both volunteers and staff) and to understand how we can improve their experiences.

Part of this effort is a survey for contributors that has just been launched at:

http://www.surveygizmo.com/s3/1852460/Mozilla-Community-Survey

Please take a few minutes to fill this out and then share this link with the communities you work with. Having more people complete this will give us a more complete understanding of how we can improve the experience for all contributors.

We plan to have results from this survey and the data analysis project available by the time of the Portland work week in December.

Mozillians of the world, unite!

When i got involved with Mozilla in 1999, it was clear that something big was going on. The mozilla.org site had a distinctly “Workers of the world, unite!” feel to it. It caught my attention and made me interested to find out more.

The language on the site had the same revolutionary feel as the design. One of the pages talked about Why Mozilla Matters and it was an impassioned rallying cry for people to get involved with the audacious thing Mozilla was trying to do.

“The mozilla.org project is terribly important for the state of open-source software. […] And it’s going to be an uphill battle. […] A successful mozilla.org project could be the lever that moves a dozen previously immobile stones. […] Maximize the opportunity here or you’ll be kicking yourself for years to come.”

With some minor tweaks, these words are still true today. One change: we call the project just Mozilla now instead of mozilla.org. Our mission today is also broader than creating software, we also educate people about the web, advocate to keep the Internet open and more.

Photo of a Maker Party in India by Kaustav Das Modak

Another change is that our competition has adopted many of the tactics of working in the open that we pioneered. Google, Apple and Microsoft all have their own open source communities today. So how can we compete with companies that are bigger than us and are borrowing our playbook?

We do something radical and audicious. We build a new playbook. We become pioneers for 21st century participation. We tap into the passion, skills and expertise of people around the world better than anyone else. We build the community that will give Mozilla the long-term impact that Mitchell spoke about at the Summit.

Mozilla just launched the Open Standard site and one of the first articles posted is “Struggle For An Open Internet Grows“. This shows how the challenges of today are not the same challenges we faced 16 years ago, so we need to do new things in new ways to advance our mission.

If the open Internet is blocked or shut down in places, let’s build communities on the ground that turn it back on. If laws threaten the web, let’s make that a public conversation. If we need to innovate to be relevant in the coming Internet of Things, let’s do that.

Building the community that can do this is work we need to start on. What doesn’t serve our community any more? What do we need to do that we aren’t? What works that needs to get scaled up? Mozillians of the world, unite and help answer these questions.

Investing more in community building

I’m very excited to see the new version of Mozilla’s Get Involved page go live. Hundreds of people each week come to this page to learn about how they can volunteer. Improvements to this page will lead to more people making more of an impact on Mozilla’s projects.

This page has a long history—this page existed on www.mozilla.org when Mozilla launched in 1998 and it has been redesigned a few times before. There is something different about the effort this time though.

We’ve spent far more time researching, prototyping, designing, testing, upgrading and building than ever before. This reflects Mozilla’s focus this year of enabling communities that have impact and that goal has mobilized experts from many teams who have made the experience for new volunteers who use this page much better.

Mozilla’s investment in community in 2014 is showing up in other ways too, including a brand new contribution dashboard, a relaunched contributor newsletter, a pilot onboarding program, the first contributor research effort in three years and much more.

All of these pieces are coming together and will give us a number of options for how we can continue and increase the investment in community in 2015. Look for more thoughts soon on why that is important, what that could look like and how you could help shape it.

Learning more about the Mozilla community

We’ve learned a lot this year as we’ve been working on enabling communities that have impact. We discovered there is a high contributor churn rate, scaling the size of the community doesn’t meet the needs of all teams and there is a need to make community building more reliable and predictable.

There are still many more questions than answers right now though and there is much more to learn. A contributor audit was done in 2011 that had useful findings and recommendations, but it has now been 3 years since that research was completed. It is time to do more.

Research has provided other community-driven organizations with lessons that help them be more successful. For example, Lego has an active community and research has helped them develop a set of principles that promote successful interactions that provide value for both community members and the Lego organization.

We’ll be kicking off a new research project soon and we’d love to get your help. This will involve creating a survey to send out to Mozillians and will also dive into the contributor data we’ve started collecting. This won’t answer all the questions we have, but this will give us some insight and can provide a starting point for other research projects.

Some specific asks for helping with the survey include thinking about what questions we want to ask and thinking about the audience of people we want to reach out to. For the data analysis part, please comment here or contact me if you’re interested in helping.

Creating community contribution challenges

There is something magical about how anyone anywhere can contribute to Mozilla—people show up and help you with something you’re doing or offer you something completely new and unexpected.

The Code Rush documentary has a great example of this from the time when the Mozilla project first launched. Netscape opened it’s code to the world in the hope that people would contribute, but there was no guarantee that anyone would help.

One of the first signs they had that this was working was when Stuart Parmenter started contributing by rewriting a key part of the code and this accelerated development work by months. (This is about 27 minutes into the documentary.)

It is hard to plan and schedule around magic though. This year we’ve been building up a participation system that will help make contributions more reliable and predictable, so that teams can plan and schedule around leveraging the Mozilla community.

Pathways, tools and education are part of that system. Something else we’re trying is contribution challenges. These will identify unmet needs where scale and asynchronous activities can provide impact in the short-term and where there is strong interest within the volunteer community.

The challenges will also specify the when, where, who and how of the idea, so that we can intentionally design for participation at the beginning and have a prepared way that we’re rallying people to take action.

For next steps, leadership of the Mozilla Reps program is meeting in Berlin from September 12-14 and they’ll be working on this concept as well as on some specific challenge ideas. There will be more to share after that.

If you’re interested in helping with this and want to get involved, take a look at the contribution challenges etherpad for more background and a list of challenge ideas. Then join the community building mailing list and share your thoughts, comments and questions.

Quality over Quantity

I was in Portland last week for a work week and Michelle recommended that I try the donuts at Blue Star. The blueberry donut was really great. The inside of the bakery was interesting too—right inside the doors was a big mural that said ‘Quality over Quantity’.

That turned out to be an good summary of the work week. We were checking in on progress toward this year’s goal to grow the number of active contributors by 10x and also thinking about how we could increase the impact of our community building work next year.

One clear take-away was that community building can’t be all about growth. Some teams, like Location Service, do need large numbers of new active contributors, but many teams don’t. For instance, localization needs to develop the active contributors already in the project into core contributors that can take on a bigger role.

For me, creating a draft framework that would give us more ways to support teams and communities was the most important thing we did—in addition to taking a great team photo 🙂

Growth is part of this framework, but it includes other factors for us to look at to make sure that we’re building healthy functional and regional communities. The health measures we think we should be focusing on next year are:

• Retention (how many contributors are staying and leaving)
• Growth (how many new contributors are joining)
• Development (how many contributors are getting more deeply involved in a project)
• Sentiment (how do contributors feel about being involved)
• Capacity (how are teams increasing their ability to build communities)

Having this more nuanced approach to community building will create more value because it aligns better with the needs we’re seeing across Mozilla. The growth work we’ve done has been critical to getting us here and we should continue that along with adding more to what we offer.

There is a video that Rainer just posted that has a story Chris Hofmann told at last year’s summit about one contributor that had a huge impact on the project. This is a great example of how we should be thinking more broadly about community building.

We should be setting up participation systems that let us help teams build long-lasting relationships with contributors like Scoobidiver as well as helping teams connect with large numbers of people to focus on an issue for a short time when that is what’s needed.

Moral of this story: Eat more donuts—they help you think 🙂