How to Be an Effective Manager of a Community Builders Team

(This post was originally published on CMX Hub blog, I’m adding it to my blog to keep everything in order)

A lot of community builders are working as a one (wo)man band, doing everything on their own to support their beloved communities. Far less common is the situation where you have a team of community builders working together on the same community program. As a manager of a team like this, how does one build, sustain, and grow it?

Luckily, a lot of the existing culture surrounding team management can be applied with success. I like to think about Tuckman’s stages of group development as a good starting point. It describes the inevitable phases in order for a team to grow, face up to their challenges, find solutions, and deliver results. What are specific elements and suggestions to consider, within the frame of a community builder’s team?

Phase 1: Form

In this phase, a new team is created. Its members join for the first time, start to think about the common project, and the reasons to work together. They also begin to get to know each other, both professionally and personally. There are three essential key responsibilities for the team manager: establish the vision, hire team members, and connect them.

No one more than the team manager should know the reason for such team to exist, why the company needs the community. And this reason should drive the hiring process too: there are plenty of resources on how to hire good community managers and builders, but just the right skills are not enough. It’s important to identify someone who shares the same vision and is motivated by the same whys. Initially, that vision will be a strong first element of commonality among team members. Subsequently, it will help everyone to have a clear understanding of their part in the journey. Over the long period, this alignment will provide a major boost to members’ spirit, productivity, and happiness.

Once there is a common goal among team members, another manager’s core responsibilities during the Form phase is to shift the newly formed group mindset from “me” to “us,” increasing as much as possible the many:many relationships inside the team. Think, for example, about engaging members in some type of collaborative effort, so they can motivate one another and hold one another accountable. When the shift happens, the team unleashes its real potential, obtaining results that are more than the mere sum of people’s individual contributions.

Phase 2: Storm

Once team members start to collaborate with each other, sooner or later, the vast majority of teams will go through a phase of conflicts, where the focus is on the differences among members, more than on what unites them. On failures, more than on successes. On conflicts, more than on collaborations.

To successfully deal with this stage, the manager should address areas of uncertainty and foster collaborative discussions with positive outcomes among team members, to contrast that “conflict element.”

Among those areas, two of the most important are the definition of success and the community strategy. Connected with the aforementioned team vision, identifying what success for the community looks like, and the tangible returns the community should provide, helps the group to understand how the community can serve the company, and concentrates energy and resources in one common direction

Once the definition of success is known, the manager should ensure the team creates a proper strategy to pursue it. Tools like the community strategy canvas can help to lay down a clear path to follow while leaving space, at the same time, for diverse set of contributions, added values, and creativity every team member can bring into play. The canvas should be reviewed time to time by the team, to adapt to changing factors and to tackle new challenges in pursuing success.

Another common source of conflicts in a team of community builders, is when there are divergences on the appropriate behaviors community members should have. To avoid countless discussions, the manager can help the team to find and articulate a community tone. Once decided upon, these guidelines can both reduce conflicts inside the community and, for the ones that still happen, team members can find an easier way to solve them by following the tone.

Phase 3: Norm

This phase is where team members really cooperate together, all working toward the common goal, knowing and accepting each other. Despite lot of positive elements, a good manager knows the major risk of this phase lies in the inability of the team to challenge the status quo. The community is a living organism, always changing; a team that blindly sticks to outdated models to support itself could potentially represent a problem.

Investing in member training can prevent that. Participate in conferences on community management, organize recurring lectures or brown bag sessions about books or the latest articles on the matter, encourage folks to actively participate in a community of community builders, and much more. Whatever is useful to broaden views and expertise of the team and to bring fresh new ideas, you should be doing it.

Once these new ideas are found, it’s important to provide team members a protected space to test them. Especially for mature and big communities, the fear of a small spark, generated by an error of a community builder, becoming a wildfire damaging the community with a negative impact for the company, can prevent the team from introducing changes. So, the team manager should first set a culture where small and controlled failures are not only tolerated, but there is acknowledgement they are needed to improve, and then allocate resources to perform tests in a protected environment. For example running focus groups, or creating a special group of early adopters inside the community, etc.

Bringing an external point of view can also help: someone outside of the team could easily identify areas of improvements for the community, without being “emotionally connect and involved” with the rest of the team members, and the community itself. Once spotted, the manager should work to create a plan to solve these issues, and follow up on its execution.

Phase 4: Perform

In this phase, the team performs at its peak. Autonomously, well connected with company’s goals, and with very little guidance needed. Thanks to that, the manager can collect the most substantial fruits of their labor and has more time availability. How can one reuse both of them wisely?

For example, one way would be trying to grow visibility internally into the company and to obtain more resources, in the form of a budget increase, more team members, and so on. Even if reports that show connections between the community outcomes and the company needs have to be available since the first day of the community, in this phase there is more time to increase their accuracy, deepen the analysis, extend the long-term contribution measurement. All of this should be done with one main goal: show how indispensable the community is for the company. And the team manager has to be the spokesperson of this bond, more in this phase than ever, to guarantee a bright and long-term future for their team.

Alternatively, the manager can start looking for new company challenges to address, connected either with the community-related skills team members possess, or with new needs the community can solve for the company. Has the community, initially born to provide scalable support, proven to be a good source of ideas and product feedback? What about integrating it in the creation process for new products, or new versions of them? Has the community, born to mobilize a group of people toward a cause, proven to be a source of inspiring stories and loyal customers? What about morphing it in a place for brand ambassador? Creativity is the limit.

Just a final thought to recap: every team is like a small community, and it changes over time. While the main manager’s duty always remains to connect it with the rest of the company one side, and to serve it and allow team members to thrive on the other side, knowing the most typical phases of a team can allow the manager to be more prepared, and more effective, in fulfilling their duty.

(This post was originally published on CMX Hub blog, I’m adding it to my blog to keep everything in order)

Team management practical wisdom, Codemotion Rome

Being a team manager is a big responsibility, regardless of team size. What are the best practices to make the most out of this role? Where and how management and leadership converge? How to manage difficult moments and decisions? A brief history about what I have learned, errors included, with an eye to technical teams.

Slides

(Codemotion Rome, 22 March 2019)

Team management practical wisdom, Codemotion Milan

Being a team manager is a big responsibility, regardless of team size. What are the best practices to make the most out of this role? Where and how management and leadership converge? How to manage difficult moments and decisions? A brief history about what I have learned, errors included, with an eye to technical teams.

Slides

(Codemotion Milan, 29 November 2018)

Google Developers community management culture

Working with communities, at scale, means working with a decentralized team of people in different geographies, with a similar, but diverse, professional background and expertise level. One of the few working strategies to keep all of us aligned on main goals, while fostering local ideas and adaptive strategies to better fit the local ecosystem, is to define and maintain a common team culture. Recently I was asked to present what is the Google Developers community management culture and key insights in front of our team of community builders, people like me in charge of supporting tech communities all over the world that want to share knowledge on Google technologies during their activities. Here a list of my main takeaways.

Why we do what we do and what is our role?
Dev communities help to solve the growing complexity of the technological landscape, adding a very unique social flavor. So, as community builders, we accelerate learning, cultivate culture and collaborate with communities on a shared mission and goals. We help them to be more successful because, ultimately, this helps Google dev products to be more successful. And because we love communities.

Community leaders first
We should already be used to the “User first Google’s philosophy principle. In our case, it translates to “community leaders first“. They are our primary focus, and should be treated with respect. We have to build a two-way and mutually useful relationship. All the rest follows.

Embrace goal diversity and work on the sweet spots
We have to recognize, and acknowledge, community leaders are driven by their own goals and reasons, and our company goals cannot be pushed to them. Instead, to keep this relationship prolific and sustainable in the long period, we have to base it on collaboration and independence, searching for overlaps in goals and build on these sweet spots. And we should be the first ones doing that. Sooner or later, opportunities will come.

Be a transparent and servant community builder
Community leaders know very well we don’t do this for charity. Like any trust-based relationship, it’s important to be transparent with them and communicate openly. We’re here to serve them, and not the other way around, as communities can exist without Google support, but we cannot exist without communities.

Treat them equally, as the ecosystem is our highest value asset
Some communities are more mature than others, some are quicker to execute, some able to have a bigger impact. It doesn’t matter, because what we value the most is a healthy growth and development of a vibrant community ecosystem. So they all are our beloved community leaders and we need to support all of them in the mid-long term, regardless of how they could help to reach our goals in the short team.

First save their time, then ours
In case we need to make a choice between saving our or their time, pick theirs: we’re paid to do this job, they volunteer their time. First, we need provide a coherent system maintained by a culture to interact with us, avoiding community micromanagement: in the long period, it will save a lot of time on both sides. Then, we can always optimize something: write easy-to-read, timely and useful communications, avoid asking data useful only to us, etc. Finally, if they don’t know about our initiatives, or they missed something, we assume it’s our fault.

Be data driven and restless student
Getting meaningful data out of communities is hard, but it doesn’t matter. A better knowledge of the community ecosystem helps us to make more informed decisions. We can be brave community builders, trying new things to improve our culture of community management one step at time, relentlessly, for the good of our communities and for a better collaboration with them. Every time we collect a new learning, positive or negative, we should share with each other.

Have fun
This job keeps a consistent part of our life busy: make the best out of this time, having fun while cultivating our passions.

If you’re curious about my life in Google, there are other posts to read.

How to structure useful 1:1 with your team

One of the core components of my manager toolbox is the 1to1 meeting (or 1:1, or one-on-one, or 1on1, face2face, f2f, …), a recurring appointment each team member has with me. How to structure and get the most out of it?

At the beginning, it’s important to set the reasons to spent this time together and the tone. The meeting is all about the team member: their needs, frustrations, feedback, ideas and career growth are the topics of discussion. The 1:1 is a chance for the team member to bring the problems them need help with, and a chance for me to learn more about their work. As consequence, I empower them to be the owner of the agenda and structure it around a unique, core, question: “What can your manager be helping with?

Once the objectives are clear, I set the cadency of the meeting to create an habits, generally weekly and one hour long. Unless something more urgent happens: rush hurts the quality of the conversation, so better postpone to a less busy moment, or shorten, or even make a phone call if there is something urgent to discuss and other conflicting activities.

Especially for the first times, I prefer to use a format that facilitate the discussion centered on the previous question. To make everything more collaborative and transparent, I have a shared and confidential document with every team member that we can both pre-populate, with this general structure for each meeting we have. The use of “you” is important to empower the team member, instead of a more abstract 3rd person.

  • Challenges: Leverage manager support to remove roadblocks and enhance your impact, receive coaching and guidance in areas where you have a challenge
  • Issues and Concerns: make manager aware of any personal or professional issues you have
  • Review core and project progress: an opportunity to demonstrate your impact, to share what’s going on and what’s coming up
  • Performance expectation and feedback: from the manager, to the manager
  • Career and personal development: support in developing your career, skills and knowledge
  • Misc (Out of office, lead updates, other unplanned discussions)

It’s important to constantly remember the point on career and personal development and, once in a while, it becomes the main topic of the meeting. Again, to facilitate the discussion, it can be useful to have a career worksheet template to use as base, touching these main areas:

  • Personal reflection
  • Goal setting
  • Action planning
  • End-of-quarter retrospectives

As final touch, I remember the team it’s always possible to change the structure of our 1:1 and they can schedule extra 1:1s outside of our normal schedule, as I’m here to serve.

Bonus activity for one of the 1:1: ask the reasons they do what they do.

What does a Developer Relations Ecosystem team do?

Some companies have evolved the Developer Relations area to a point they have a specialized orgs. Google is one of them, and I work under the Developer Relations Ecosystem team. What does we do?

Sticking to the broader DevRel goal (see the definition from my colleague Reto), I consider ourselves a connection layer. On the one side, there are the different Google Product Areas (PAs) like Android, Cloud, Assistant, etc, and we solve for them the complexity of dealing with local tech ecosystems. This scales global initiatives by engaging local developers. On the other side, that “articulated” tech ecosystem, where we’re often seen as the “last mile” between them and Google, brings valuable insights back.

How do we connect these two sides? We apply a 1:few:many interaction model. I see us (the one) as “passion multipliers“. We take Product Areas goals and, with a touch of magic, translate them for the “influencers” in their local context (the few), supporting them in doing even more of what they love doing. It could be organize tech communities, share their knowledge on Google techs, run amazing 3rd party tech conferences, solve people’s needs in innovative ways using company’s products, deliver best apps to clients and much more.
The more successful our audience is pursuing their passions, the more vibrant, mature and fun the company 3rd party tech ecosystem becomes (the many). A win-win situation I love and a way to implement Google’s philosophy “Focus on the user and all else will follow”.

We’re a tech team in the relationship business, at scale. Thanks to the trust component of our relationships, we have the rare privilege to be exposed to global and reliable first hand insights about developers all over the world. They let us know who they are and where they are; what they love and hate about our company’s technologies; emerging and descending trends; how they’re organising tech communities in every country; their success stories supported by our technologies. Because of this knowledge, we can be even more effective in building relationships and matching PAs needs, creating a virtuous circle.

Diversity is also deeply embedded in our team culture: there isn’t a project that can scale worldwide without considering how diverse the world is. For example, mentorship activities are very effective in some cultures, and totally against the mindset of others; developer and community dynamics in cities with millions of people are very different from cities with thousands; running a hackathon in Italy is different from running one in Nigeria, etc.
So, we naturally recognize the value of diversity and we focus on it, across our programs and audiences. What does diversity mean? Gender, culture, race, religion and many more.

From a team structure point of view, we approximated the complexity of the tech ecosystem splitting it in several audiences, like tech communities (GDG and all the other communities), Tech Experts, Startups and their developers etc.
Thus, we created work streams to deal with each one of these audiences, organising ourselves around two main roles. One gathers Program Managers that work on these streams at a global level, defining the infrastructure, strategy, goals, tools, budget etc. The other is made by people like me, called Regional Lead, in charge of executing these programs locally. It’s the implementation of “Think globally, act locally” strategy.
Maintaining a bi-directional communication channel between the roles is fundamental. Global work streams cannot evolve without the inputs, knowledge and experience from the local ecosystems provided by regional leads, while high-level directions from global allow us to operate in an aligned way despite we spread all over the world.

The most difficult challenge is linked to Ecosystem’s core: in fact, building these relationships at scale is a never-ending, tailor-made and time-consuming process, as the ecosystem is a living creature in constant evolution. In addition, after a certain point, we suffer from “reach-ability bandwidth” saturation: we simply cannot interact with additional people anymore and with all the amazing stuff they’re doing.

Apart from company PA goals, I personally see another important behavior for being a good citizen of the ecosystem we deal with: act as superb connectors. Pentland wrote in his book “It is not simply the brightest who have the best ideas; it is those who are best at harvesting ideas from others. It is not only the most determined who drive change; it is those who most fully engage with like-minded people. And it is not wealth or prestige that best motivates people; it is respect and help from peers.
Connecting people with similar passions helps the ecosystem to grow and improve in the mid-long term. It’s something you cannot control or measure, but years later, someone that has done something worthwhile your admiration will tell you: “Thanks to your suggestion all those years ago, I’m here now”. Priceless and crucial, this is one of my duties, and my passion!

If you’re curious about my life in Google, there are other posts to read.