In a Post Developer Relations World: Fix or Fire?

In “Developer Relations: A Painful Reckoning“, I laid out the current broken state of developer relations and it got people fired up. Some called me an “instigator” (fact check: true), others a “doomer” (okay but not productive), some said I was wrong (without feedback), and a few offered a thoughtful counter. Luckily, for everyone who put their fingers in their ears shouting “nuh uh!”, twice as many asked:

So what should DevRel look like?

To those people: Thank you. Now that we agree on the problem, let’s explore some fixes. It’d be nice if there was a single, clear cut answer, it depends on your organization, your goals, and the people you have. Before we try to define what DevRel should be, let’s lay out our options and what it’s not.

Proposal: Eliminate DevRel

Unfortunately, firing DevRel appears to be the most common approach at the moment. On the surface, it makes sense. They’re expensive and since there are fewer events, one of their single biggest value props is gone. If you just want someone to write some blog posts and creative tutorials, there are cheaper ways and – if you hire people from your target markets, frameworks, etc – you can probably get audience and distribution in the deal.

That said, please don’t fire DevRel. If they’re any good, they know your product, your ecosystem, your use cases, some of your customers, and have credibility in your target communities. More importantly, some portion of the credibility you have is transitive from their own. If you fire them, those communities will feel some level of betrayal.

If you want to keep the people – but not the function – of DevRel, you have to figure out how to leverage their strengths.

But DevRel is not Sales

Sales teams live and die by the dollar (or your currency of choice). Most DevRel people – myself included – couldn’t close a deal to save their lives. While we’re great at starting and building relationships, navigating org charts, identifying decision makers, and pushing along a deal are a more active and assertive skills that we just don’t have the experience.

And DevRel is not Engineering

Building cool demos and talking about them is DevRel’s super power. In fact, there’s almost nothing we can do better. The problem is that this skill only gives us a surface level understanding of most of our art while engineers have to go deep into their tools, frameworks, and the problem statement to be effective. Unfortunately, we usually don’t have the time or need to have that level of skill so most don’t.

DevRel isn’t Product Management either

Most DevRel people I talk to want to move into Product and that gets interesting. From our relationship building, we can be great with customers. With our ability to demo, we can evaluate and dive into topics quickly. With our writing and storytelling skills, we can write user stories. With some technical depth, we can extend those user stories into specifications. This feels like a great fit.

Where it falls down is that our metrics and motivations are completely different. Where we used to be evaluated by presentations, webinars, blog posts, demos, community contributions, and potentially how they lead to product signups, almost none of those things matter to Product. Instead, we have to think about product adoption, use cases addressed, and maybe signups. It’s disorienting in the best of times.

Disclosure: When I left Twilio, I tried PM at Clarify. Despite having deep technical expertise in what we were doing and why, I struggled to shift my mindset and get aligned with what I should be doing vs what I was good at. You may be able to do it better but don’t step into it blindly.

But DevRel is Product Marketing

Product Marketing is a whole other beast. At its most fundamental level, Product Marketing is learning about your customers, being able to describe their problems, understanding how your product solves those problems, and how to get your product in front of those customers. The entire realm of Product Marketing is bigger – Ed Sawma has one of the best explanations – but it boils down to 18 areas:

No one will be able to cover every single item on their own but DevRel can shine by leveraging their skills:

• building relationships with customers to talk about their challenges
• telling stories with language that is descriptive for customers and their industry
• talking technical details and sketching out ideas, solutions, and building compelling demos
• writing guides, blog posts, competitive briefs, and thought leadership pieces about your product, the space, and how it comes together.

Of all the places where DevRel can go, Product Marketing is the cleanest match where you can leverage your existing skills and have metrics that are similar enough to feel natural.

Disclosure: After leaving Clarify, I joined Okta on the Product Marketing team. Initially, it felt odd getting back into DevRel-like activities but it quickly turned into an amazing experience. More importantly, I had the opportunity to work with great Product Managers to witness what excellence in that role could be.

DevRel still needs to Make Sense

Regardless of where you put DevRel, remember who you hired and why. They have specific strengths – writing, presenting, language mastery, community credibility – and if your team isn’t leveraging them, you’ve lost some of your best capabilities.

Product Marketing is the unique place in your organization that maps almost 1:1 with DevRel’s skills, knowledge, abilities, and metrics and – more importantly – it is a natural transition for the people in the role. You’re not asking them to think about the world in completely different way. You’re asking them to apply their skills at a different scale across the entire organization and ecosystem.