By clicking “Accept All Cookies”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
Playbook
GTM Playbooks
Playbook

Building Community and Dev Rel at Product-Led Companies

This post by Dan Nguyen-Huu is part of our series on Product-Led Growth Playbooks, an emerging field that pushes the boundaries of conventional sales, marketing, and customer success. In the series, we share insights and advice from leaders who have built successful PLG businesses and offer specific playbooks for founders running high-growth software startups targeting software development teams today.

Tim Berglund knows developers and we’re lucky to know Tim. Tim has been a part of today’s leading developer companies like GitHub, DataStax, and Confluent, where he’s Senior Director of Developer Advocacy.

He was gracious enough to sit down with me to map out the keys to building a developer community, scaling Developer Relations, and running a developer marketing playbook with equal parts authenticity and excellence.

Playbook: How To Build Your Developer Relations Team

So, you are building a product-led or open-source company that focuses on a developer audience. How do you build a following? And, how do you support that community once you’ve built it?

Hiring in DevRel can feel like you’re stuck trying to work out a chicken and egg problem. Do you hire someone to write the docs and technical blog posts that will create demand? Or do you hire that person once there is demand?

Tim’s answer, if you believe in your product, is to start hiring.

Your First Key Hires

The Developer Advocate: At the start of your organization, in its nascent stages, this person will be a jack of all trades, a road warrior, and a pillar of the developer community.

“They might live-code their way to glory in front of hundreds of developers at a meetup, and then help clean up pizza boxes after.”

There’s a duality to this role in the early stages of your company. The Developer Advocate functions as a beacon for the community, but isn’t too proud to do gritty work.

That could mean filing tens of CFPs for the conference season. It definitely means flying and driving to Meetups, conferences in that Developer Advocate’s metro area and beyond. And it also means engaging in electronic channels like Slack, Discord, StackOverflow, and Twitter.

“To boil it down, the Developer Advocate has to do a good job not just saying your product is awesome, but helping developers become awesome as they learn to use it.”

Keep in mind that, as your team grows, you’ll need to distinguish between types of advocacy. Instead of one developer advocate flying to conferences, producing content, and managing your docs all by themselves, those tasks will form separate disciplines within Developer Advocacy. You’ll have a conference or evangelism team, a content team, and a docs team who are all uniquely focused on those three critical areas of Developer Relations.

The Community Manager: This person has their finger on the pulse of your developer community and the developer community in general. They are your company’s eyes and ears on the internet, identifying and tracking opportunities for your Developer Advocacy team to educate and inspire their peer developers.

They are likely closely monitoring Twitter, Reddit, Stack Overflow, YouTube, Twitch, and any other key developer outlets to see how the content you publish to those platforms is performing, what you can learn from the community’s response, and how you can be a better member of that community.

Those learnings should be easily accessible in well-written Worked / Not Worked-style reports as well as data-oriented reports. When someone asks, “how did that blog post do?” they should have a metrics-oriented answer. When someone asks “what was it about?” they should have a crystal-clear answer that sells the narrative of the post and it’s impact on the community.

The Community Manager should be, as Tim says, “the soul of the community.” It’s a tricky job to fill, but an equally impactful one at that.

Playbook: What Dev Rel Areas to Focus on And When To Do It

You can see from the responsibilities of the first two critical hires that the landscape of Developer Advocacy is broad. So, where do you focus first?

Tim outlined the several critical areas he sees as essential to a quality Developer Advocacy team.

  • Documentation: This precedes any formal DevRel effort, and indeed is so necessary a part of anything with a developer-facing surface area that it must exist in the absence of any formal DevRel investment, in any stage of your company. However, Tim includes it in the list because as the team grows, a formalized documentation team rightly belongs under the DevRel umbrella.
  • Developer Advocacy: Your first formal DevRel hire will probably be a developer advocate. This is a person with an engineering background who is also a gifted teacher and communicator, building sample code, giving presentations, making tutorial videos, and (as occasional pandemics allow) traveling to in-person events to meet with your developer community face to face.
  • Community Programs: That lone developer advocate can’t succeed as a solo act for long. Robust programs need to be created and operated to track conference activity, build a Meetup network, manage online channels like Slack and Discourse, operate an MVP program, and so on. This specialized team provides this structure, with special sensitivity to the needs of developer communities.
  • DevRel Engineering: Many DevRel teams find that as they scale, they need more sample code written than developer advocates can manage. A DevRel engineering team is a team of developers, skilled in the product’s technology space, who are eager to build useful applications and sample code to help community members get started with the product and explore its advanced features.
  • Content Operations: The growing team is building a lot of content. If Marketing has a formal Content Operations function with bandwidth that can be dedicated to DevRel, excellent! If not, a dedicated Content Ops team will eventually emerge to shepherd blog posts, podcast episodes, educational videos, and sample applications from conception through production to release.
  • Video: Hopefully, Developer Advocates have been making their own screencasts since day one, but as the product grows in features and use cases grow in complexity, so will the team’s output of educational video. In-house video production is unlikely to live under DevRel itself, but this is an important differentiator worth its own investment. Videos should be concise, as code-centric as possible, and feature on-screen talent that can deliver a quality experience with the authenticity that only a developer can bring.

Conclusion: Building a Community is Long Term yet Highly Rewarding Endeavor

Building a developer community is not a side project. It’s not something you can schedule a block of time to focus on for a few hours a week. It’s a daily practice that requires equal parts effort and empathy.  

To build a strong developer community, you have to steadily produce content that your community needs today and the content they’ll need tomorrow. Making these investments not only pays off in customer loyalty and product growth, it just feels good. When a company has a genuine following of developers, and a genuinely passionate community, that’s palpable. It’s not something you can buy, but it’s worth a whole lot.

A photo of Tim at the Kafka Summit SF 2019—the last in-person Kafka Summit before the Pandemic. Ale Murray, Confluent's Global Community Manager, had just kicked off the MVP program. All of the MVPs who were present at the Summit went to Build A Bear on the Pier and made a stuffed animal. Legend has it that this little guy is still sitting in his office, visible in the background of Zoom calls.