Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
The DevRel collective is a community where people in the developer relations field can chat and help each other out. But this post isn’t about that group… We’ll get to that. This is an article about you: the startup founder or manager who’s trying to hire your first developer relations person. This article is here to help you by example.
I’m not the first to write about this problem. Taylor Barnett wrote a great piece on this as well. Be sure to check it out!
When many set out to build a developer program they think first and foremost of the benefits that come from having developers actively participating in their community: supporting other developers in your forums, writing blog articles, hosting meetups and hackathons, helping with documentation, and contributing to open-source projects. The developers who grow into these roles are your advocates, and they bring to our developer programs what we all hope to achieve: scale.
A common miscalculation is an assumption that these outcomes will happen naturally. And while some products and platforms are better situated to achieve these outcomes more organically, the vast majority of platforms need to be much more intentional and conscientious in the creation of their advocacy engine.
With the recent downturn on public stock markets due to COVID-19, a recession or depression is almost inevitable. It’s likely we see mass failures across retail, travel, entertainment, and other industry sectors. The spillover from coronavirus disease and the following shelter-in-place can have drastic consequences in the startup world. Small brick and mortar businesses that were shuttered due to shelter-in-place rules will no longer are spending money on Facebook or Yelp to promote their business nor will they maintain their SaaS subscriptions. Large enterprises will pull back spending in sales and marketing in anticipation of a recession. This could cause reduction in seat counts or usage for SaaS contract.s Similarly, sales teams may find CFOs and financial controllers are blocking many more purchases than before forcing deals to be stuck in procurement or legal review.
The good news is that many developer platforms and APIs have tricks that make them more resilient to a recession. However, if you’re not doing these items today, now is the time to reconsider to ensure the longevity of your product and/pr company.
Developer Relations is not simply a role or department at API-first companies. Developer relations is a mindset of getting developers adopt a platform and making them successful with their initiatives rather than attempting to sell to those developers. This makes developer relations different from traditional sales and marketing roles. However, if you ask “What is Developer Relations?”, you may get many ambiguous responses as developer relations is a catch all phrase for a variety of different roles and titles. Some titles include “Developer Advocate” and Developer Evangelist”, but can also include other newer titles like “Developer Experience Manager.”These roles vary company to company and even across teams within a company.
This post outlines some of the different roles within devrel, such as:
Each developer relations program has a different opinion on what should be north star metrics to measure the success of their platform. Some metrics are valid while others can be what are called vanity metrics. This post discusses which metrics you should or should not be tracking.
The goal of developer relations is to ensure third-party developers are able to leverage your platform to create something of value. Value can be subjective, but some examples include shipping a new integration or plugin that increases the usability of your products or integrating your APIs and SDKs into their web or mobile apps to deliver a better experience for their customers.
I've worked with Developer Relations for many years now, and I think it's a fascinating topic with many takes on what it is and how to do it! I wanted to share my view on it here, and what I think it encompasses.
Last year I gave a presentation called "Have you tried listening?" at the DevRel Summit which I think outlines a number of the main DevRel concepts and areas, and examples from my personal experiences with them.
After more than four years at Google, I'm now a Developer Advocate! "Wait, I thought you already were that?" is the most common reaction. Allow me to tell my story.
Google recruiters had reached out to me over the years, and in August 2014 — if my memory serves me right — they queried about my interest in becoming a Developer Advocate for the Web at Google. I expressed my interest and we started Google's detailed and granular assessment and hiring process. In my first call with HR, though, they informed me that this role was full-time in London. Not having an interest, nor possibility, to move to London, I said that I couldn't relocate but I would be happy to travel there every second week and work there then. I was met with "Unfortunately that's not going to work out; you have to be based in the London office full-time."
In the context of developer relations, a Lunch & Learn event is a lunchtime developer education event. It's very similar to an evening meetup, but hosted during the lunch hour. While a meetup can have different formats (hands-on, lecture, panel, etc.), this particular event has a lecture-style format. Developers come to the event, get to eat a delicious lunch, learn something new, ask questions, and network.
So now the question is — why run an event during the lunch hour? I'm going to share why a Lunch & Learn can add value to your developer relations program. I want to mention this is not to run instead of evening events, but in addition to evening events.
I thought about writing a post on juggling work commitments, travel with my job, and time at home with children and family. And then I came across this post from community friend Robin Moffatt:
https://rmoff.net/2019/02/08/travelling-for-work-with-kids-at-home/
My first blockwatch of 2019 is an interview from late 2018 with Rachel Black of Lisk (@RachBLondon), in which we discuss the company, what's coming up and the importance of developer relations/tech evangelism in the blockchain space.
If you like what you read, listen to the full interview with Rachel below as it contains lots more Lisk titbits and pearls of wisdom.
A big part of many developer advocacy programs is content. Content can be in the form of tutorials, blog posts, videos, and hands-on workshops and other forms. Coming up with content ideas is not always easy. In this blog post, I'm going to share some ideas how to simplify content creation.
The IBM Developer SF team hosts weekly events. We host at least one in-person event and one online event (webinar/online meetup). For every in-person workshop, we host an online event. It's usually best to host the online event after the in-person event, as people who couldn't make the in-person event can watch the online version (but the other way is also fine). The in-person event is about two hours and the online event is usually 40 minutes. So yes, the content covered will be different, but the basis will be the same. This is the first example where doing a hands-on workshop easily creates content for an online event. The in-person event doesn't necessarily need to be a meetup/workshop-type event. It can also be a conference talk, a panel, or a Q&A. It can really be anything.