When a community program grows, it moves from a one-person band role, to a team of people, to a team of teams. And Community Operations is often one of the first teams formed. When to start one, and how to scale it? What are its key responsibilities? It’s just about data, dashboards and automations, or is there something more? In this session, I shared my best learnings in leading a dev community operations team in Google, the most embarrassing failures and “the road head”.
Good managers are made, not born. It makes no difference for a team of community builders, with added complexities such as remote working, high burnout risk, unclear career path. I’ll share my story covering topics about hiring, set a vision, metrics, remote management, work-life harmony, etc.
Here my story covering topics about hiring, set a vision, metrics, remote management, work-life harmony, etc.
There are common challenges every team of community builders faces. Contribution to company’s goal, team members alignment, long term planning and execution with the next step already in mind, a diverse and rich community landscape to support, etc. Mine is no exception, and we tried to address, or at least mitigate, some of these challenges thanks to the Feverbee’s Community Strategic Plan.
Why the Community Strategic Plan, and how?
I’m deeply rooted in the importance of the whys, the reasons motivating our actions. In the context of a brand community program, the whys are the goals the company wants to pursue, thanks to the community tool. The complexity every community professional faces is to link those goals with dat-to-day execution. The Community Strategic Plan creates a clear connection between these two extremes. Via interconnected hops, defining the overall community strategy, tactics, expected results, resources allocation and other important elements.
The first time we worked on the plan, we followed all of its canonical key elements. The second time, we deviated slightly from the manual, focusing on the following key elements:
Goals: what the organization wishes to achieve from the community.
Objectives: what behaviors community members need to perform in order to achieve the goals.
Emotions: what feelings to amplify and leverage, in order to influence community members to perform desired behaviors. We expressed them using the perspective of user stories. For example “I’m proud of giving back to my local ecosystem thanks to technologies“. Or “I am motivated to offer compelling content to my members to increase hands-on learning at different levels“.
Tactics: the specific projects the team will execute to amplify these emotions. We didn’t go too deep into defining action steps, because we made the plan in the context of an entire team. Once a person, or sub team, starts working on a specific tactic, they will also have the freedom, and responsibility, to define detailed steps.
The Community Strategic Plan and the existing team culture
In Google, we use OKRs. For the Community Strategic Plan to be truly adopted and followed, and not to be forgotten after the initial enthusiasm, we had to find a way to insert it into the “existing team flow”. Luckily, it’s wasn’t that difficult, as a mapping between the Community Strategic Plan and the OKR framework is pretty straightforward. From the OKR angle:
Objectives express goals and intents
Key Results express measurable milestones which, if achieved, will advance objective(s) in a useful manner.
So, considering the key elements of the Community Strategic Plan aforementioned:
A goal provide an high-level categorization of a group of Objectives in the OKR
An objective maps with an Objective in the OKR
A tactic maps to a Key Result in the OKR
Bonding the Community Strategy Plan with team OKRs was the way to keep team members focused on the tactics. In general, I strongly encourage to adapt and connect the Community Strategic Plan to the existing team habits. For several teams, adopting the plan is already an important mindset shift, so it should not be weighed down by further changes to team routines.
Work on the Community Strategic Plan in an remote team setup
Honestly, it was quite a complex exercise to work on the Community Strategy Plan in a remote team setup. Because of the many consequent steps, the many “diverge-converge-decide” phases, the non trivial amount of time, focus and effort required to formalize the entire plan.
I started making each team member aware of what is a Community Strategy Plan, and the potential advantages in adopting this new framework in the team. Thanks to previous retrospectives about the work we did together, I had enough material to support the proposal.
Then, with a sub group of experienced community builders, we set goals, objectives and emotions. We iterated twice on them, to be sure we developed quite extensively the company goals, without leaving anything behind. The experience of the sub group allowed to focus on the important elements, to interpret goals considering also “historical context”, and to identify emotions, thanks to their deep knowledge of community members.
Finally, we shared the pre-work done with the whole team, and leveraged everyone’s contribution for a tactics brainstorming. Fresh-air and alternative points of views, provided by newer team members, were really useful. We then prioritized tactics and picked up the top ones, completing the last element of the Community Strategic Plan.
Challenges and opportunities ahead
As I mentioned at the beginning of this post, strategic thinking and purse team alignment while working with the full spectrum of communities is one of the core reasons we created our Community Strategy Plan. With the plan now in place, I asked every team member to constantly check if the ways they’re spending their time with communities resonate with one or more priority tactics. If yes, 👍. If not, or they may need to refocus their effort, or we may need to improve and adapt the plan, as no tool is the perfect tool, especially over time.
Speaking about time, the more you move closer to execution (from company goals down to tactics), the quicker is the “speed of adaptation“. It means goals are here to stay for the long period (ideally), while tactics may change quickly. When we prioritized tactics, we had to left behind some interesting ones, or others that needed for some pre-condition to be true, in order to become feasible. I’m quite sure, in the future, we’ll include some of those tactics into the official Community Strategic Plan.
Measurement is another area of untapped opportunities: in fact, for some of the priority tactics, we hadn’t a precise idea on how to measure the impact, or even the progress. We had a feeling it should be possible, and that was enough to commit to do it later. It’s not a “postpone-to-forget” attempt, but it could become without the right discipline. So I foresee lot of data-oriented learnings we’ll acquire executing those tactics.
After a 3 years long tradition of in-person team summits, to retrospect, brainstorm and plan the work of the team, while having fun together, we had to switch to an virtual team summit format. Here the key learnings worthwhile sharing.
One format doesn’t fit all
Core insight: the experience of a team, may not perfectly apply to another one.
Every team is different. In order to have a successful virtual team summit, it’s important to consider some team characteristics. Like number of people, familiarity of the team members, team culture, etc.
For example, if a team culture doesn’t support a collaborative environment and open discussions within team members, chances are very low a brainstorming activity can be successful. In person, even less online. The same goes for a team with several new members. The less people are familiar with each other, the less they’ll speak in team-wide discussion tables. In this case, smaller group discussions, 1:1, and a final moment of sharing, may work better.
As a reference, my summit targeted a team of 12 people, with a minority of new team members; mostly on the same time zone (within the +/- 2 hours range); already familiar with feedback oriented and collaborative activities (like retrospectives, brainstorming, etc.), but in an in-person setup only.
And this is the agenda we used:
Day 1, morning
90 mins: icebreaker + welcome + activity 1
30 mins: (social) break
60 mins: activity 2
Day 2, morning
90 mins: icebreaker + activity 3
30 mins: (social) break
60 mins: team fun activity
Why this format? Let’s explore the main reasons:
The importance of energy level
Core insight: several mornings are better than one of two full days.
It could be tempting to run an entire day of virtual team summit, or even more days. From my experience, it works well with in-person summits, but it’s not really the best for a virtual summit. When you work from home, life happens, and you need to leave space for it. Cook the meal, take care of family members, bring out pets, etc.
In addition, online collaboration drains more energy than in-person collaboration, so people need more time to recharge.
My suggestion is to spread the team virtual summit across different mornings, or to the closest possible scenario allowed by time zones. Morning is when, generally, the energy level is higher, and attendees can start the summit with a fresh mind, so more focused.
Alternatively, use the mornings for collaborative activities, and reserve the afternoons for reflective and individual activities. So people have more flexibility to arrange their time and work in the way they prefer.
Activity blocks duration
Core insights: start with a 90 mins block, then 30 mins break, and a final 60 mins block.
After observations, my favorite format is to have two main “working blocks”: 90 mins, followed by another 60 mins, with a break of 30 mins in between.
It’s hard to remain plugged and productive for 90 mins, twice. Plus, a 3.5 hours (90+30+90) block is hard to accommodate in a “morning”, when the attendees cover slightly different time zones.
Blocks of 30 or 45 minutes are generally not optimal for virtual summits, for what was said previously (context switch, ease of getting lost, etc), unless there is a very specific and short activity to run.
Of course, the time slots allocation really depends on the kind of activities to run:
90 mins seems OK for time boxing a brainstorming-like session: there is time to explain the challenge, diverge, discuss, converge. If the challenge is very complex, it’s possible to explain, diverge and discuss in the first 90 mins, take a breath and detach during the break, and then use the following 60 mins to converge and close the activity.
If there are lot of presentations, it’s better to have 25 mins slots (20 mins for the presenter, as per TED talks rule, 5/10 mins for Q&A) then 10 mins to break, where attendees have time to absorb what was said, before jumping to the next presentation. Avoid very long (+45 mins) presentations, or a 60/90 mins continuous alternation of different speakers: it’s the best way to kill audience attention, and attendees will quickly turn to do something else.
Hackathon-like activities would require the full morning / day slot, with teams auto-organizing their time.
A Design Sprint could even be run in a day, with Map, Sketch and Decide phases during the morning, and Prototype and Test phases for the afternoon, or in the following morning.
Core insights: 30 mins to detach completely, potentially alone.
Breaks should be 30 mins. It’s enough to move away from the personal working area, have a bio break, detach a little bit. And also prepare something to eat and/or drink, as we don’t have the luxury of catering service.
Create a different Meet/Zoom/Teams appointment, called “[Optional] Social break” for people that wanted to chat and gossip during the break. And make it very clear that it’s optional to attend, that setting separated chat groups is OK too, or even spending the whole time “away from the desk, and alone”. This is a 100% attendees truly reserved time: they should have freedom in choosing what to do with it.
Team Fun activity
Core insights: have fun, together. Contextualized to the attendees group.
Having a dedicated moment for fun is an important part of every summit. It bonds people together, allows for serendipity, helps to recharge batteries, etc. It’s even more necessary now, where we haven’t seen each other in person since a long time.
In addition to some short ice-breakers (5-10 mins max) at the beginning of the other slots, I dedicated an entire hour for a specific fun activity. At the end of the second morning, as a way to celebrate together the achievements of the summit, and to relax the pressure. There are millions of fun activities to run, and it’s important to select something appropriate for the audience.
In a just formed team, having the fun activity at the beginning of the summit could be a better choice. It could help to build the initial “social infrastructure” that will favor collaboration and interactions for the rest of the event. For a longer virtual team summit (3-4 mornings) it could be run in between of the days, to take a break.
Set summit goals in advance…
Core insight: well defined deliverables, in advance.
I’m a supporter of setting and communicating in advance what should be the desired outcome of a team summit. A tangible set of deliverables, everyone can measure the progress toward. Even more for a virtual team summit.
While in person it’s easier to be agile, and pivot and replan part of the activities in a short time, this is generally more difficult for virtual summits. In person, it’s possible to quickly identify where the team consensus is going, if some attendees got lost, the overall group emotional status, thanks to many non-verbal communication elements. Also “implicit peer pressure” exercises a strong influence (if I perceive that several attendees think this is an important topic to discuss, probably it should be important also for me). In a team virtual summit, because of the lack of many non verbal elements, the same is not always true.
Creating and sharing the agenda in advance, avoids this problem. Through iterations, 1:1s and feedback, it is generally possible to reach a wider team consensus about the goals to achieve, and how, before the summit.
A well known agenda also fosters engagement. It helps attendees to approach the different summit segments with the right expectation, a more appropriate mindset and, generally, come more prepared.
… and don’t overcommit
Core insight: less is more, because of focus and energy.
It’s easy to stuff a team summit with many desired goals, we all know. The real difficult, and valuable task, is to trim them down to very few deliverables, and run specific activities to reach them.
Context switch puts an important burden while working from home. At the end, we’re physically alone. So, it’s easier to lose track of where “the rest of the team is”. Or get distracted by “the rest of life” as soon as there is the feeling of not being able to keep up with the speed of the team.
In addition, for a moderator it’s really hard to check if attendees are “present and aware”, or if something else is competing for their attention. Again, a video/audio only interface cuts out a lot of non-verbal communication elements.
Few deliverables help to keep the attendees focused, provide a sense of fulfillment once they’re reached, feeding engagement (we’re all happy to be an active part of something that works).
The right tool for the right session
Core insights: carefully match an activity format with the most appropriate tool to run it.
A Google Doc or a Google Sheet can be the jack-of-all-trades for plenty of collaborative activity formats. But they may not always be the best tools at your disposal. Maslow said: “[…] it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” UX matters, and I personally consider it valuable to spend (a reasonable amount of) time to find, or even create, the right tool for the right activity format. Attendees will benefit from this attention. The more they are, the bigger the benefits.
For example, here my screen setup while running a brainstorming activity:
From left to right: the “virtual whiteboard where we collected our ideas” (a Google Drawing doc, resembling a whiteboard with sticky notes and voting dots); the Meet window, so I always remained in visual contact with the summit attendees; a countdown I used to time bound activities: the doc where the note taker took notes about the discussion. And yes, I really love my ultrawide monitor :)
Ask for feedback, and iterate
Core insights: we’re all learners, and we need quality feedback.
Surveying attendees about the “Overall summit satisfaction, on a scale from 1 to 5” is the bare minimum. Asking them why, what was the best part of the summit, the worst, and what they missed (a start/stop/keep doing/best approach), provides good insights. To really learn and improve, ask detailed feedback for each activity.
Include the feedback activity in the summit agenda. Reserve 5 mins, before closing the summit, for the survey. It will be an awkward moment of silence, but the completion rate will skyrocket (up to 90%, even more). Share the feedback with everyone. Attendees will appreciate the point of view from others, and they can always learn something. If it’s not possible, share the core insights obtained from the feedback. And use them to adjust the next virtual team summit activity.
(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)