When a community movement is worldwide spread, like Google Developers Group is, maintain a good balance between a common identity and local differences is essential keep the “sense of belonging” among the chapter leads, while leaving them the freedom to be successful interpreting the local context. But what defines that common identity? I created a GDG Community Canvas to explore and understand that.

The Community Canvas by Fabian Pfortmüller is, for a community, what the Business Model Canvas is for a company. While the latter is a visual chart with elements describing a firm’s or product’s value proposition, infrastructure, customers, and finances (Wikipedia), the former is a framework to describe the underlying structure of a community, focussed on 3 main section: Identity, Experience and Structure. More info in the Community Canvas site, alongside with very useful guidebooks to understand each section and questions to drive its creation.

The process

Similar to the Community Commitment Curve exercise, I’ve asked to 70+ GDG leads to create their own Community Canvas, to check if a common picture about what a GDG is would have emerged and, if yes, what it would have been. In short: yes, there is one, and it’s very well defined!

We did the exercise during the annual community summits and, because defining the whole canvas could be overwhelming, we used a short version of it, called the Community Canvas MVC (Minimum Viable Community), still by Fabian, and working only on the “Identity” part, the most useful to provide an answer to my assumption.

The benefits of running such exercise in person with the community leads were multiple: first, it was an introspective journey they took, together, to better understand the reasons they do what they do. Gather around the same table younger and more experienced leads, to share and reflect about one passion that connected them all (they were there because they all run a GDG), fostered a stronger Sense of Community. Finally, it wasn’t Google telling them what a GDGs should be, they told each other, and based on their experiences.

We used simple design thinking techniques to co-create the GDG Community Canvas: first, we invited the leads to reflect about one of the element of the identity section, individually. Then, in group of four, they shared their learnings and discussed. Finally, they wrote down the main points on a template I provided them, to group all the thoughts emerged. We iterated for each of the identity section element: purpose, audience, values, goals. Finally, I went thru the findings, doing a little bit of summarizing. The whole exercise, in total, took a couple of hours.

The result

The follow maps describe what a Google Developer Group should be, and I pretty much agree with it.

Purpose: GDGs exist because they are local platforms for peer-to-peer sharing and learning of tech knowledge, expertise and ideas, for everyone and without discrimination. They create a space to socialise and get together with likeminded people interested in tech, enabling personal and career growth. They also aim to increase diversity in tech, creating a welcoming and safe environment. All with fun.

Audience: GDGs are for tech professionals with different level of expertise, interested in learning and sharing about Google technologies, and in giving back to the community. They’re also open to students, tech entrepreneurs and, in general, to all the people working with developers and / or with a technical background or passion about technologies. They host audiences of different ages and people close in terms of geographic location. They also welcome people interested in diversity and inclusion topics in the tech ecosystem.

Values: the most recurring values of GDG communities are about a social, technological and cultural inclusiveness, a continuous learning attitude of the members paired with a love for new technologies and a culture of sharing, a desire for personal growth, all enclosed in mutual respect and support. Diversity is present in many dimensions, from members background to knowledge level, including reasons to be part of the community to technologies, all to create a psychologically safe environment for everyone.
I particularly liked one of the point made: “learn, earn, serve”.

Goals: most common success factors for GDGs are the positive feedback from satisfied community members about the activity organized, the ability to share in an efficient and effective way knowledge and positive values of the community, being recognized as a valuable community and the reference point for Google technologies in the local ecosystem. Also the “creation factor” was mentioned: in term of new projects and ideas, community contribution to technologies: bugs, pull requests, feedback, etc. Success is also defined by more diversity in the event attendees, in term of gender and cultural background.
One group mentioned the increase of Community ROI, seen as Return of Interest, in term of more attendees to the events, more retention among attendees and more bonding capital among members.

Here the detailed results.

Next steps

It would be great to run the GDG Community Canvas exercise across different cultures, as my cohort was mostly from Europe. I suspect main points will be the same, with some interesting secondary differences. In addition, I left to the leads the pleasure of filling the other two sections (Experience and Structure) once home, with the rest of their community core groups, but it would have been interesting to go thru the whole canvas together. Nevertheless, several told me they’ve done, and it was very useful to better shape and share their idea of community and align their minds.

And you, GDG member or lead reading this article, do you find yourself and your community in this canvas? Please let me know, as I’m interested in every single feedback!