Intro

We’re in a very interesting time, to the say the least. We’re adjusting to coming out of the heavy isolation of COVID, mixed with the early parts of a recession, and other macro-economic conditions causing some of the most aggressive layoff cycles in quite a long time across tech. It’s a lot. Once again, we’re looking at a shift in the way we work.

While this IS true, the writing has been on the wall that Developer Relations has been shifting for a bit longer - in fact, we’re well into The Next Age of DevRel. The role has fundamentally shifted. A tongue in cheek example - even the name itself really isn’t valid anymore. No shade intended, but how many of teams actually “advocate” exclusively for the traditional developer audience? The role has extended outward to include the wider range of users of tooling or platforms, this includes groups like DevOps teams, Platform teams, SRE’s, Product Managers and much more. At HashiCorp we used the phrase “Practitioners”, which I’ve always loved. At LaunchDarkly we’ve started to ground around the idea of “Builders” which I don’t hate either.

Another great example is the role of events in the DevRel space. I remember early days of DevRel where a core focus was presence in the meetup space and conference community, generating awareness. With the changes to conferences in general (more on that later…), do events scale in the same way they used to? Are “Builders” attending in the same way they did before? Are we presenting content in a vendor echo chamber? These are good questions to ask ourselves as we look at the next chapter.

I’ve had the pleasure of looking after Developer Relations at LaunchDarkly for just under a year now (May 1st is coming up fast!). I came into the role with some unique perspectives. My 2c, Developer Relations is wider than just an individual role (i.e. solely Developer Advocates). It’s a collection of individuals focused on supporting the “User” journey in some way (often in many ways!). This is why I wanted to bring Technical Marketing into the fold (as just one example). I also believe the role does it’s best work staying close to sales teams (staying close to the concerns/problems that are happening in real-life scenarios). Staying close to content syndication, search (SEO), enablement, and many other core roles.

A couple of caveats before we kick into gear:

• These are strictly my perspectives and observations from my lens. The great thing about community is that we all bring different perspectives together, and being able to talk about them is what makes communities great.
• I’m not pitching something new, or that I’m the only one to have these ideas by any means.
• I’m sure there are DevRel teams who are leaning into these concepts already, and probably have been for quite some time in many cases.

The point of this article is to jot down a few thoughts on emerging behaviors around these shifts, and maybe generate some conversation around the ways the role is changing, and give some suggestions I have on leaning into the curve.

Experts in the Builder Journey

The “modern” (I really do hate that phrase, but here we are) Developer Relations member is an expert in understanding the journey a “Builder” goes through within their product. What does this look like in practice? I think of centered around truly understanding the “Path to I Win”, and the “Path to Friction”

• Path to “I Win” - What are the successful moments in the product that you want your users to hit as fast as possible? How are users guided to that, and once they arrive at it, how do they execute on it successfully?
• Path to “Friction” - Friction exists regardless of how optimized your product is. What are the rough edges of your product? The high complexity moments where builders are most likely to stumble? What are ways you can mitigate this friction?

Non-product sponsored plug here - I love Amplitude as a way to dig into these points. When setup right - pulling together queries around both of these is super easy. More on that another time.

Great DevRel teams look at these two paths and understand how they can influence them. Effective feedback loops look at how to elevate “I Win” moments, and providing tangible data on the friction points and their possible resolution paths. I can guarantee you that your product and design teams want to know this information, and they want it with real user data when possible.

I absolutely think that top tier DevRel teams have a well established feedback loop with product/engineering teams, with the hope of driving enhancements/corrections - but often times content curation ends up being a great way to short circuit these solutions. Developing in-product solutions takes much more time in many cases, and you can advocate for your audience by building content that smooths this out too!

Become the expert for the user journey with your product, whether those users are developers, SREs, DevOps teams, product managers, or everything in between. Resist the urge to build based solely on your own perspectives. The closer you can stay to optimizing your user journey, the better adoption you will have. Easy as that. As we look at the current times where people are exploring products more independently, and purchases are being scrutinized more - solving for “I Win” and “Friction” has massive and far reaching benefits.

As your expertise grows - shift your focus into looking at ways to lower the barrier to your product. Be the person that enables growth through things like content (see more later on in this post), click-through demos, and use your knowledge of the “Builder Journey” to collaborate closely with your Product Marketing teams on messaging.

Accelerating the Path to “Do a Thing”

A theme I’m going to continue to talk about throughout this article is the idea that our user communities have moved into a phase where they are evaluating in a more hands on approach than ever before. In this scenario, it becomes so much more critical to be the on curating the path forward - in many cases, DevRel should be shifting into the seat of being prescriptive around the thing we want our user communities to do inside of our product - and giving them the content/knowledge to be able to do it.

What does this look like? There’s so many options now for teams to be able to run code without having to spin up infrastructure to do it. Platforms like Netlify and Vercel offer extremely mature platforms for running applications and edge functions. Platforms like Railway give flexibility to run entire stacks. Tooling like Supabase exists for everything from databases to functions to authentication. Cloud based IDE’s like Gitpod and Replit exist to edit and run code right in browser. GitHub has it built-in!

I know this previous section seems like an ad for all the great developer tools of the now. My point is, in “the times before”, art of the possible was totally acceptable - but tooling has matured enough at this point to where we can give our practitioners a path forward to execute on. People don’t want the art of the possible. They want a tangible path to “doing a thing”.

We can give code samples, we can give ready made sample applications, we can build content that gives them a path to achieve the “I win” moments, we can share demo code.

Optimizing for the “Next” Interaction

I have this question I use with my team often when we build some form of content - “What’s the thing you want them to do next?”

In general, I like the idea of curating a path for users. Is getting them into a trial enough? Wouldn’t you rather hit the first milestone? In marketing, the idea of the “CTA” (call to action) is talked about often as a next interaction - but just like in the scenario I discussed above, theres an evolved version of this. The original version of this article focused on the concept of “The Marketing Funnel”, or the path that users are guided through as a company tries to convert them into an actual qualified lead. Thats a very different conversation for another day; DevRel tends to stay pretty close to “Top of Funnel” in many examples. As the DevRel space shifts, theres incredible value for DevRels who are looking to help construct the path a user takes throughout that funnel. They optimize for “Next” interaction.

What’s driving this shift now? My take, its a couple of things. The skill bar has risen drastically within the user audience overall. User’s want to explore products on their own terms, and with the isolation of the past few years - they have had the time to do it. Tooling has improved to a point where adoptions is far less complicated than it once was (this is an over-generalized statement). On top of that, information is highly available now (more on that in video content later, and the shift in community later). Users have a baseline expectation that they can explore content on their own, learn about it, and make their decision independently.

I approach content interactions through the investment lens. Every moment your user spends with your content represents an investment on their part. If your content is “low value” (i.e. very surface level, not technically deep, doesn’t answer concerns or questions they have, or my favorite term of all - “is too fluffy”) - the user bails from your content (see bounce rate as an example). Your content didn’t warrant any more of their investment.

The best DevRel’s I know have influence at each stage of that funnel because they are charting a course for users throughout that funnel. They recognize this investment mindset, and actively look at ways to make sure the “next” interaction continues to build relevance in their product. They enable the users to take an independent path to reach the “I win” moment from a content lens. They curate the next steps for users, and they put big ol’ signs in front of the holes or places where dragons live.

If we’re not optimizing for next interaction, we need to be confident that the user is going to find that optimal next interaction on their own - and if that ends in a friction point - we need to be ok with that too. You see see where I’m going with this?

The Rise of Video and The Different Way’s People Learn

People learn in very different ways. It used to be that the hallmark of a great DevRel was an active blog. Some of my favorite DevRel leaders are still churning out extremely effective and insightful content on their blogs. Every single one of them would agree that video is quickly rising in importance from a content delivery standpoint. More important than the medium however is the idea that people consume content in very different ways now than they have historically. You might have heard about the call-out that YouTube is the 2nd most popular search engine. This phrase has since been debunked with data indicating its more likely that YouTube is the 3rd largest however the statistic is still a fantastic datapoint to the popularity.

Technology as a whole has largely shifted to remote work, with a few exceptions in the space. The ability for individuals to keep YouTube up and learn visually while they work on tasks is a normal activity now. For better or worse - this was a bit harder to do in “the office”. Personally, I turn to YouTube an equal amount to searching for solutions on other search engines. Outside of YouTube, platforms like Udemy, or even egghead.io have tremendous following behind them. Live streaming is a common occurrence creating a method of both “live” engagement, as well as a content item to be discovered later.

In this age in DevRel, it’s not enough to just do the blog, or just do the conference talk. The evolved version looks like a combination of these tasks where we’re taking a topic we’ve learned and using it to create multiple pieces of content, and using those to chart the path I outlined in the previous section. Bonus points if you can tie it back to the “Friction points” and “I Win” moments from the section above.

The video + blog combo is a great way to maximize the way people consume your content. More bonus point if you can create a 2-3 minute internal enablement video that teaches your revenue teams or outreach teams how to use that content in a conversation. These behaviors create scale - and extend your reach both within an organization and outside an organization.

Expanding beyond the video + blog combo - many customers want the full-blown hands on experience. Taking the content you’re creating, and producing replicable demo code from it that can be shared is really taking this concept to the next level. Pro-tip - I’ve been advocating for my team creating a GitHub repo for every conference talk/webinar/live stream they do, storing the demo code in it, and including a QR code in their slide materials to take users to the repo. The link can be included in the text of video content, and reused in blog content as well. Scalable content is unicorn stuff.

The Role of Community is Expanding

When COVID hit, the role of in-person events changed drastically. I remember in the mid-point of the lockdowns having a conversation with a few people on the “user” side of a technology community I was a part of where we were reflecting on how AVAILABLE product content was “now”. Before COVID, many of these events were “pay to attend”. As teams lost the ability to capture audiences in person, virtual events became an easier way to engage and build product demand.

I think we can all agree that these went over the top - and as in-person events slowly begin to come back, we’re seeing the virtual side of things normalize. That being said - significant amounts of users are still uncomfortable returning to in-person events. On top of that, an even greater amount of your user community will never actually attend an in person event (the Dark Matter Developer concept coined by Scott Hanselman) - whether that’s because of budget reasons or just purely the conference/meetup scene not being their thing.

What am I getting at here? The road-warrior style of DevRel may not (in some cases) be the best (scalable) approach anymore. Are the events we’re attending really full of our customers, or are they largely other vendors who are at that event also speaking? It’s a good question to ask. That being said, what does have scalable value is creating areas where people can come together to learn from each other, grow, and become advocates/champions on their own. These interactions can be reinforced at in-person events, but curating a community that allows users to participate from anywhere gives you a method of creating consistent interaction, far beyond that first “meet”. It’s another angle on the Optimizing for Next point I made earlier in this discussion.

Organizations that lean in on community are finding a new method of creating interaction with their user base. Authentic community activities tend to create a more loyal user base. One of my favorite examples of this is the VMware community overall. When you look at what VMware did with its VMware User Group (VMUG) community, the Code community, as well as the vExpert program - individuals from all walks of life we’re able to participate and be rewarded.

These activities enables users to learn the products from other users who evangelized the products - creating an incredible scale for word of mouth. In turn, these users came together at events to interact and learn from each other - and created an entire event sub-genre of their own through community driven events and conferences.

Closer to the world I currently work in, another example is looking at what Vercel has done with the NextJS and Svelte communities and their presence. Have you taken a look recently at the engagement numbers of someone like Lee Robinson, Hassan El Mghari, or Steph Dietz? These individuals actively participate in the social community of Vercel, building demonstrable content, engaging with people who are having issues, and widening the circle of their own community by helping users be genuinely not just successful with Vercel - but frameworks and other development efforts. I could write an entire blog post on these 3’s interactions within the community as great examples of leaning in on the new ways people are building and consuming content. Vercel is a better company with them in these roles.

Closer to the Revenue

This one is a bit of a spicier take; and I hinted about it at the beginning of the article. I truly believe DevRel shines the brightest when it’s helping revenue teams create more authentic and scalable interactions. I’ve seen the wide spectrum of DevRel teams during my time in technology. I’ve seen DevRel teams who operate completely independent of revenue stream (“My job is advocate for usage of the tool, even at the cost of a sale” was a phrase I heard MULTIPLE times.), and I’ve seen purely Technical Product Marketing teams who carry revenue targets like their Product Marketing peers. Like most things, the optimal path live somewhere in the middle.

I wrote earlier about the idea that customers are far more enabled than ever at this point. They have the ability to self-evaluate products in many cases. They will explore, and with the vast wealth of information at their disposal - they likely don’t need you to take them through the use cases on the first call.

This leads to a much more “hands-on” sales experience. It’s not enough to be an expert at deal desk anymore. Ground floor Account Executives are having value-based technical conversations. Yes, it’s possible to have a technical conversation that illustrates the buyer-value of your product.

Be the DevRel who gives account based tech talks. Create the demo content that help shorten sales cycles. Be the best friend to sales. In this era of DevRel, the sales teams are going to be your fastest source to knowledge about problems in your user community, and the more indispensable you are to sales teams - the safer your role will be overall.

A Brave New World…

I’ll wrap up this again by iterating what I said earlier on -

• These are strictly my perspectives and observations from my lens. The great thing about community is that we all bring different perspectives together, and being able to talk about them is what makes communities great.
• I’m not pitching something new, or that I’m the only one to have these ideas by any means.
• I’m sure there are DevRel teams who are leaning into these concepts already, and probably have been for quite some time in many cases.

Much like DevOps transformed the way traditional operations teams operate, Developer Relations can evolve too. The idea of Platform Relations, or Builder Relations isn’t that far off. The spiciest take of all is that in reality - we’re all some form of marketing, even if we don’t want to admit it. Just like we’re all a part of sales at the end of the day, assuming of course you work for a vendor. Assuming you don’t… can I have a few moments to talk to you about LaunchDarkly? Thats a joke. Kind of.