Community as the Front End of Data Management and My Evolution From a "Not My Domain" Community Manager
I recently wrote about my thoughts on the future of community management, the evolving role of the community manager, and the role executives should play in this transition. After seeing a post on LinkedIn from Josh Grose that mentioned the mentality of a "not my domain" community manager, I realized it was important to share my journey moving away from the "not my domain" mindset after working very closely with product-led startups on their earliest community collaborations.
In a large organization, it's easy and often beneficial to clearly delineate what falls neatly into your scope versus what should be handed off to another team or colleague more suited to the task. This is one of those leadership skills that they never tell you that you should learn to do: knowing when and how to say "no." Failing to develop this skill can set you up for frustrating encounters with territorial coworkers who feel that you are encroaching on their area of expertise and responsibility - especially in a time when no one is feeling particularly secure in their job.
However, holding inflexible boundaries prevents you from building key relationships and filling your proverbial jar with political tokens. No one likes the "not my job" coworker. They are not a team player. They do not step up or go "above and beyond" when the team needs extra support.
Over the course of my career, I've gone from a 100,000-person company, to a 2,000-person company, a 200-person company, and finally, all the way down to a 20-person company, and finally, to a one-woman show. In that time, I went from having lots of red tape (con) and plenty of resources (pro), to very little oversight (pro) and extremely limited resources, especially with regards to people with relevant skills and overlapping responsibilities (con?). When you're working in a startup or other small or medium-sized business, there are simply fewer resources (time, people, money, etc.) to go around. Team members must be more willing to "wear multiple hats" or key business functions become neglected and the business will suffer or die. It was in this startup environment that I grew from a "not my domain" community manager to a "community-led organizational strategist."
What in the world is a "not my domain" community manager?
The "not my domain" community manager refuses to work with marketing, sales, product, support, and whomever else they've deemed "not community-friendly." This community manager is an inflexible, stubborn, ideologue who simultaneously believes in the purity of community and struggles to draw a straight line between community engagement and the company's bottom line.
With the luxury of big company resources and support of an executive or two, I was this community manager. I was a hero of the people, standing up to the big, bad marketing scoundrels and keeping the community clear of marketing drivel. At least, I was until I realized that this mindset was incredibly limiting to what influence the community had on the company and the growth potential the company had in the market.
Why do "not my domain" community managers exist?
Honestly? Trauma.
Community managers are the face of the company - often to its most disgruntled users. We troubleshoot in public. We defuse public customer meltdowns. We protect the brand and we advocate for our members behind closed doors. We are the go-between, torn between our responsibility to the company and our empathy for the members. We often see the best and the worst behavior and we're responsible for protecting the rest of the community from that bad behavior - sometimes by bearing the brunt of the abuse. Historically, we have carried a great weight of responsibility, held up by unrealistic expectations and insufficient support from our own companies (tools, budget, headcount, etc.) to perform our duties without lighting ourselves on fire to keep others warm. We have seen some shit.
What does a recovered "not my domain" community manager look like?
I still believe that there is a right way and a wrong way to engage with your community and to produce community content. However, what I lacked before was the nuance to explain this difference to the various stakeholders who, frankly, I needed on my side to be successful at advocating for my members. I also had not yet adopted the perspective that community belongs at the heart of every single function within the organization. It was easier to just toil away in our corner of the company and hope no one would bother us.
Now, when I talk about the community, I help my internal colleagues to understand their role in the community (instead of fighting their presence, like white blood cells to a virus) and we explore together how the community can help them achieve their own goals. I also actively encourage all of the relevant cross-functional leaders to make community an element of their team's quarterly and annual goals, in whatever way it is appropriate for them to do so. This relieves the pressure of conflicting incentives for non-community teams, like customer support, to free up resources for things like content creation and community engagement, which ultimately makes their jobs easier and saves the company money.
If Content is King, Then Context is Queen. Long Live the Queen.
Even the most beautifully written article can have little or no effect (or worse, the opposite of the desired effect) without consideration for the audience's context. Any good Communications 101 course will tell you that communication is dependent on "senders" and "receivers." How well the receivers actually understand and interpret your message depends on your ability to contextualize the message for them in a way they can relate to.
One of the key differences I focus on today between community work and other traditional parts of the business (i.e. demand gen) is to be explicit about who our respective audiences are. Community is focused on individuals while demand gen, sales, marketing are all focused primarily on customers. At a B2B organization, that fundamentally means that they are trying to attract organizations. Functionally, this might look something like this:
When thinking about how these two teams might approach a topic like loyalty or advocacy differently, it's easy to see how the key difference is the audience. It also helps us to see where there may be overlap. In this example, the overlapping area might include brand announcements (new product launches, release notes, and other PR-type communications). This is an important distinction to make because it impacts the company's operational, promotional, and data management strategies.
Wait, whoa, we're back to data again? I thought we covered that last time!
Yep, friends. Community management is the front end of data management. And this topic isn't going away, so strap in and get comfy.
Community management is the front end of data management.
How does this very basic Venn diagram of recognition milestones relate to data management?
Well, how do you think we would manage these programs, communications, or campaigns from an operational perspective?
One way is to create two separate mailing lists. One is for community communications and the other is for marketing communications. That way, we can send all the communications that fall under the community's scope to a single mailing list and the other communications can come from the marketing distribution list.
Why wouldn't you just select individuals from the marketing list when you need to send a community-related message?
This is where understanding our community member's user journey, which we'll dig into in more detail next time, comes in handy. In short, from a compliance* and best practices perspective every member should have as much control as possible over how their data is handled, stored, and used.
If you offer only one single marketing mailing list, the user only has the option to opt in or out of that one list. If they opt out, you no longer have the option to email them about community things. Instead, if you give the user multiple use cases as to when you might use their email address to contact them, they may choose to stay in certain mailing lists and not others, rather than opting out of contact from the company entirely. That's win-win.
*Obligatory legal disclaimer: I am not a lawyer. This is not legal advice.
There are a lot of things to know about when managing a community. It's not just engagement for engagement's sake.
You're tellin' me, kid. And it's all related: people, data, communication, and the technology that makes it all possible. That's why community builders are both team captains and utility players. We go where we're needed and we learn whatever skills are required to get the job done.