With most of the world in lockdown due to Coronavirus (COVID-19), most organizations switched to running online events. IBM Developer SF team has been running online events for almost two years so the switch to online-only was simple for us. I shared before how online events allow you to scale.
Not everyone can or wants to run online events. You might be in a place where internet connection doesn’t permit to produce live high-quality events. You simply might not be comfortable doing live events. And that’s fine. The good news – there are other things you can do.
Content (articles, blogs, tutorials, videos) is one of the best ways to scale developer relations. Content can be accessed by developers anywhere and anytime. High-quality content can be your evergreen content – that is content that doesn’t go out of date.
One thing that’s not always easy is coming up with content ideas or what to write about. Here is one way to come up with interesting content ideas.
Peak at what other people are publishing (also called borrowing brilliance). There is probably disproportionately more content written about using various Amazon AWS services than any other cloud provider. You can see what tutorials, articles and how-to’s were published and borrow some ideas.
For example, a lot of content on Serverless is based on using AWS Lambda. Take a tutorial that uses AWS Lambda and write a similar one that solves a similar problem using Azure Functions, IBM Cloud Functions or Google Cloud Functions.
Hope this little tip helps you publish more content.
Extra credit. You can also look at Stack Overflow. Browse a topic and see if there are any questions you can answer. If yes, you can answer that question in a blog post. Then go back to the question and answer it with a reference to your blog.
Online meetups (webinars, web conferences or webcasts) is one of the best ways to scale Developer Relations. In most companies Developer Relations teams are small, probably under ten people. Even if we look at some of the big companies with hundreds of people in Developer Relations organizations such as IBM, Microsoft, Google, AWS and some others – they cannot be everywhere to host in-person workshops, meetups and attend conferences. You cannot scale with people.
Even if you could send a Developer Advocate to every meetup or conference, there are many more developers who don’t attend meetups or conferences. There are many reasons, maybe they leave in an area where there are no meetups or they don’t have a travel budget. You need to reach these developers and also scale.
Reach developers anywhere
As online meetups happen online using software such as Zoom, Webex, Hangouts Meet or Crowdcast (we use Crowdcast), developers from anywhere in the world can participate. Developers from places that you would never reach other wise can join your event and get high-quality developer education. Here is a map from one of our recent online meetups Deep Learning Master Class I – Introduction:
People joined from all over the world. We would not be able to reach these folks with in-person events. We simply don’t have enough people and time to do that.
The meetup started with Nicki Stone, Technical Evangelist from AWS and Matt Auerbach, Developer Advocate from Twitch sharing their experiences and best practices on streaming and live coding using Twitch. In the second talk, Potch, Developer Evangelist from Glide shared his experience with live coding.
How to measure success in Developer Relations is one of the most discussed (or debated) topics. Having been in Developer Relations for a good number of years I believe it’s important we measure it. Without measuring we don’t know what to improve, what works and what doesn’t work.
Now, I don’t believe there is one way to measure Developer Relations. Every company with a Developer Relations organization or a team will measure its success differently. The same way companies approach success in general, every company has its own unique ways to measure success.
Instead of telling you how to measure success, I’d like to offer a framework. The framework can be adjusted for a company’s specific goal and needs. The framework consists of three parts:
I learned a lot about Developer Relations in 2019 and in the process I have been sharing my experience here. The following is a collection of articles I published in the past year. I hope some of the content is valuable and helps you build and grow your program. I of course continue to learn. I’d love to hear what you think and what other topics I should cover.
When people ask me what I do, I tell them I’m in Developer Advocacy/Relations space. Most people look at me confused and say: what? Even folks who are in a software space usually don’t know what this role is.