Month: April 2012

Mozilla is an amazingly global and diverse community. I like to think we got it from our open source heritage – open source projects know how to work globally.

Mozilla is committed to working globally – we hire all over the world, hold regular community meetups around the world and have community spaces in many cities.

But it’s not easy. Ensuring that a global team works effectively takes a lot of dedication by everyone.

Recently we had a Global Community Champions workshop to discuss what’s going well, how we can teach other best practices and what we want to improve on.

Amié Tyrrel organized the event. Homa Bahrami and Debbie Cohen facilitated.

There were a lot of great conversations and takeaways. We’ll be following up with lists of tips and a few specific task forces, but here are a few of the takeaways I had:

• Open source (and Mozilla) are peer-to-peer teams, as opposed to parent-child teams.
• All projects need a conductor and they need music to follow. A music sheet that says who plays what note when. When you don’t have a conductor, or you have an informal one, the music is even more important. We need to plan. 🙂
• We talk a lot about how hard it is to be geodistributed but we don’t talk much about the benefits. A geodistributed team is amazing. There are traditional reasons like hiring the best talent or having continuous time zone coverage but it’s also a huge advantage when it comes to diversity (which makes sure our products and solutions work well for even more people around the world) and growing community.
• There are different types of collaboration and different types of teams.
  • Collaboration can be pooled (we each do our part and then combine them), serial (I develop the product and then hand it off to QA), reciprocal and multidimensional.
  • Teams can be loosely coupled (like a golf team) or tightly coupled (like a soccer team.) Loosely coupled teams are much easier to coordinate in a geodistributed environment. Tightly coupled teams are likely to take a lot more time and energy. If you are on many teams, you might want to make sure you aren’t spending all your time on tightly coupled teams at the expense of your loosely coupled ones.
• Many people at Mozilla are on many, many teams.
• Mozillians are very emotionally connected to their work. (As opposed to financially or intellectually connected.) This is one of my favorite parts of working at Mozilla. However, it also means that emotions run high and when someone has diverged from the project, it’s really hard for them to say goodbye.
• Remote teammates don’t have much signaling communication (random smiles as you pass by) and tend to focus on substance conversations. It’s important to build the signaling back in some how.
• There are three times it’s important to meet in person.
  • At the beginning of a project to work out ambiguity,
  • At the end of the project to aggregate and celebrate and
  • Whenever there are conflicts.

  (I think this point will be important as we figure out when and how often to have work weeks.)

• Several people have had success with office hours. Specific times when they are available to chat.
• Conflicts in geodistributed teams are much more likely to be about relationships rather than tasks.
• Ineffective teams are likely to have:
  • fuzzy goals
  • ambiguous roles
  • ad-hoc, unclear roles
  • internal focus
  • lack of identity
• Effective teams usually have:
  • clear goals
  • differentiated roles
  • pre-determined rules for
    • how to deal with conflicts
    • how to build consensus, make decisions
  • external focus
  • shared identity
• Debbie shared how Mitchell described Mozilla’s decision process. I hope Debbie or Mitchell will share with us in a blog post but basically it was you write an email describing the problem set, the issue you see. You make a recommendation. Ask for specific feedback, allow some time for discussion and then take action.
• The team leader or orchestrator does not need to run the meetings. Several teams (like the Automation & Tools team) are rotating the facilitator for their regular meetings. This lets everyone play an active role in the project. I believe the facilitator touches base with everyone on the team, gets their status updates and issues. Sets the agenda, runs the meeting and sends out the notes afterwards.
• Effective geo-distributed team leaders know when to be:
  • colleague
  • context provider
  • orchestrator
  • director
• We need more team charters. 🙂

And that’s only part of what we discussed! Lots and lots of good info that Amie and Debbie will helping us get out to the rest of the organization in a way that’s hopefully useful. And in a way that starts a dialogue so others can also share their best practices and working globally knowledge.