Q: “Does building a developer community have to be done by developers?”
I’ve heard this question countless times. This question appears in every community group, and it’s usually raised by people who want to make their mark in the tech industry but don’t have a technical background themselves. They’re unsure whether they can survive in the tech industry.
I haven’t written a single line of code, yet I successfully became Estimote’s community evangelist. We’re a startup focused on mobile developers. Along the way, I learned many lessons that anyone working in community operations would find very practical. We’re all product-centric, rallying more developers. We can not only use these experiences but also discuss and promote them together, continuously making more contributions to enrich the experience. Product-oriented communities are like beehives, where everyone contributes to a common goal. Most of the time, our work focus isn’t actually on the technology itself.
I’m not the only example of someone from a non-technical background. Even companies famous for building developer communities like SendGrid and Twilio have non-developer members in their community teams (hi Tim, hi Lisa!).
Let’s discuss this question again: To build a developer community, do you have to be a developer yourself?
No, But You Need to Learn to Think Like a Developer
Even if you can’t think in code, you should learn to think like a developer.
People in any profession have their own habits, terminology, and special ways of looking at the world. Your task is to create a place where developers feel at home. Of course, every developer has their own characteristics, but the more developers you meet, the more commonalities you’ll discover. They always talk about the same things, like pull requests, forked repos, and API tokens. Yes, you need to learn these things. Don’t make excuses to avoid it.
Many developers are obsessed with efficiency. Their minds are filled with systems, pattern recognition, and detailed analysis of various problems.
Is this description too vague? Yes. Within a certain magnitude, this description is accurate. But if someone tells you they can explain how developers (or designers/journalists/construction workers) think in a few sentences, please don’t believe them.
There are no shortcuts to learning developer mindset. The only way is to have conversations with developers.
Eat with the technical team in your company, attend their meetings, follow new developments in Slack/HipChat channels, and discuss with people responsible for user feedback. You can also seek learning opportunities outside the company, such as attending tech conferences in your city and following hashtags related to your community on Stack Overflow.
Some topics you may completely not understand, like “What’s the most complex C code you’ve ever created?” You actually don’t need to understand these questions too thoroughly. When reading, you just need to watch the details others discuss and find joy in them. These practices can make you a better community operator and technical evangelist.
No, But You Need to Understand the Product
The core of all communities is people. But developer communities have products as their core besides people. Developer communities attract developers together through special tools or purposes. Even if you can’t become an expert at using these tools, you should become an expert at explaining them.
You can read success stories to understand best practices and in what contexts developers will use your tools: if your company hasn’t published this content yet, you can ask the customer success team/business development team/other community operators to share with you. You also need to understand the product’s evolution: check old posts and read product update logs.
Understanding the product and users, you can showcase relevant case studies, answer general questions, and encourage people to contribute to the community by writing their own content. Encouraging others to contribute is the most important point. When community members feel you care about them, they’ll write guides for your tools and organize meetups around your product. If your product is open source, they’ll even help you fix bugs, and they’ll convert to your product’s faith.
How to determine if you understand the company’s SDK and API well enough? One good way is to see if you can tell someone which page in the product documentation they can find the answer when they encounter a problem deploying a certain product feature. This means that even if you can’t use the product yourself, you’ve already become familiar with it and know where the root of the problem lies. Obviously, if you can do this, it’s enough to prove you’re not solving problems by luck. Software keeps changing, especially in this era where everyone emphasizes agility and daily updates. That is, what you learned before will soon become outdated, so you need to keep learning.
Inside Estimote, we established a biweekly “stack review” activity: a short meeting to ensure everyone has learned the latest product release. This meeting takes at most 20 minutes, but it lets us ensure everyone is on the same page.
Because software products change fast, don’t be discouraged when you don’t understand or remember something. Even within a company, developers can’t fully grasp all the details of the product, even if they developed it themselves. There’s nothing to feel inferior about—software products are too complex for one person to memorize a huge codebase. When you encounter problems, you just need to know who to ask.
If your company uses collaboration tools like Confluence or Asana, you should maintain a document with technical details and FAQs for the product.
If your company doesn’t use collaboration tools, you can use Google Doc. Note that someone must be responsible for updating it. Outdated documentation is worse than no documentation.
No, But the Team Needs Developers
In the developer-facing field, any community team must have a developer. Initially, our team didn’t have a full-time developer. This pattern lasted for a while. We maintained a certain level of exposure at events worldwide, continuously improved content, and provided high-quality customer service.
But we soon hit a bottleneck. Our ability to support hackathons was limited. We also felt overwhelmed when writing technical content. Those difficult support requests would drag on for days because the team prioritized shipping issues before troubleshooting. These support requests accounted for 10% of all requests.
After we brought in a code-writing technical evangelist, the entire team became more efficient: customer support, content, events, feedback collection, developer relations, etc. We became more proactive and approachable in the community’s eyes.
Equipping the team with a professionally capable member can exponentially increase the team’s efficiency. If you want your developer community team to go from “good” to “awesome,” you need to equip the team with a developer-turned technical evangelist.
Estimote Community Team (left to right), Wojtek, Witek (team lead), Ula (community manager), Piotr (technical evangelist)
No, But Learning Programming Yourself Isn’t Bad Either
You might think I’m just talking big. After all, I’ve admitted I’ve never written code. Well, we often give advice to others but rarely do it ourselves. So I urge everyone to learn—don’t repeat my mistakes.
It’s very possible that through learning, you won’t become an excellent developer. But you don’t need to become an excellent developer.
You don’t even need to develop products yourself. You learn programming to let you build a developer community and better think like a developer. Even the most basic programming knowledge can greatly help you understand the community and your product’s intent. This is basic knowledge to participate in developer communities.
Besides programming, you can also learn other things. Users of developer-facing products do many other things besides writing code. If you’re like me and just don’t have a good feeling about the Xcode and Android Studio world, you can learn in other areas. Read books on product management, take some UI design courses, learn UX. There are endless things in this world waiting for you to learn. Coursera, Udemy, iTunes U, and tons of blogs provide you with all kinds of wisdom. These are the learning materials you dream of—learn to use them well.
Most importantly: learn knowledge in the field. As long as you broaden your horizons and don’t limit yourself to community building knowledge, learning some other knowledge can make it easier for you to build developer communities. Expanding your knowledge reserve in related fields can make you converse more fluently with community members.
Are There Exceptions?
There are indeed some developer community teams that I initially thought must have quite rich developer experience. Companies like Docker or MongoDB. Their products are very technical. Mentioning them will definitely make you think of technical code, just like mentioning Estimote will definitely make you think of micro-location, mentioning Twilio will definitely make you think of text messages, or mentioning Oculus will definitely make you think of video games.
But after studying their requirements for “community management” positions, I found these positions don’t require applicants to have a technical background. Perhaps this isn’t surprising. If you want to build a developer community, just go do it. You don’t need to be Linus Torvalds to succeed.
Author: Wojtek Borowicz (Wojtek is the community evangelist at Estimote in Krakow, Poland.)
Original: How to Become An Awesome Developer Evangelist When You’re Not a Developer
Reposted from: DevRel Developer Relations—How Non-Developers Can Become Excellent Developer Evangelists
Translator: Lu Xingyun
Reposted from: Developer Relations »
