How to Build an Awesome Developer Community When You’re Not a Developer

“Do I have to be a developer to build a developer community?”

I’ve heard that question countless times. Sooner or later, it pops up in every community group, asked by community professionals thinking about a career in tech, but unsure they can make it without a technical background.

Well, I’ve never written a line of code, and I work as a Community Evangelist at Estimote. We’re a startup focused on mobile developers. I’ve learned a few lessons along the way that aspiring community professionals will find useful as they build a developer community around their product, not only to use it, but also to discuss it, promote it, and contribute to its development. Product-oriented community works like a hive mind, a distributed effort toward a common goal. For the most part, it’s not about the technology itself.

My non-technical background isn’t exactly a special case either. Even SendGrid and Twilio, classic examples of companies that have built a developer community, have had non-developers on their community teams (hi Tim, hi Lisa!).

So, let’s answer that lingering question once and for all: Do you have to be a developer to build a developer community?

…No, but you need to think like a developer.

Even if you don’t think in code, you should think like someone who does.

Every profession has its habits, jargon, and a specific way of perceiving the world. Your job is to create a place where developers feel at home. Not all developers are the same, sure, but the more developers you meet, the more patterns you will notice. They speak the same language of pull requests, forked repos, and API tokens. Yes, you need to learn that language. No but’s.

Many developers obsess about productivity. They think in systems, identify patterns, and have an analytical approach to problems.

Does that description sound too simplistic? It is.

It’s accurate… within an order of magnitude. You shouldn’t trust anyone who says they can explain how developers (or designers/journalists/construction workers) think in a couple of sentences.

There are no shortcuts to learn the developer’s mindset. The only way to do that is to actually talk to developers.

Start going to lunch with technical teams in your company. Attend some of their meetings and planning sessions. Follow what’s happening on their Slack/HipChat channels. Discuss user feedback directly with folks who built the features in question. And look outside the office too. Attend the next tech meetup in your city. Read some discussions on Quora and start following tags relevant to your community on Stack Overflow.

You might not understand the contents of a thread like What is the most complex line of C code you have created? You don’t need to understand the in’s and out’s of the answers. Rather, read it to understand the joy of observing people discussing the details of their craft. This kind of armchair anthropology will put you in a much better position to build a developer community.

…No, but you need to understand the product.

All communities are about people. But developer communities are also about products. They gather people interested in using specific tools for specific purposes. If you’re not going to be an expert in using these tools, you should be an expert in explaining them.

Read success stories to understand best practices and the context in which developers use your tool: if your company doesn’t publish them, ask customer success/business development/fellow community professionals to share some. Learn how the product evolved: check old forums threads and look up the changelog.

Only knowing the product and its users, you’ll still be able to showcase relevant case studies, answer common questions, and encourage people to contribute to the community with their writing. That last thing is the most important. When your community members feel you care about them, they’ll write tutorials for your tools, organize meetups around your product, and if you’re open source, even fix your bugs. They’ll evangelize.

How do you know if you’ve learned enough about your company’s SDKs and APIs? A good litmus test is checking if you can point someone towards the right place in the documentation if they ask about implementing a feature. This shows that you’re comfortable with the product and know what’s happening under the hood, even if you couldn’t use it yourself. It almost goes without saying that this test is not a one-off trial-by-fire. Software changes all the time, especially with everyone striving to be agile and ship daily. What you’ve learned gets outdated all the time.

At Estimote, we’ve established bi-weekly “stack reviews”: short meetings to make sure everyone is up to speed with the latest releases. It doesn’t take more than 20 minutes and helps ensure we’re on the same page.

Because everything changes so fast, don’t get discouraged if you don’t understand or remember something. Not even developers in a company know all the in’s and out’s of the product they’ve built. No shame in that, software is way too complex for a single person to know a large codebase by heart. Just know whom to ask when you get stuck.

If your company uses collaboration tools like Confluence or Asana, maintain a document with technical details and a FAQ for your product. Otherwise, use a Google Doc. Just make sure there’s someone assigned to updating it. Outdated documentation is worse than no documentation at all.

…No, but you need a developer on your team.

Any community team in a developer-oriented company does need an actual developer on board. Initially, our team at Estimote didn’t have a full-time developer. It worked for a while. We still managed to keep a presence at events across the world, constantly improve our content, and provide good customer service.

However, we struggled to go a level higher. Our capacity to support hackathons was limited. Writing technical content dragged. And the 10% of the most difficult support inquiries would lay unanswered for days, because product teams always prioritize shipping over troubleshooting.

The moment we brought in a specifically code-writing Developer Evangelist, the whole team became much more effective (we wrote more about this on our blog): from support, to content, events, feedback gathering, developer relations, we became more proactive and relatable to our community.

Adding someone with a skillset that complements your team’s qualifications will make the team improve exponentially. So if you want your Developer Community team to make the leap from good to kickass, then you’re going to need to bring on a Developer Evangelist.

…No, but it wouldn’t hurt to learn.

This may come across as hypocrisy. After all, I admitted that I’ve never written a line of code myself.

What can I say? Taking your own advice is hard. That’s why you should take it from yours truly and don’t repeat my mistakes.

Chances are you will not become a great developer. But you don’t have to be a great developer.

You don’t even need to build anything yourself. Learning programming for the sake of building developer communities is an extension of thinking like a developer. Even basic knowledge of programming will help you a lot with understanding the community and what your product means for it. That’s a fundamental knowledge if you want to engage your developer community.

You can learn more than just programming too. Users of developer-oriented products do much more than write code. If, like me, you don’t feel too good about the Xcodes and Android Studios of the world, there are other fields you can build expertise in. Read up on product management. Take courses in UI design. Learn about UX. Knowledge is abundant in the world. Coursera, Udemy, iTunes U, and hundreds of niche blogs offer more wisdom that you could ever dream of processing. Take advantage of that.

The bottom line is: acquire domain knowledge. You will have a much easier time building a developer community if you don’t narrow your expertise to community building. Stretch your expertise into allied fields that will help you talk to your community more fluently.

…Or maybe?

There are teams that build developer communities where I initially could not imagine working without a developer background. Companies like Docker or MongoDB come to mind. Their products are so deeply technical that you cannot abstract them from writing code, the way you can abstract Estimote to microlocation, Twilio to text messaging, or Oculus to video games.

But then I researched their openings in “Community Management.” None of them require a technical background. Maybe that’s not so surprising after all.

If you want to build a developer community, go for it. You don’t need to be Linus Torvalds to succeed.