Developer Relations: A Painful Reckoning

The last four years have been brutal for developer relations.

Obviously, covid sent everyone home and canceled conferences, meetups, and every other event. The underlying framework of hallway conversations, buying drinks for developers, and live in-person demos disappeared. Fast forward to 2021 and every tech company was on a wild hiring binge making crazy offers for engineers while developer relations teams pushed on but struggled. Then we got into 2022 and the world changed with 7 Fed rate hikes making company valuations crater and layoffs began by the end of the year.

(If you’re not sure why the prime rate is important to tech company valuations, look into Net Present Value and figure out cashflows or read swyx’s post: DevRel’s Death as Zero Interest Rate Phenomenon.)

But you didn’t come here for a recap but for some analysis and here it goes:

Developer Relations is dying because devrel failed their organizations.

I’ll unpack that statement into three categories:

Marketing doesn’t need DevRel

First, marketing has become developer savvy. When I started as a Developer Evangelist at Twilio in 2011 (recapped here), you could name every clueful marketing leader in the industry on one hand. They knew developers hated traditional marketing and that whitepapers, webinars, and big budget ad campaigns were a waste. They understood you needed to provide value through code, conversations, and community. In 2024, every company understands that. They don’t need DevRel to convince them.

Then DevRel chose terrible metrics. At some point, DevRel people decided they were immeasurable. After being called on that bs, they relented to accepting a key metric of conference speaking slots. That might work with some requirements but there were none. Many DevRel people started making their name with non-technical and non-dayjob-related topics. Therefore, your technical deep dive into your problem space and your colleague’s talk on [imposter syndrome, mental health, finding your place in tech] counted exactly the same. When your company is paying the bills, your job is to build their brand, not yours. But more to the point: If Marketing can’t measure your contribution, you don’t fit into their budget.

The Company doesn’t need DevRel

Then DevRel pissed off the rest of the team. Every organization has engineers who asked to go to a conference and were told “no” for various reasons. And after heard “no” for the one conference they requested that year, the DevRel team posted pictures from their 5th conference this year from some cool place.. and in that picture were the core devs from that engineer’s favorite framework that they use daily and that streamer/blogger they’ve followed forever. Yes, this is jealousy but when your job depends on credibility and relationships, this is damaging.

DevRel people aren’t developers. In ancient times, devrel were “developer evangelists” and had years experience as a developer. They had (emotional) bruises from shipping code and making hard tradeoffs. Better devrel people had experience writing, presenting, and teaching technical topics to technical audiences. The best devrel people had a following via a blog, youtube, books, or the like. Unfortunately, most current DevRel people don’t have any of the above. They may be strong marketers but they’ve never shipped code. They may have a computer science degree but they don’t have experience. Frankly, they haven’t put in the reps. They could address but it takes time and effort but few current devrel people are willing to do that.

DevRel hurts DevRel

DevRel atrophies your development skills. Of the DevRel people who are developers, the longer they go between shipping real, production code, the more abstract their understanding of both the code and how development is done becomes. Yes, they can still open their IDE and hammer out some clever functions but how do you deal with a modern CI/CD pipeline? How do you deal with massive projects including thousands or hundreds of thousands of lines of code across huge teams? When was the last time they updated tickets in Jira?

Sorry.. I just died a little inside there. Give me a minute.

DevRel gives you a distorted view of the world. The average developer attends zero conferences each year. A small portion attend 1 every other year. An exceptionally small, tiny, immeasurable number attend multiple in a given year. Then you have DevRel. During my peak, I was speaking at 15+ conferences a year and recognized the “conference circuit” types like myself. We saw each other often and formed friendships within that. But at some point, the topics changed from “here’s a cool thing I discovered” or “here’s how to do our jobs better” to “here are the cool places I visited” and “I got this credit card to optimize my points.” It shifted from doing the job to bragging about the side benefits of the job.

So what do we do with DevRel?

Eliminate DevRel. While this seems to be the current path, it’s a bad approach. Done well, DevRel is immensely valuable. I’ll talk about this more next week but great DevRel is a blend of Product Marketing and Sales Engineering.

Switch DevRel people to other areas. Maybe you don’t need the DevRel function but you like the people. Moving them to another team is great but requires them to shift gears. Not only will travel effectively go away but they’ll have metrics that are wildly different than they used to do. Then the question becomes: Where should they go?

• Marketing – this is the obvious answer with Product Marketing being the best fit. DevRel people already understand storytelling, writing, and presenting and many have some idea of metrics and distribution. If they can leverage and improve these skills, this is the best fit by far.
• Engineering – one of the hardest fits. Again, most of them were never developers so they don’t know how to operate in this world. Further, their skills have atrophied so even if they left as a senior engineer, they’re probably not fit to be one now. The ego check will hurt.
• Product – a weak fit. For Product, you need deep understanding of the problem, your company’s products, and the overall ecosystem. Very few DevRel people have ever had to consider those questions because they’ve never had to and most made a name for themselves outside the company’s goals and interests.
• Documentation and/or SDK development – this is another strong fit because these people have seen more docs, onboarding guides, etc than just about anyone else.

Those of you who know my career path are now saying “But Danger, you went from developer evangelist at Twilio to product at Pangea!” Yes, but you’re ignoring 10 years in between. At Okta, I ran product marketing for a deeply technical product and then at ngrok, I paired with good friend to boot up all marketing operations including product marketing. I got a lot of bruises and education along the way.

So what should DevRel do?

DevRel needs to reflect on their role and goals.

Figure out what your company needs. What are their goals? How do they measure success? How can you influence that number both short and long term?

Focus on that goal. There are a ton of things you already can do that map to that goal. Do them. Do them often. That may include blog posts, guides, docs, SDKs, sample code, integrations with existing frameworks, customer interviews, competitive/ecosystem intelligence, and a ton of other things.

Measure your contribution to that goal. The gold standard answer is being able to say “I did X and that changed key metric Y in this way.” You may not be able to say that all the time but do what you can to move that direction.

Adjust your perspective. It sucks to not have cool trips, meet core framework devs, and catch up with friends. I agree but those times are gone. Going forward, those teams will be smaller and unless you can address a lot of needs, there won’t be room for you.

Sharpen your skills. Figure out which direction you want to go in – product, marketing, engineering, whatever – and double down on those skills. Look for opportunities to work on those efforts and teams and be useful and build a bridge to move there.

In Summary

Early DevRel came about to solve a real problem and did. More modern teams were less effective – both from being more expensive and the overall noise – and now the correction is hammering both the handful of best, industry-shaping people along with the weakest.

You can either fight against the trends or you can figure out how to ride them.

Note: Thank you to all the people who bounced around ideas and critiqued my analysis. Since 100% of you said not to use your names, I’ll use initials: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, and Z.