How We Broke DevRel as an Industry  ## Metadata - Author: [[Community Pulse]] - Full Title: How We Broke DevRel as an Industry - Category: #podcasts - URL: https://share.snipd.com/episode/0bb107b9-01f0-4e86-ab4c-5bd1bf72f6c7 ## Document Notes ## Highlights - Episode AI notes 1. The definition of DevRel varies between companies and is often based on the individual's personal experiences. Hiring for DevRel positions is often done by individuals with little to no DevRel experience. There is no unified definition or criteria for building a DevRel team. A DevRel team requires a combination of different skill sets. Building a successful DevRel team requires understanding the strengths and weaknesses of the team and filling in any gaps appropriately. Many companies approach DevRel without a clear understanding, resulting in mediocre outcomes. 2. The speaker believes team-specific metrics are a waste of time and make teams less functional. The only three metrics that matter for a company are: are people finding them, are the people who are finding them signing up, and are the people who are signing up sticking around. The speaker argues that developer experience should be measured by how engaged and activated the users are. The speaker believes that increasing the proportion of level three activated users and the overall number of users should be the job of the team. There is pushback on the speaker's argument because other departments are also responsible for achieving those goals. ([Time 0:00:00](https://share.snipd.com/episode-takeaways/e7e0b34a-7a7f-4b7a-8e87-edc76aaf0f15)) - Challenges in DevRel Teams and the Need for Definition Mia Moore and Jason Langsworf discuss the challenges of DevRel teams. They point out that the definition of DevRel varies by company, leading to mismatched skill sets. They argue that there is no unified definition or standard for DevRel teams. Instead, companies should build bespoke teams based on their specific needs. This lack of clarity results in subpar performances and a need for improvement in the industry. Transcript: Speaker 3 My name is Mia Moore. I use they-them pronouns. I work for a company called Camunda that's also based out of Germany. I also do not live in Germany. I live in Austin, Texas. My role is the senior technical community builder, so I'm on more of the community building side of DevRel. Speaker 1 I'm Jason Langsworf. I just screeched in off the off stage. Thanks for letting me join late. I run a company called Learn with Jason. I do content for hire and I'm based in Portland, Oregon. Speaker 2 Awesome. We all have had different experience with developer relations, and some of it in terms of the way that it works now, is screamingly wrong that we all see, but people who aren't in the industry May not understand or be very apparent. For me personally, it's like one of the things is that people who hire for DevRel aren't in DevRel or don't have DevRel experience. I just wanted to try to go down the line and tease out some of the things that you know that you see that really shows that we really need to fix some of the stuff. Let's start with you, Jason. Speaker 1 I think one of the biggest problems that I've noticed in DevRel teams is that the definition of DevRel seems to be made up by each company individually. Sometimes the person has done DevRel in the past, it's building the team, and then they build a team that is a mirror of their skill set, times however many people they can get headcount For, which is problematic in and of itself. Other times it is DevRel as defined by somebody who's never done it or been part of a company that has a DevRel team, and so they tend to do whatever they can piece together by looking around, Which is typically like, well, it's basically marketing, right? But they're nerds. I just cringe to bit. I mean, it truly is like it's such a rough, because we haven't ever defined this. There's no where you can go and get a unified definition of what to look for in a DevRel team, and I also, my current argument is that there's no such thing as a DevRel team. There is the DevRel augment, and it's made of like 15 different skill sets, and you probably don't need all of them in your company, so you have to build a bespoke DevRel team, which means You need an understanding of what it could do, what your strengths and weaknesses are as a team, and where you need that extra fill, and that is ultimately what nobody's doing, and I think That's led to a lot of folks just kind of wing in it, and usually with lackluster results. ([Time 0:01:33](https://share.snipd.com/snip/d30494a5-ec8f-42b7-81ba-0919a53a163f)) - The Value of Team-Specific Metrics and Developer Experience As the VP of developer experience at Nellify, I campaigned to abolish team-specific metrics and focus on three important ones: attracting users, getting them to sign up, and retaining them. I believed that measuring developer experience should be based on user engagement and activation levels. However, I faced pushback from other departments who also had a role in achieving these metrics. But that's the whole point, to work together towards the same goal. Transcript: Speaker 1 I have maybe a nuclear take on this, but so I was... Speaker 4 Well, it was spicy and nuclear. This is really great. Speaker 1 Right. So I was the VP of developer experience at Nellify. And while I was there, I spent most of my time campaigning to just, like, abolish most of the team-specific metrics, because they're a huge waste of time. And I actually think that making team-specific metrics is an exercise in, like, administrative procrastination that actually makes teams less functional. And my reasoning for this is, the reason that the company exists is to make something valuable that people want to use that they're willing to pay for. And so the way that you measure that is, are people finding us, are the people who are finding us, signing up, and are the people who are signing up, sticking around. Right. Those are the only three metrics that matter. And everything else is just us playing corporate chess so that we can own a metric, instead of just all taking ownership for the metrics that we should care about. So what I was always pushing for at Nellify is that, like, developer experience should be measured by how engaged, like, how activated are our users. And we had come up with scoring to say that, like, somebody who used our platform has, you know, done certain things that made them a level one, level two or level three activated user. So I argued that our job should be to increase the proportion of level three activated users and try to help increase the overall number of users total. I got pushed back on that because, like, well, of course, product is also responsible for that. Engineering is also marketing is all like, yeah, yeah, that's the whole point. Exactly. Right. ([Time 0:21:46](https://share.snipd.com/snip/e34a9155-57ee-416c-9e20-cdb9e9534db9))