Developer Relations in the COVID era

15 min readJun 9, 2020

Developer Relations is all about helping communities of developers be successful. Presumably, we choose to work in a Developer Relations role for a project, community, product, or company because we believe that the organization we’re affiliated with makes a meaningful contribution and positive impact on the communities we love being a part of.

I’ve spent over 20 years building, advising, and shaping Developer Relations teams for a variety of products at Sun Microsystems, Microsoft, Amazon Web Services, Facebook, Twitter, and numerous startups, including Timescale, my current employer. Over the years, I’ve found that Developer Relations professionals use the same fundamental approaches to bring value to our communities. But, the world of 2020 is unlike anything that we’ve experienced as a global population — and as a Developer Relations community. A lot of things we assumed were true are either no longer true or ripe for reinvention. We’re at a point where adapting these for the times is essential.

In this post, I’ll describe the fundamental tactics I’ve used over the years, as well as how we can (and should!) evolve them to suit the current environment. I’d love to hear more from you on how you and your organizations are meeting this challenge.

What does Developer Relations do?

I organize Developer Relations around four specific areas. That’s not to say that any individual does or does not do all four. It’s more that our roles can be boiled down to these core areas.

Number 1: Capture and represent product feedback.

The core definition of Developer Relations mandates that we spend time with prospective communities or customers to get them excited to try (and adopt) a product, and really good Developer Relations people have a strong idea of how well those prospective customers receive the product. Great Developer Relations teams are expert observers and connectors: they earn the trust of engineering teams by crisply summarizing customer feedback (explicit and implicit) — and then use their solid reputation and credible technical arguments to drive action within their organization.

Number 2: Build credible and authentic content that offers value to technical audiences.

Focus on your docs

Some Developer Relations teams are also responsible for product documentation, which is a very smart and advisable thing, IMO. Your docs should represent the spine of your growth strategy. You may have the most beautiful website, but developers will quickly scan the homepage, search for “Docs” or “Developers” in the top-nav, and click on that.

To the chagrin of many traditional marketers, they’ll bypass whitepapers and opportunities to sign up for a webinar and head straight to your docs. Your docs MUST be informative, entertaining, and comprehensive. If they’re great, your docs can cover up paper cuts in your product. If they’re excellent, your docs can turn a skeptical developer into a fan. You want your docs to spark the imagination of your developers and keep them coming back for more. It’s not just API references and introductions to core concepts. It’s also fun tutorials that fire up the creative impulses of your customers. Simply put, get your docs right.

Fun content beyond docs

Developer Relations teams should also build fun and engaging content that reaches new customers, gets them excited to use a platform, and guides them through specific scenarios. Note the word “guide”: the prospective customer should feel not only a sense of accomplishment with the product but the content shows them how the product will be applicable to their projects or use cases. Often, this content reflects a deep knowledge of the community or types of developers that the product aims to recruit. Kathy Sierra does a great job discussing this concept — and many others — in her book Badass: Making Users Awesome.

Typically, you want a good mix of first-party hosted content (product docs, company blogs, etc.) and third-party content (Twitch live-coding streams, videos on YouTube, non-sponsored articles DZone, Smashing, and so on). Third-party content always includes liberal links back to first-party content (your docs and tutorials). You want to entice and motivate people to learn more and give them the ability to do so, by clicking through to detailed technical guidance. This is a big reason why it’s so important that your docs are stellar: you drive developers to them through everything you do.

For example, when posting on social media, use animated GIFs of your product in action with links to tech docs for developers to explore themselves (this is different from social media advertising, which is pure marketing and where you’d use campaign landing pages).

The false god of paid acquisition

My strong advice is to not jump ahead of yourself and pay for placements before you get your docs and content right. As most traditional marketers learn, developers are inherently skeptical of advertising. Even if you’re a startup, it is a much better use of time and money for your top engineers to author quality content, alongside your Developer Relations team, and earn your way into top publications. Stephanie Morillo has written a fabulous book on content marketing for developers, with advice on how to identify relevant publications and approach the submissions process.

The power of YOU: making your content stand out

At the end of the day, good content is important. Your content must be technical, helpful, and everything we’ve discussed to this point. But breaking through the din of content requires more.

A remote-first culture may or may not become prevalent in our industry, but it’s certainly true that working from home at least part of the time will become more prevalent and acceptable in many organizations. Working from home has many attendant benefits, but it can also be more exhausting. Sitting in front of a screen while lacking a clear dividing line between personal and professional lives yields shortened and short-fused attention spans. As with all things COVID-related, trends we were already seeing have quickly accelerated.

Great content is a reflection of your personal brand. You can do all the SEO and organic discovery tricks in the handbook. But the difference between consistently good and consistently effective content is how often people seek out your opinions and authority. When I look for information on JavaScript, I look to Sarah Drasner first, everyone else second. When I’m curious about Artificial Intelligence or Machine Learning, I start with Paige Bailey or Francesca Lazzeri.

So, my final piece of advice is to think about more than simply producing quality content — establish a quality brand that drives people to actively seek out your opinion.

Number 3: Connect and build relationships with community leaders.

Your goal is to focus on long-term, collaborative, and technically credible activities. In other words, things that will develop over time, involve a good deal of mutually beneficial technical discussion, and be rooted in code.

A lot of what we used to think of as “community engagement” revolved around meetups. Of course, community development is a lot more than buying pizza and giving talks. Spending time with like-minded enthusiasts helped us stay abreast of the latest thinking from community and product leaders, and the latest use cases from developers.

Community engagement in the COVID era is a different beast altogether. Sure, you can meet virtually with the community leaders you know about. But, what about leaders in local or region-specific development communities? How do you even go about discovering who they are (let alone find rising stars) if you can’t attend meetups?

Here are a few ideas:

Partner with your internal engineering team and contribute to open source projects of the community leaders you admire and would like to build relationships with.
Work on starting or supporting a virtual meetup for a mutually interesting community. Most recently, for example, I helped Timescale, a database company, launch a meetup for enthusiasts and caretakers of public datasets. The meetup isn’t about the company’s product, but it appeals to the types of developers who may have use for the company’s product. We do no advertising of our involvement other than running the landing and sign-up page.
Create working specs for future products or services and share them publicly for collaborative feedback. Timescale did this recently for a future feature set that would address the needs of a highly capable engineering community. “Developing and designing in the open” has tremendous benefits for both product design and community development.

Be genuine, authentic friends to your community. Adam Grant wrote wonderfully about this in Give and Take.

As we’ve discussed, the fundamental frame of the Developer Relations role is to engage with communities and get people excited about using your product, service, or project. In a world post-COVID where it’s impossible to hit the road and meet local community leaders, engaging in authentic and unique ways online can attract both the global community leaders you know about and the numerous local community leaders you don’t.

You should never, ever do “fly-by-night” activities or marketing tactics with these folks: don’t ask them to Tweet something for you, don’t ask them for a quote in your press release, don’t ask them to endorse your product in exchange for a fee. These shortsighted approaches are inauthentic and will do far more damage than good. Mary Thengvall wrote an excellent blog post on this topic.

Number 4: Speak at events.

This used to be the most glamorous part of the job, and I always intentionally put it last, even before COVID. After COVID? It’s non-existent. Despite all the fun involved with events, they were always exhausting, always expensive, and always inherently unmeasurable.

I’ve worked at companies big and small, and there’s always a reckoning with management over the cost of events. Whether your management is free-spending “lead acquisition at all costs” or errs on the side of frugality, it doesn’t matter. At the end of the day, justifying the expense of sponsorship, travel and entertainment, and time out of the office was always hard.

If you were running your own event series or tour, you had to account for event logistics (venue, catering, etc.), demand generation (the expense of getting people to attend your events), and content generation (a massive amount of time). Certainly, there were also positives of such events: focusing the entire team on shipping features or products to hit an event date has always been a traditionally great motivator and the opportunity to assemble your developer tribe in one place has always been a traditionally great way to get your internal team and your external fans on the same page. But in the post-COVID era, the positive vs. negative argument is moot.

After COVID, companies have begun the pivot to virtual events. Microsoft and Apple migrated their developer conferences to an all-online modality, and smaller conferences from KubeCon to GrafanaCon and more have done the same.

We are at the beginning of this shift and it’s natural that companies still use tropes from the old approach, including stultifying tech exec keynotes and lengthy breakout sessions.

Moreover, as companies and organizers look to virtual events, we now grapple with “Zoom fatigue,” the very real phenomenon that virtual meetings and collaboration is significantly more exhausting than in-person communication.

It’s time to innovate on the tech conference, and it’s Developer Relations that should lead the way. And hopefully, we can lead in a way that builds in and rewards a more inclusive, kinder, and friendlier approach.

Much will change about how we run events, some obvious, some not so obvious.

Should sessions still be the traditional Netflix-style 45 minutes long, or should we look to a different format with 10–15 minute (or even shorter) sessions?
Can sessions be recorded and incorporate more post-production, so that animation, titles, and other traditional TV-like effects can replace or augment slides and demos in order to build and retain interest?
Can sessions be built as short preludes to written content, tutorials, or self-paced training?
How can we use services like Twitch and Discord to capture the serendipitous hallway conversations that make in-person events great?

One thing is for sure: we can measure (almost) everything now, when we could barely measure anything of consequence before. From the number of unique viewers and average time spent watching to the most popular sections of a talk and so on, we can now capture and use this data to inform the next event, and the next event, and the next event.

In summary, what was once an extraordinarily inefficient aspect of the job can become one of the most efficient. Every crisis is an opportunity.

Measure what matters

Measuring our work is important. Let’s face it: not every company gets the role of Developer Relations. I’m not going to belabor the point, but in all times (but especially lean times) demonstrating your value to the organization has merit. At the same time, measuring what matters gives you room to experiment, improve, and scale your efforts. In fact, I believe so much in measuring what matters, it’s perhaps no surprise I found myself now at Timescale, a company building a time-series database that basically lets you measure everything that matters

Each of the four areas — product feedback, content, community engagement, and events — can be measured. And, just as there are best practices for the tactics themselves, there are some guiding principles and best practices for how we measure each tactic.

Whenever I look to define metrics, I like to start by asking myself what success looks like in each of the four core areas:

Capture and represent customer feedback.

Developer Relations feedback is accepted and considered valid by the product team.
Developer Relations feedback is prioritized by the product team.
Developer Relations feedback is acted upon by the product team.

Build great content.

Developer Relations content reaches lots of new customers.
New customers touched by the content activate the product at a higher rate than the control.
New customers touched by the content consume more of or spend more money on the product than the control.
Existing customers return to our docs

Connect with community leaders. (these are intentionally vague, as I’ll discuss in a moment)

Grow first-time and repeat attendees to virtual meetups
Community leaders welcome developer relations contributions to their open source projects
Community leaders provide feedback on products or services

Speak at and host virtual events.

The speakers who attract the most viewers
The speakers who attract viewers with the longest time spent watching
The sections of each talk that are most interesting

Building measurement tools

One of the things that attracted me to Developer Relations 20 years ago was that it was a great opportunity to exercise the creative aspects of my personality (I was a drama major and a screenwriter when I was younger) with my more mathematical and algorithmic side (I was also a Computer Science major). You are what you choose to measure, as the old axiom goes. And one of the things I would not want to do is subtract the creative aspects of the job. With that in mind, we want to minimize process, maximize insight, and retain creativity.

Measuring feedback

With customer feedback, if your Developer Relations team uses the same task management service as the engineering team (they should!), then you can run queries on their submissions and determine if those submissions meet the criteria for success you’ve defined:

Number of bug reports submitted and accepted
Number of customer feature requests considered

Measuring content

I measure content and event impact in very similar ways — and my approach requires knowledge about basic web measurement techniques: URL query parameters.

What you’re trying to do is append any link to your site (domains you control/own) with a tracking code, so that you see how many people arrived at your site as a result of a given activity, determine which channel is most effective at driving growth and adoption, and invest your time and resources in the highest performing tactics.

It’s important to note that this strategy does not associate visitors with any personally identifiable information — it merely allows you to see anonymous individuals’ traffic and engagement.

In modern times, the best marketing people are quasi-data scientists who run queries to identify which routes to product signup and usage are the best. When Developer Relations does this, it opens up a whole world of nerdy growth hacking, given the loop between content production and measuring efficacy is tightly contained within one person or team in the organization.

You can use any tool to or parameter structure for your tracking codes. The key is to have flexibility so that you can see instances of tactics, not just the tactic itself. In this example, we’ll use the Google UTM format (via Google Campaign URL Builder). The important thing is to adopt a standard, consistent schema, so that you can run queries later to determine the efficacy of general tactics, specific pieces of content, publications, or events, and even specific team members.

As a refresher, Google UTM links consist of three primary fields, and while most frequently used by marketing people, we can easily adapt it for Developer Relations’ purposes.

For each of the three primary fields, I’ve listed a schema I suggest for Developer Relations:

utm_source (the general tactic you’re using): article, newsletter, blog, 3rdpartyevent, 1stpartyevent, twitch, webinar, youtube, github, social, workshop
utm_medium (the specific instance of the tactic you’re using): smashingmagazine, pyconaustralia, and so on.
utm_campaign (the alias of the specific person in your company running this tactic): prashant, billg, zuck, etc. (note: it’s important to use this as a tool to identify areas where content is working, not to stack rank Developer Relations people. Stack ranking creates bad incentives. But a culture of formulating hypothesis, running experiments, and examining results critically is one that brings out the best of everyone on the team and ensures that everyone is working on the most impactful projects.)

Let’s talk for a moment about how content flows to your site. Let’s say you write an article about analyzing public COVID-19 datasets and post it to the DEV community. Within the article, you link to your product documentation. You would append the following UTM parameters:

utm_source: article
utm_medium: dev
utm_campaign: prashant (me, the author)

These parameters allow you to filter visitors based on what led them to your site, and, depending on your website and product analytics tooling, actions they took on your properties. That way, you can look at your signed up users and see which inbound tracking codes may have led them to your site (in, say, the last 90 days). It’s impossible to identify causality in a world where a customer may interact with you in multiple ways before deciding to sign up (so-called “multi-touch attribution”). But you can identify correlation and take note of which tactics are most commonly present in your most recent customer sign-ups (or any customer cohort you define).

Measuring community

In community engagement, our highest priority is authenticity. The second-highest priority is to be helpful. I’m a very firm believer that engaging with community leaders (and others in the communities of importance to you) cannot be driven by a quid pro quo. You can’t expect anything in return. If you show up with an authentic desire to learn and help, you will do your job. If you try to associate the time you spend in the community with sales or other metrics, it can lead you away from an authentic desire to learn and help and instead down a path of self-centered desire to grow your business.

Measuring events

As noted earlier, what was once impossible to measure, can now be much easier to quantify. To start, I’d experiment with a multitude of session types and formats. Events no longer have to be linear and held in 1–3 days (nobody is going to watch 6–10 straight hours of streaming video unless Jason Bateman and Laura Linney are involved). Think about hosting events over an extended period of time, dripping content instead of firehosing it. You’re trying to optimize for repeat viewing, engaged viewing, sharing, and delayed viewing.

YouTube gives you great information on viewership, including the most popular sections of your sessions. Build landing pages for each session and embed the YouTube video so that you can measure it the same way you do content (see above). In your landing pages, you can include additional resources and related content to keep people engaged and drive them to more of your documentation and tutorials.

Pulling it all together

Once you and your team appends tracking codes to all your links inbound to your product or service, you can begin to run queries using your favorite analytics tool. Common questions I like to ask are:

How many new sign-ups is Developer Relations driving overall? What activities are driving the majority?
Are Twitch live-coding streams more effective at driving traffic or net new visitors than webinars?
Which third-party sites are most effective at driving new users?
Which types of content are most effective at driving new users?
Is one person on the team better at events or content?

You’ll definitely want to create a dashboard so that everyone on your team can quickly slice and dice this data to get insights on what is working. One of my core management principles is to eliminate all forms of information asymmetry in an organization. To that end, I’m also a big believer that all dashboards should be shared broadly in an organization, again conveying the value of Developer Relations to everyone.

Summary

For the bulk of my 20+ years in Developer Relations and Developer Marketing, measuring content, events, and community activities has been extraordinarily difficult. Developer Relations has always seemed like an ambiguous role, and I’ve certainly been part of organizations for whom developers were the third- or fourth-most important constituency. Even though my career advice would strongly advise Developer Relations professionals to select organizations that prioritize developers long-term when job-hunting, it’s likely that no matter how much importance your organization places on developers that you’ll need to justify your existence, so to speak.

The danger is that an organization snaps Developer Relations to sales or “funnel” metrics, such as Marketing Qualified Leads (MQLs) or Sales Qualified Leads (SQLs). These metrics are unhealthy for Developer Relations, as they result in dubious tactics that place short-term revenue above long-term community development. However, a concerted effort around measuring what matters will enable you to focus your efforts on building and growing a community around your product and appease executives by demonstrating quantifiable impact.

I believe that the topics I’ve discussed here are applicable to all teams, regardless of size or organizational maturity. I’d love to learn more about how your Developer Relations teams are measuring what matters and demonstrating impact in your organization. You can find me on Twitter @CoolAssPuppy.