An opinion I’ve been mulling over for some time has recently crystallized for me: If you work for a company that’s platform or service has created a community around it, you are not a part of that community.
Chef employees weren’t part of the Chef community. Cloud Native Computing Foundation employees aren’t part of the CNCF community. And AWS employees certainly aren’t part of the AWS Community.
My intention is not to go tumbling headlong into the No True Scotsman fallacy. But I’ve seen a number of companies either knowingly or accidentally subvert their communities because they don’t understand that their employees are not and can not be part of the community.
Here’s what I mean. Back when I was deep into the configuration management weeds, I managed to never use Chef. Yet somehow, I attended Chef conferences and was always predisposed to think extremely well of the product based solely upon the strength and exuded kindness of its community. This was a great thing.
Then, one day, Chef began hiring its passionate and well-regarded community members. As I looked at the hires, each person unquestionably made Chef a better product and a better company. This was not a bad thing!
But soon, the entire “community” seemed to be Chef employees talking to other people whose email addresses ended in Chef’s domain. This was a bad thing for the community.
What is community?
To understand why Chef’s community had a problem, it helps to understand what a community is with regard to a platform or tool. Communities generally emerge from a place of shared suffering or, more optimistically, a certain esprit de corps amongst users of a given offering.
Communities have fundamentally shifted the ways that people engage with buying and using commercial software. If I buy popular software and it doesn’t do what I need it to, or I can’t figure out how to adapt it to my use case, my immediate response is no longer, “time to reach out to the company and ask about it.”
Instead, I turn to the community of people who use that product. Once upon a time, that meant joining an IRC channel or a mailing list. Today, that may well mean looking at Stack Overflow or popping into that community’s Slack or Discord. And, of course, asking people you trust in your circles whether you’re doing something right or wrong is always a good move.
The primary mistake companies make with communities
The best communities are the ones that spring up organically, whether from love or from pain. “I have to use this thing, it sucks in some ways, how do the rest of you wrestle it into submission” is the subtext underlying most questions in community forums. This is inherently at odds with companies’ stated positions, which carry a subtext of “our product is awesome and you should use it more, scaling it particularly in whichever direction best aligns with our pricing model so you can give us money faster.”
The problem comes when companies overreach and attempt to either control the community, which is bad, or appear to be attempting to control the community, which reduces down to the same thing.
What companies underestimate is how much a trusted voice in a community can make or break a product’s reputation among a significant subset of its potential market. If a company owns or appears to sway those voices, the company loses out.
How AWS fosters its communities
AWS is a fascinating example in this direction. (You probably knew I was going to get around to my Favorite Cloud Provider™ sooner or later …) I could instead talk about the CNCF’s approach to community, but I do try to only kick one beehive at a time lest I get stung to death.
Originally, AWS manifested its community by crowning Community Heroes, a collection of voices in the community who had demonstrated both expertise with the platform along with a willingness to share their knowledge. It’s proved a valuable way to identify folks doing things in public to help the rest of us learn, and I’ve met some truly great Community Heroes over the years, including Eric Hammond, Ben Kehoe, Matt Coulter, Ben Whaley, and many more. In recent years, AWS expanded its programs to include AWS Community Builders, of which I’m a member. (Incidentally, I highly recommend the program, though I confess I have absolutely no idea why they invited me!) Community Builders casts a far broader net than AWS Heroes and picks up rising voices that aren’t yet being recognized as notably within the community. I like this approach to nurturing the community — with the caveat that it feels like AWS is trying to capture more and more of the community under its own umbrella. It’s toeing the line between fostering its community and appearing to be trying to control it.
The problem with AWS’s community pipeline
I don’t have a problem with AWS hiring from its community; there’s certainly no risk of running out of AWS users who are learning in public. The challenge is when community members they hire don’t internalize that their role has fundamentally changed.
Let me draw you a picture. As an AWS Community member, you might very well respond to an application architecture question with something akin to “and for this part you want to use Google Cloud Run, because AWS’s container offerings are convoluted, expose too many abstractions, and, frankly, seem to be competing for mindshare with one another rather than solving customer problems.” If you were to say that as an AWS employee, it’s hard to imagine that the AWS containers service team doesn’t come for you with knives out, or that the marketing department starts carrying a subtle grudge. You can’t live in both the community and take home an AWS paycheck. You’ve lost your status as a trustworthy third party.
Extend that logic to community members who see the community program path as a gateway to future employment opportunities (which it absolutely is!). Are those members as likely to say accurate-but-unflattering things about the community’s core product focus? Corporate overfocus on the community weakens that community; there’s no way around it.
In a recent discussion on the new AWS Collective over on Stack Overflow, there’s a question that would test divided loyalties. Should the community tag topics with a generic aws- or go back and forth between Amazon and AWS the way that their formal product names do? The community itself wants to be able to categorize these things in a way that makes sense to them, whereas AWS Marketing absolutely would prefer the latter — and that makes the former the correct option.
tl;dr If you equate “community” as being the same thing as “people we can market to,” then you’re inherently misjudging what community means. You’re also on the inside–and “community” does not include you.
