Welcome to the first DevRel Weekly issue of 2019! Here's hoping you had a restful holiday season and are geared up and ready to hit the ground running again. I'm equal parts excited about the potential that the new year holds and still in denial that we're in 2019. 😅
I'm not a big believer in resolutions. Like K. Rain Leander, I believe in doing all the things right now rather than waiting for the perfect time to start something. It's simply what works better for me! YMMV, of course 😊 That being said, I am a big believer in recognizing milestones and reflecting on lessons learned, and 2018 had a lot of those.
Consider this issue a "Welcome Back!" as well as a chance to recap some of 2018's best-written tweets and articles about DevRel -- highlights from the year as well as some of the timeless things we should always remember. We'll also take a quick glimpse into what 2019 might bring. Grab your drink of choice, pull up a chair, and start exploring.
One from the Archives 📰
What IS DevRel?
This was a popular topic in 2018, getting hashed out and rehashed in both positive and negative ways on Twitter, at conferences, and in blogposts. While the conversations grew tedious at times, there was also a fair amount of growing pains, which is understandable given that many of us think we've entered the "teenage years" of DevRel, resulting in identity crises and a renewed desire to figure out who we are.
These four pieces did a great job distilling the definition and value of DevRel, as well as what makes us unique.
This post from Emily Freeman delves into some of the negativity that's been surrounding DevRel on Twitter lately, but also puts a stake in the ground around what DevRel is and why it's so important in the overall tech industry. On a personal note, it sums up why I quit a secure job & started doing DevRel consulting. Not because it’s lucrative. Not because I want to be famous. But because we need more resources & more people working to better convey the valuable work that DevRel professionals strive to do.
At the core of the "Rel" in #DevRel is this... Building relationships with developers requires, as a core tenant, the mantra "Developers don't care that you know, until they know you care."
🔑 keys for building community:
- Consistency - keep creating even if no one responds
- Experimentation - try new things, don't stagnate
- Humility - it's not about you; it's about the whole
- Transparency - be honest and admit mistakes
- Energy - keep it high; keep it positive
We started off 2018 with this fantastic post from Ashley McNamara which has been mentioned numerous times since then, but it still holds up despite the controversies from this year. In it, she covers the role of Developer Advocate as well as an overview of the value that the Developer Relations industry brings to the table.
No Single Recipe, but a Common Goal
One of the most difficult things about DevRel is the fact that how you approach it -- whether the focus is on content, event sponsorships, sample applications, or 1:1 conversations -- is largely dependent on your particular technical community and their needs. 2018 brought us many "how to" articles, their intention being to help DevRel professionals improve particular skills or reach their audience in a more effective manner. But as Jono Bacon said a few weeks ago,
There is no single "recipe" to build community growth. It needs an initial ignition (the launch), and then consistent amplification via content, campaigns, social, advertising, and other methods. This needs to be planned and resourced, informed by metrics about what "sticks".
So how do you figure out what works? By asking questions.
In the Fall of 2018, CMX Hub published a fantastic piece on The 7 P's of Community, giving you questions to ask and things to consider when building a community. The questions they pose are similar to the ones I walk through with my own clients:
- What do you hope to get out of this community?
- What's in it for the community members?
- Why is this important to your business?
and perhaps the most important: What does success look like?
Questions like these help you figure out how to best serve your community and your company simultaneously, bringing value to both.
After all, that's the point, right? We're the bridge between our technical communities and the company we work for. As the ones who are most involved in the day-to-day lives of people who use our products, it's our responsibility to communicate their needs back to our co-workers. Likewise, we also need to know the needs of our co-workers in order to be able to connect them with the appropriate community members.
These connections, or "DevRel Qualified Leads", as I like to call them, are essential to establishing our success and value within our business.
Figure out what similarities and differences exist in expectations between community members and your company. You may find both parties want similar outcomes, they just frame and communicate them in different ways.
Above All, Make it Sustainable
Whatever words we use to describe what we do and whatever methods we decide to pursue in 2019, we must do one thing above all: protect ourselves from burnout, making DevRel a sustainable practice.
It's not just travel that plagues us, however, though that is a major factor. We need to make sure we're taking breaks from our jobs, disconnecting from social media when it becomes toxic as it has lately, and creating boundaries so that we're doing the things that only we can do.
This article from Higher Logic goes into more detail about how to prevent burnout for community managers, a topic near and dear to my heart.
I addressed burnout generically in this blogpost from 2017 and went into detail about how burnout specifically relates to DevRel in Chapter 9 of my book. I also plan to release a "Burnout for DevRel Professionals" post in the next few months -- keep an eye out for it in this newsletter!
The moral of the story, as my calendar reminded me the other day, is this:
You cannot give what you do not have, so if you want to help others you have to take care of yourself first. This is why they always tell you on airplanes that you have to put your oxygen mask on first before you help someone else with theirs.