Please log in to watch this conference skillscast.
Community is nothing new to developers. Just look at the open source movement, the numerous conferences, and the growth of collaborative resources like GitHub and Stack Overflow. Developers know the best solutions come from collaboration. In many respects, community is a superpower for innovation and problem solving.
So why is community so difficult to establish inside companies? It would seem like a natural opportunity given the collective nature and shared vision of being part of an organization. Yet when I visit most companies, community and collaboration are sorely lacking, and sometimes even discouraged.
In this talk, I share practices from my journey while at Stack Overflow and in other communities I have over the past decade to help all of us in the journey towards building healthy and thriving internal developer communities.
Q&A
Question: What do you do if the community grows too big (even if following Metcalfe's law) such that it is no longer engaging like it was when it was small?
Do you look at splitting the community into sub-communities?
Answer: Yes, splitting is ideal when the interactions become distant (people have formed cliques and do not engage as freely). This is something that is often done in the mode of communities of practice to identify specialty interests. There is this thing called the Dunbar Number, which states that the maximal size for any one person to maintain stable / trusted relationships is 150 people.
This is why bigger communities start to become unwieldy (and companies too). You simply cannot implicitly trust and maintain relationships with so many people. I talked about the trust layer of communities, and it starts to fray once the community gets too large. The way to address that is to create sub communities, still connected to the global community, but smaller so that trusted relationships can be maintained. As an example, I had a meetup several years ago that would regularly get 70 to 80 people. Then I had an event of over 200 people. It was a completely different feel and the social interactions were actually muted. Much less serendipity.
The point is not so much the specific number, but the context of how Dunbar impacts your community / organization. For example, my "Dunbar Number" for in-person events was around 75. Anything over 100 people became unwieldy and lowered the serendipitous engagements between attendees. So the real Dunbar Number can be very different for you based on what outcomes you are seeking to drive from your community.
Question: I was wondering about community burn out? At what point should you change things up?
Answer: Good call out on burn out, something I have faced. On burnout, you need to make sure you are recruiting volunteers to get involved, they will be the next generation of leaders over time. Also, never launch a community on your own, get colleagues to help.
Question: Obviously, StackOverflow does a private offering. Are there any other good knowledge-sharing/community-building platforms that you've seen work well for developer communities?
Answer: Yes, I have actually seen internal Slack and Discord groups in companies work. Also I like Discourse for knowledge sharing. Discord is free and often used in the gaming world. Discourse is a SaaS offering (launched by Jeff Atwood, the other co-founder of Stack Overflow). I break it down this way, Slack is often already in use or in place in many companies (if not a Microsoft shop that is), so adopting is easier. Discord is great and totally free, but may lose people that do not like the interaction aspects of the UX. Discourse is for canonical knowledge and conversations you want to keep and find later, so more forum or knowledge base oriented.
Question: Any specific tips on creating a global community (say within a company that has offices around the world)?
Answer: For a global company, start local or regional at first. There are language and cultural issues that are faced when going global that if you do not iron out early on can tank adoption and engagement.
Question: I'm curious about what you think the number one thing is that stops internal communities developing?
Answer: Number one thing is culture, some companies are stuck in old modes of management and hierarchic structures. But then again, those organizations often do not have great engineering teams and culture anyway.
Question: Can you talk a little more on getting leadership involvement? Is it different to getting them involved as "fans" or as community managers?
Answer: The best way is to build a business case, treat it like a real program and outline the goals, metrics, and outcomes to be expected. Then shop it to your leadership. In terms of leaders getting involved, once they give their support to the community, get agreement from a few of the senior leaders to participate in structured ways. The challenge of communities is that there are peaks and valleys of engagement, so create "events'' that bring the leader(s) into the community to interact. The best types of events are AMA style talks / discussions, online town halls, and hackathons. Why this work is that these are things that can be put in the leader's calendar. Get access to a leaders calendar and you have a lot of power to shape community involvement.
Question: Some communities start from the idea or effort of one person. How can these communities avoid revolving around these central figures so that they don't collapse when those figures are no longer there?
Answer: It is hard. I made that mistake where my persona overwhelmed the community and stunted the development of other leaders. I talk about this in the book as one of the traps faced. If you make a conscious effort to recruit fellow leaders / co-founders early, you can avoid this "cult of personality" that sometimes happens.
Question: Do you have any specific examples of communities that you feel are doing an awesome job? Those are at the smaller (50-500) end at the moment.
Answer: There was one quant trading firm that I worked with that did an amazing job and had under 200 people. What was the difference maker? Incorporating the community into the onboarding process and a member story of how the community helped that resonated with everyone. The story hit the WIIFM that I talked about and once that was clear (in this case, get answers to any question fast), the community took off.
Question: When developing your community you mentioned the 5-10% high participation. Is there a risk that you end up with only those voices dominating the community? How do you balance keeping their useful contribution to content vs potentially drowning out or discouraging others' contributions?
Answer: This is a common issue, in smaller communities, a few "louder" voices can take over. It will happen and does so in every community. A small number of people will dominate the conversation. That is actually not a bad thing because that ensures there is "liquidity" of engagement and content in the community. What you can do to ensure that others can also engage and feel safe is to have a Code of Conduct and ensure that communication about the community promotes content and contributions from the group of casual community members.
Question: Do you have any recommendations on how to build a productive community around an open source software. By productive I mean : A community that continuously improves the open source's code base, constantly engaged with the roadmap of the open source software.
Answer: For any community, it comes down to "do people really care about it"? That is the first step in what I outlined when building a community. Start there and build your community from the steps I outline, it does not differ whether you are building a dev group for API's, a community of practice on engineering practices, a group for K8s, or a community around an open source project. All the 8 steps to building community remain valid.
YOU MAY ALSO LIKE:
Launching an Internal Developer Community
Mark Birch
Principal Startup AdvocateAWS