Organizing developers and techies has often been described as trying to “herd cats.” Recently, the Drupal documentation team discovered that a professional cat herder (a Facilitator) can provide an amazing help at times when you have many difficult, high-level decisions to make.
What can you learn from their experience? The tale awaits.
The Context
The Drupal project’s documentation is not exactly known for its depth or breadth. Earlier this year, the Knight Foundation awarded funding grants for a number of Drupal sub-projects, one of which was the documentation arm.
Addison Berry, the Drupal documentation team lead, got the news about the award at Drupalcon DC. As the work had to proceed one way or another, Addison had already arranged for a documentation sprint to happen at Drupalcon, and another to follow in Toronto.
In walked Cindy McCourt with, as Berry puts it, “no laptop and a desire to help.” This was her first Drupal event and her decision to attend the documentation sprint was last minute. By the end of the sprint she found herself in the hallway with Berry and others who needed to discuss issues around the upcoming Toronto sprint.
Entering the Fray
During the hallway meeting, McCourt says, “I listened to what folks had to say and took some visual notes (on my note pad) and shared them with the group. I suppose my facilitation experience is so engrained that I just started passively facilitating.”
How did she do this? She says she learned long ago to follow the process:
- Write down what people are saying where they and the others there can see it.
- Ask for confirmation that your version is correct.
- Listen to their response, fix any misconceptions.
- Return to 1.
“When something is written down,” says McCourt, “people know they have been heard. This triggers others to be ‘heard.’ They add, expand, challenge, etc.”
She adds that the fact that the Drupal people are “fabulous” didn’t hurt either. “They are contributors by their very nature.” The common bond of their project enabled these people who had never met before to be open with each other immediately, which she calls a facilitator’s dream.
Planning the Sprint
At the end of the hallway session, McCourt wanted to discuss what she’d heard from Berry, but Berry had to attend another meeting. Another hallway participant, Emma Jane Hogbin (a specialist in online community buildings and communication through technology, not to mention a Drupal documentation contributor), jumped in to help McCourt catch up on all of the context around the discussion.
From there, the two women sat down to organize not just an agenda for the Toronto sprint, but a process the team could follow in order to reach their desired result. McCourt began by discussing what she calls “Meeting Management 101,” sharing how she typically goes about facilitating information gathering and decision making.
McCourt says that there are plenty of general tools and techniques for meeting management and facilitation. However, she firmly believes you have to choose which to use based on the group at hand, the topic, the session, the personalities, and objectives. Hogbin was able to help her better understand the objectives, needs, and people they were dealing with, and together they spent most of the day hammering out a draft plan.
Since the plan turned out to be exactly what Berry was looking for, she invited McCourt to join them at the Toronto sprint and guide them through the agenda. While Berry was purchasing plane tickets, McCourt sat down and drafted another document explaining the madness behind her methods. After Hogbin and Berry’s feedback, the document was refined for the sprint.
Starting the Sprint
When McCourt arrived at the airport, Hogbin was there to pick her up. Along the way the documentation team contributor explained the team’s culture a bit more and that, “some or most of the group might not be receptive to
an organized process.”
After considering the issue, McCourt decided to add one more activity to the agenda. They would open with an ice-breaker discussion of the Drupal community culture. This session became a brainstorming session where, “we described the nature of a volunteer community – the difference between being free and open to do what you want but at the same time, recognizing the need for structure or framework.”
There was another goal for this process as well. Part of creating technical documentation is identifying your audience, so the discussion allowed the team to take a moment and give some serious thought to the people they were writing for. McCourt comments that, also, “the discussion let everyone recognize that, even among a small group, there would be philosophical differences. I believe that an activity, such as this one at the start, helps people express their perspectives without owning them, without them being personal.”
As they discussed, McCourt took notes, and left them on the wall as a reminder of the audience they were trying to reach.
The Importance of Taking Notes
One of McCourt’s chief duties was to capture everything from the meeting. Barry says, “This was actually a big concern for us going in to the sprint. It is one thing to talk about lots of great ideas, but quite another to capture them all. When you are dealing with implementing code, if the group codes (and comments) as they go, the essence is captured already, but the more high-level you go, the harder it is to self-document.”
In particular, she adds, “Having a single note-taker made it easy for us to explore and keep up with the conversation without being distracted by writing, as well as having the notes themselves stay consistent, rather than getting a ton of disparate notes in various styles from many people. This wasn’t limited to something like detailed minutes, but also included things like jotting brainstorming up in the flip charts, rearranging sticky notes on the wall as we categorized out loud, sketching images, etc. We ended up being able to focus our full brain-power on the discussion and the ideas and then we had a nice, organized record of it all to review later.”
On the art of taking notes, McCourt says to write fast and be willing to interrupt for short clarifications, especially if you’re trying to quote correctly. She then adds, “Also, don’t try to write everything they say. Listen to the comment and if it is long, ask them to summarize in a few short words. Quite often in a brainstorming session, ideas are flowing and have not yet been condensed into a single coherent thought. Letting the group ramble a little and then asking them to summarize or convey the key point of the conversation is one way to allow for discussion while documenting only the salient points.”
And not all notes have to be taken in strictly text form. “Sometimes you get capture the moment in a diagram. You know, pictures speak louder than words. You should check out http://grove.com. I was trained by them way back in 1992 or 1993. I learned a lot and still refer to their tools and techniques.”
When All Is Said And Done
When asked if she would use a facilitator again for key sprints, Berry says, “Absolutely! I was nervous going in because I’d never done anything like it before, but the benefits are overwhelmingly apparent. I’d love to have a facilitator at most any working event now. I definitely plan to make it a regular part of the Drupal docs work, as best I can. I’d also whole-heartedly support having a facilitator outside of Drupal work. While different events may have wildly different goals and personalities, a good facilitator will be flexible enough to cater to the individual event. I think many of the attendees at our sprint walked out of there with lots of great ideas about other places they’d love to have this process.”
In particular, she’d love facilitators around for any event where things are a bit fuzzy. “Events with brainstorming, blue-sky thinking, complex relationships, undefined parameters, trying to change tack on established structures or processes; these are the places that I’d consider a facilitator essential. That said, I think I’d try my best to avail myself of any opportunity to have access to a facilitator down to even a small group trying to do basic organization.”
When it comes to facilitation and open source in general, she adds, “Open source projects tend to have additional barriers to success due to the distributed nature of the work. The over-arching policies or structures that keep things moving tend to be more fluid or diffuse than they are in, say, a corporate setting. Even a small amount of cat herding from a professional can get a diverse group moving the same direction much more quickly. It is worth the investment to save months of volunteer time wandering about.”
In particular, Berry and McCourt say that you don’t need a professional facilitator. For those who aren’t coders, helping to take notes at the meetings and act as planners and facilitators can be an invaluable contribution. Berry says, “I’d rather pay someone like Cindy twice the amount to save us more than half the time we would have spent trying to sort ourselves out in order to do something effective with code or docs.”
And for those volunteers who want a way to pitch in, finding a really helpful way to do so can give them a great feeling and make them feel a full member of the community. McCourt says, “I felt honored to be invited to meet and work with some important people in the Drupal community. You have to understand that I am a Drupal believer and have been since 2005 … I am not a coder or themer so to meet some of the key smart people who make this system possible was very exciting given I was a total stranger to them. Most people, who have a lot riding on an event, won’t just let anyone into their group, let alone someone who they don’t know and someone who will be doing something they don’t know will work.”
See “Tips on Meeting Facilitation” for more on how to try out these techniques for yourself.
