I love doing webinars and hearing from attendees in the Q&A part of the event. It’s also great to receive emails after the webinar ends. During the webinar I can give quick answers for the questions and point attendees to additional sources of information. After the webinar I can do additional thinking and research to provide a more expansive response. Last week during my “Developer Relations Best Practices and Tools of the Trade” webinar, I was asked a wonderful question. The question was “If my resources are limited, what priorities should I focus on?”

Limited Resources? Activities that Won’t Take Long

When you have a small developer relations staff and/or budget you should look for the things you can do to communicate and grow your developer membership program. Here are some of my thoughts about the content and activities that you should consider.

1. Write short blog posts with technology/product tips, tricks and how to(s). These don’t cost money and if you keep them short, you won’t have to spend a lot of time.
2. Tweet news/tips to your developers and to the developer community
3. Use Facebook Live/Video to put up short videos where you talk about your products/services/APIs – use your smartphone and just be yourself every day. Developers will love hearing from you, seeing you and also seeing something you are doing – showing a product/demo/solution quickly.
4. Have your community members also share their videos, articles, tips/tricks – give them points/discounts if they help you with content.
5. Automate as much as you can with programming/systems/tools – very important when you don’t have a large staff – that’s why I use Buffer for my Social media with the plugins it has for Chrome/FireFox/etc browsers -when I see an interesting article or finish a blog post – I can quickly post it everywhere.
6. Build automated response systems for questions and emails coming from developers – this might take a little more work/development – to use Machine Leaning, Deep Learning and Bot technologies to handle the volume of email and forum posts from developers and give them answers and tips – leaving your team time to handle the tough inquiries.
7. Provide bug tracking and workaround infrastructure – Atlassian Jira for example, allow your members to post bugs, post workarounds, post proposed fixes – they will help share the load to get better quality into your product/service.
8. Allow your community members to add comments/content to your online documentation/wiki. Some worry about polluting the documentation – so you may set up the system (something like MediaWiki for example) to allow proposed comments/edits/additions/code/fixes and have someone review before including – make sure to have the member assure you that they are giving you the content and that they haven’t copied if from copyrighted materials (via the submission form).
9. When you think you have automated as much as possible – then look at those things that are left and try to automate them as well.
10. Create an MVP (Most Valuable Professionals), Community Leaders team to extend the # of devrel team members you have. Intel has their black belt members, Microsoft has their MVP program, Google has advocates, etc.
11. When your engineering team is too busy to help, find ways to make it easy for them to help. For example, when I am doing webinars or technical sessions, rather than have the engineers prepare their own presentations, I would buy them lunch (they have to eat) and record a conversation with them and use it in the session or transcribe it into a document/slide deck.
12. Have programming contests by your members to build apps using your products/services – give electronic based prizes – you’ll get more sample apps built or at least you’ll have apps stories to write about if members don’t want to give you their apps.
13. Engage students/interns to help you – they don’t cost much (sometimes $zero if they get school/college credit) and can help with some of the work you need to get done and they also gain experience working with a company, it’s products/services/APIs.
14. Interview your customers to create case studies and success stories. Record the interview and provide it for members. Transcribe the conversations to create documents for your developer/product web site – programmers talking to programmers about what they built, how they built it, what they learned, what more they want to do.

Top 3 Priorities to Focus On

I could say that you should do all of the above and more. But, if pressed to list three top priorities for content to generate for your developer community, here is my list.

1. Content – tutorials, quick guides, How To(s), Sample code – “Content is King!”. Ask tyour engineering team to help.
2. News – keep them up to date on product, API and company news – email newsletters once or twice a month.
3. Videos – short (3-5 minutes) created by you, your team, engineers and leading community members.

Other Ideas and Priorities?

If your Developer Relations program, team and budget are limited, do you have additional advice? Send me an email and I will share them with our DevRelate community of Developer Relations professionals.

David Intersimone “David I”
Vice President of Developer Communities
Evans Data Corporation
davidi@evansdata.com
Blog: https://www.devrelate.com/blog/
Skype: davidi99
Twitter: @davidi99
LinkedIn: https://www.linkedin.com/in/davidi99/