At the end of September 2015, Mozilla Science Lab held a Leadership Summit at the Mozilla offices in Toronto, Canada. This was our first iteration of a training and networking event we’ll repeat in the coming year. We gathered about a dozen community members who’ve been jump-starting and leading open science and citizen science projects, advocating for working open in their fields and communities, and running Study Groups (regular meetings where participants teach and learn code and open source practices). We aimed to supercharge their work by providing extra training on best practices for open projects and groups— and by creating a pop-up mini-community of superstar leaders and thinkers.
The Challenge
From an instructional design perspective, this training presented a challenge: we wanted to “Teach Like Mozilla”—get learners doing something immediate, creative, and hands-on. When you’re teaching writing and remixing for the web, learners can jump in and be making and creating in minutes. But how can you “learn by doing” in a training for something as abstract and situational as “leadership?” It’s a question I’m still considering, weeks after the Summit. In the meantime, I’ve taken our first-try approach and condensed it into seven tips for workshop design:
1. Do User Research. Whenever I start working on a design problem, I begin by thinking about the end users. This is so, so, so important— you can spend countless hours designing the most brilliant training/software/product ever, totally aligned with your fabulous objectives… only to find it doesn’t meet any of your user’s real-world needs. So we drew up a list of questions (What are your goals for your project or group? What challenges do you face? What resources do you need? What skills and insights do you have to share?) and included them in the Summit RSVP form. The detailed responses we received helped us create an agenda focused on real-world needs: sessions on best practices for open projects and groups, how to work effectively with contributors, and how to grow and sustain active open science communities.
2. Build On Existing Knowledge. Why design in a vacuum? As we developed the training, I talked to as many people as possible at Mozilla and elsewhere who train teachers and leaders— there were great resources all around me. I had helpful conversations with Michelle Thorne and Chad Sansing among others, and uncovered some fantastic writing and thinking. Particularly useful were Michelle’s blog post on a Webmaker Training in Uganda, and this terrific resource on facilitation by Laura Hilliger.
3. Make it Social. Some of the best advice came from Michelle— she suggested we build in plenty of downtime for participants to hang out, talk, and make friends. It’s tempting to get right down to business and stuff every spare moment with delicious content and cool activities. But it’s easy to max people out— and those 2 hour lunches, long coffee breaks, and leisurely dinners are when people really get time to connect, share, and have brilliant conversations and big ideas. In the end, many participants said the social downtime was one the most valuable aspects of the Summit.
4. Leverage the Resources in the Room. Since we were bringing an amazing group of people together, it made sense to put their knowledge and experience front and center— rather than just talking at them for two days. We’d already ID’d areas of expertise in the user survey responses (see #1). Our sessions began with short 10-15 minute presentations from Mozilla staff on each topic (I actually framed this as “storytelling,” so we’d get at real-world situations and steer clear of ho-hum bullet points). Then participants who had expertise in that area shared their insights for about 5 minutes each (I’d given them a heads-up before the workshop so they had time to prepare). This brought a range of voices, perspectives, and solutions into the conversation that MSL staff couldn’t provide on our own.
5. Make it About Real Stuff. We wanted to avoid abstract presentations or fluffy activities (hello, trust fall?), so we designed activities that were relevant to participants’ real work. We did a jargon-busting activity to practice communicating clearly about open science; we worked and hacked on real project materials, and with the help of Emma Irwin from the MoCo Participation Team, we devised personas to get into the head space of potential community members and define pathways for them to engage with our projects and groups.
6. Build In Loops So Learning Become Active. This was another great tip from Michelle: get participants to immediately teach or apply what they’ve just learned. I’m not sure we executed it quite as well as we could have, but we did encourage participants to review and revise materials like project or study group roadmaps and documentation as part of the training, to put new info into practice right away… And we encouraged participants to pair up or work in small groups, so they were challenged to think about and problem-solve for projects other than their own.
7. Invite Feedback. We put sticky-note pads around the room, and after each session we invited comments or feedback about anything. Participants left the sticky notes on a podium that happened to be in the room. The sticky notes let people respond in a non-public, low-stakes way. We got helpful suggestions like “more bathroom breaks” and “can we get 1-on-1 project critique time?” and were able to modify and improve our agenda on the fly. After the Summit, we sent survey, asking for both 5-point Likert scale and open text responses, and adding a catch-all “anything else?” question to invite a range of feedback. These responses let us know that we did okay (yay!) and provided great suggestions for our next iteration of the summit.
Many of our workshop design tips— and more— are in our short Facilitation 101 guide. We plan to run another, revamped iteration of the training in January.
Summit Takeaways
My top three insights from the workshop:
1. Open Science Leaders ROCK. This community is full of talented, dedicated, brilliant people with a stunning range of skills and expertise, working on some very impressive, ambitious projects. Expect great things!
2. GitHub can be tricky! Many of our participants and their communities still struggle with Git and GitHub, collaboration tools that are widely used in Open Science but were devised by and for software engineers. Scientists, citizen scientists, and anyone without ninja-level coding skills may find these tools daunting. Mozilla Science Lab aims to create some very friendly GitHub 101 learning materials— stay tuned for these!
3. Best Practices Apply Across Projects. While participant’s open science projects varied widely— from an open science digital quarry at Dionsaur National Park to a crowd-sourced disaster relief initiative to an open JS library for graph theory to study groups like this one at University of Toronto— basic principles about working open applied to all. It’s about finding ways to invite in and welcome new participants; making project and group information new-comer friendly, transparent, and accessible; defining “good first bugs” or “good first sessions” so contributors have a meaningful, satisfying initial experience of pitching in. And it’s about project and group leads understanding their contributors’ motivations, interests, struggles, skills and goals (user research, again!) and designing ways to encourage and mentor them, so both the contributor AND the project can succeed.