how_we_broke_deverel.txt

"Hi, and welcome back to another episode of Community Pulse. We are broadcasting live from Pluralsight Link, which has been a lot of fun. and we brought together some friends to chat today about DevRel, which I know is a super broad topic. But as a lot of us know, we have been changing and evolving kind of over the course of Debraal history, both in the day to day responsibilities and also in the identity of what DevRel is. We've had external influences as well as internal influences that have really changed what the definitions are, what the expectations are, what our roles are for better and for worse. So in this episode, we'll talk a little bit about what's working. what's not working, and how we can move forward to a future where DevRel makes sense. You're listening to the Community Pulse Podcasts. Welcome to your host Mary Thangball, Jason Hand, PJ Haggerty, and Wesley Faulkner. So I think this this is gonna be a fun one. I think there's a a lot of topics and a lot of things to touch on. So I think that it probably would let's just get straight to our guests. Why don't you introduce yourselves? We'll start with Ben. Hello. It's really, really great to be here. I'm Ben Greenberg. I work at a company called Parity Technologies based in Germany, but I live in Israel. and I help lead the advocacy vertical in our DevRel team. Awesome. Awesome. My name is Mia Moore. I use theythem pronouns. I work for a company called Camuna that's also based out of Germany. I also do not live in Germany. I live in Austin, Texas, and my role is the senior technical community builder, so I'm on more of the community building side of DevRel. I'm Jason Langsthorpe. I just, like, screeched in off the off stage. So 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. Awesome. And we all have had different experience with developer relations, and Some of it in terms of the way that it works now is screamingly, like, wrong that we all see but people who are in the industry may not understand or be very apparent. For me, personally, it's like one of the things that people who hire for DevRel aren't in DevRel or doesn't don't have DevRel experience. I just wanted to try to go down the line and kind of, like, 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 let's start with EG's. I I think one of the biggest problems in that I've noticed in DevRel teams is that the definition of DevRel seems to be made up by each company individually, and it's it's sometimes, the person has done DevRel in the past that's building the team. and then they build a team that is, like, a mirror of their skill set times however many people they can get head count for -- Mhmm. -- which problematic in and of itself. Other times, it is, you know, 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. And -- I I I just cringed a bit. You know, I mean, that's and it it truly is, like, it's such a it's such a rough like because we we haven't ever defined this. There's no there's no where you can go and get a a unified definition of what to look for in a DevRel team. And 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 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 winging it and usually with with lackluster results. Mhmm. Mhmm. Yeah. If I could add to that, I feel like sometimes I come from marketing. I come from content marketing. That's my background. And there's such a distinct difference to me in DevRel in marketing, but they also work together a lot of the time. So I think it's important to have, like, that healthy relationship but also understand who's driving what parts. And I think too, I've seen it where a company hiring will look at how many Twitter followers you have, or if you have a successful YouTube channel. And at that point, you're just hiring an influencer. That's completely different. I have many thoughts about this. Yeah. I think we all do. And, you know, it's not to say, like, if you have a lot of Twitter followers, you're not qualified. It's nothing like that. It's just you're looking at the wrong metrics for success. The other red flag to me is not considering that nontechnical folks can be on the Liberal team as someone who's nontechnical. I really appreciate companies that have a fuller understanding of all the different pieces and how to get the right people in those roles. But I I've I've seen a lot where when I was job hunting there, like, well, we're really looking for someone who also do demos and also do this and also basically do it all. And that's that's just a red flag to me to be like, well, this is my skill set. This is what I have to bring. And they go, well, that's not what we're looking for. or we're looking for that plus everything else. It's like, okay. Never mind. We're not aligned on on the strategy of of what you're trying to do. I I think it's interesting you mentioned that because I'll often, you'll see a job description, and the job description will be like, hey. We're looking for someone who's a content writer. And then when you get in the actual interview process, it's like, hey. Gotcha. We also want you to be able to code. Yep. It's like, hold hold on. What does that have to do with the thing that Here's the list of 20 different expectations you have for me. And you're like, this is 5 jobs. That's great. Yeah. It's just 3 jobs. Yes. DevRel, it's 3 jobs at a transcript. And it is, but also, like, you have to pick 3 of the 15. Right? Like -- Right. Yeah. Exactly. You can't give me all 15, and and that's just not pop for any one person to be all those things all the time. Absolutely. Yeah. Yeah. I just echoing exactly what they both just said. I completely agree with everything. In addition to that, I really think that DevRel is an interstitial role in that it sits in between all these different aspects of a company and understanding and narrowing down what it is that you need from a DevRel team in a company. I've noticed a lot of companies have not done that prework of why do we need a DevRel team? What is the advantages, what are the benefits that we're looking to gain by creating a DevRel team? In the context in which I've lived for the past few years, there's a lot of startups where I live. and a lot of start ups are told by their funders. You need to have a DevRel team. Yes. Exactly. And then -- How I'm interested. -- how many times have I sat with a CTO or CEO who said, Ben, can I sit with you to get pick your brain on on DevRel for us? Well and I would say, what are you looking for? And we don't know. the the funder said we need this, and -- Right. -- and I need to explore this. Well, now it's going even earlier than that. I'm I'm getting a lot of contacts from people who are, like, in a in the current Y Combinator class. You don't even have a product, and you're reaching out to me to say, what sort of DevRel strategy should I build? Oh, wow. How about you build a product? Let's start with that. Mhmm. You can't really have a community if you don't have anything else. Mhmm. You know, a lot of companies don't have a solid definition of done let's have a definition of done, and then maybe also have a definition of DevRel. Mhmm. Right? Let's let's create some of the structures around here. I think that would that kind of clarity would help reduce some of the frictions that if from the get go or from the initial start of the formation of the team, You understood why you were creative. What is your origin story -- Mhmm. -- for why you exist as a team. Yeah. And if you have a good origin story, you can always harken back to that. and start creating some of the pipelines of success and metrics, understanding what matters to your team. If you understand why you were there, if you don't even know why you were there, you have no origin story, that all that kind of cascades from there -- Right. -- automatically. Right? I think a little bit of it steps also on the on the problem that you see in startups and role or or in the VC culture where people are trying to create a solution for a problem that doesn't exist. Yeah. And when you create a solution for a problem that doesn't exist, you'll continue to find other ways to get resources that don't fit the bill. So, like, I've I've worked with companies before that are, like, Cool. So we made this thing. This thing does this for people. They don't know if they want it or not yet. Doesn't really matter. We've got a DevRel team. We want you to come in and do DevRel. I'm like, Well, who am I who am I who am I relating to? Who are the developers that I'm relating to? Because you don't have an open source, bro. You don't have an API You don't have anything that anyone needs. You built an app that finds poop in San Francisco. No one needs this. Yeah. It's it's it's easy to find. would -- Okay. Well, that's a huge difference. -- to a there is this pub against all of their -- That's what other podcasts. Can I -- That's for the after pulse. I have a I have maybe a a, like, sharp left turn here, but I have I have You said you'd be spicy, Jason, so counting on Well, I mean, my my spicy take is that I I just think everybody's, like, not hiring well for for DevRel. I think that what most people -- Should you mind that Mary hires for DevRel? What the freeze? And well, actually, I'm I'm I'm honestly, I'm I'm really curious to see if if this is if this is something that that Mary would agree with. But I I have noticed that when a lot of companies are hiring DevRel, they're thinking about the influencers, and they're also thinking about content. And so for a lot of companies, what they're they're hiring, what they say is DevRel and what they're hiring, is a content writer. And they don't understand that. So then they get confused when they're like, but what if we wanna run a hackathon, how come you can't run that? It's like, because I'm a content minor. Right? Well, I and I'm gonna take that as I'd even take that a step back. They don't even understand what content is. Well, and and this is the other problem, right, is, like so I I've watched companies kind of come in and say, we want a DevRel team, and then they basically hand them a list of SEO terms -- Mhmm. -- and say, make us rank for that sounds familiar to you. And right. Right. And and then -- Feel this. -- later when the DevRel team wants to do something else. Or, like, why are DevRels all quitting? Because Like, aren't they doing DevRel when we give them this list of SEO terms? Like, oh, no. Not at all. Yeah. But you the I think -- A little personal to me personally. I think this is this is sort of like the I I've watched this happen in in a few different teams, but this is actually more of my my left turn here, which is that I do think that early stage startups should have DevRel, but I don't think that it looks like what we're we're talking about. Yeah. I I agree to that. I I think that one of the highest value things that Adevro provides is that, typically, people who are coming into Adevro are doing it through a pretty circuitous career path, and that means that they're bringing a really broad perspective to a company. And so I've always thought of DevRel as kind of the island of misfit toys. Mhmm. And DevRel is where you can send a project that doesn't fit elsewhere in the organization. You can send like, I don't know. Maybe we wanna build a little library that helps people integrate with our tool. I don't know. Maybe we wanna try a a community program. Hey. Maybe we wanna try building this thing where people can, like, interact with it and share generated selfies, whatever it is. Right? Those those projects fit in DevRel until they mature, and then they move out. So DevRel is a really good experimental lab. -- is your first customer, basically. Yeah. Kinda. 40. Yeah. Yeah. And also, as your low risk experimentation -- Mhmm. -- when you don't have engineering resources to try something, you don't have a marketing team, you can say, like, hey, DevRel. Y'all go build something fun and see if people vibe with it and, like, wanna share it. Yeah. And they and, like, of course, we do. Of course, we wanna go build that. That's the best part of the job, at least for me. Yeah. And and so I actually think that that's one of the best things a start up can do is is invest in but you have to get the right DevRel. You've gotta get the the chaos monkey creative tinkerer that loves that, like, it's unstructured. I wanna do a little bit of everything. I have no rules, and that actually makes me feel good. Not panicky. And then you need to give them the flexibility to be able to continue doing that because soon as the company gets more mature -- Mhmm. -- and you start to say, oh, okay. Now we need you to go write this, this, this, this, Now we need you go do these official things. That person who is fantastic at that chaos monkey, break all the things. Let me see what I can do. What can I attract people? is gonna be so turned off to that -- Yeah. -- that they're either gonna leave and take their audience with them because they're gonna have a following. or you're gonna wind up just burning them out completely because it's not the role that you hired them to do. And that's the biggest thing to me and the probably the biggest thing that I've learned in the last three and a half years of being in Kamunda is hiring for the goals that you have for the team -- Mhmm. -- not hiring the team that you think you should have moving into it. Right? So in knock October of last year, we actually restructured our team. He had a team of 13. I'm looking at me because they're on it. Sounds right. Probably through. teen ish people, and we have a team now of 7 of us because we moved one of our developer advocates to the developer experience. team because they were really focused on SDKs. We moved the developer experience team to engineering because they were working more closely on documentation and the decays and needed to be more closely coupled with the engineering team. We moved another developer advocate to our product marketing team as a technical writer and a technical content creator who could do those SEO articles and things like that. So we kind of looked at the team and said, okay. we need a better focus as team because we're doing 18,000,000 different things. And also, there's other areas throughout the company that could better use the skills that are on our team to fill the needs that they have. And so looking at it in the sense of, here's the goal that we need to achieve. Here's the things that we're working toward. Does our current team fit that? Is if if I could start from scratch, is this still not the people, but the roles that I would hire for -- Right. -- is a very different question to ask, and it's not an easy conversation to have to have with yourself sometimes. But I think approaching it in that manner helps to solve a lot of those, like, what's our focus? Where are we going? What are we doing? Who do we need? And how do we then hire for those roles specifically without it being the 28 different responsibilities that you're supposed to And and it seems like it it that is kind of the the feast feast or famine situation where it's like, okay. So either I have one person who's doing DevRel regardless of title, I'm expecting them to do absolutely everything, or I have 250 people on this team, and they each do one thing, but not all the time. Mhmm. Mhmm. And the both of those situations are toxic for lack of a better term. Like, I feel like you can be a single DevRel at a startup where there's seven or eight people and things are flexible and things are flying. And then as the the company grows to 50, well, there should definitely be at least another person there who has a different experience. And that's, like, like, when Mia, you mentioned you had a background in marketing and came into DevRel. Yeah. That's an unusual thing for DevRel. It's super beneficial for so many teams because a lot of people don't understand that they're and I know people are gonna be shocked. I'm gonna say this. There's a marketing aspect to the things that we do in developer relations. Oh. You heard it here, folks. -- be under That's not what I said. That's not what I said. That's not what I said. We're actually -- I see. I I agree with what Ben Whenever I think about whenever anyone asks me, where should DevRel sit in an organization? I refer to, like and this shows my age a bit. The old star network diagram where the mainframe sits in the middle, and there's a bunch of nodes that go out to the side. DevRel is in the middle because we should be reporting to the CTO. Should we be reporting to sales? Should we be reporting to engineering and product and marketing and everyone else? The only people we don't report to HR. One of the things that that Sarah Jasner did at nullify that I thought was brilliant is she she basically, like, leverage the fact that they wanted to hire her to make developer experience into its own department that reported direct to the the leaders, like, the the co founders. Yeah. And it was specifically because there's a great reason for developer experience or DevRel to report to engineering. also a great reason for it to report to marketing and to sales and all these different things. Yeah. Absolutely. But as soon as you actually move the reporting lines, the incentives twist Yeah. And and so it has to be, like, using your you know, there's a reason that, like, bicycles have spokes. Mhmm. Do you need to, like, balance those tensions and and really make that work. And and I think putting DevRel as a hub between everything is is like, I I feel like that's one of those things where everybody would say, well, of course, be the center of everything. But I I think it's more of I think it's more of that That's what I said. But Well, I think it's it's more that, like, in DevRel because it is a a discipline that doesn't really have, like it's it's not a contained set of tasks. I've always I've always used the the analogy of like, DevRel is a turbocharger. If you just have a turbocharger, it is a hunk of metal that does very little. If you have a well functioning engine a turbocharger makes it run faster and more powerful. So that's DevRel. You're you're putting it into a well functioning company, but it has to be beholden to all of the parts of the machine, or you're gonna be out of balance. And not only beholden to, but also getting things from them. Yeah. Right? It's a -- Partnered with is making it better. -- partnered with. There you go. Yes. Yeah. Oh, gosh. I have so many interesting Like, so many things I wanna share. Hopefully hopefully, they're interesting to people that aren't me. But I was a program manager in my last role, and when I was interviewing, I knew I wanted to do something with DevRel, and I knew I wanted to be more on the community side or more on the sort of behind the scenes rather than, like, in front of the camera, DevRel. And I talked to who would eventually become my boss, and I said, okay. I don't have the technical skills you're looking for. Here's what I do have. I have the organizational skills so that you can actually build a strategy and actually things done. And he said, let me give me a week, and I'll get back to you. And ended up making the role for me that was a program manager. is amazing. That's never happened to me before in my career, and it felt like a a milestone moment of, like, wow. I convinced someone I'm worthy of something. Right? But I that really says to me, like, there's this value that a lot of teams are not recognizing in organizing the work, organizing the strategy, And I think coming from marketing where everything starts with the strategy, whereas sometimes in DevRel, I feel like there's a focus on tactics or, like, we're making content for the sake of content because we're a content machine. Mhmm. And then you just have a team of really expensive technical writers. So I don't know. I think that's a thing that I find to be underserved in DevRel is the strategy aspect and how valuable people are that can do that, whether or not their expertise as an engineering. Yeah. Well, I I think this brings up a good point as well because, I mean, one of the things that I've seen is a lot of a lot of places will say, we need to develop a content strategy. And it's like, no. You're not actually asking me for a content strategy. What you're asking me is for a list of blog post titles that you plan for me to similar, you're asking me to hit the SEO marks that you want because I'm under marketing, and that's you think is the metric. And it goes back to the biggest problem in DevRel, like, what metrics are the right metrics. Right. Well, if you're working marketing, it's many how much top of funnel activity do you have? And if you're working in sales, it's how many people actually become monthly active users? Or if you're, you know, if you're on your product, it's How are we actually improving the product product based on the feedback? Are you even collecting feedback? And and so many of these places, especially when it comes to strategies, have content strategy. Cool. Are you tracking where people are coming into the blog? Or are you just saying we've had a 10% increase in blog posts? Yeah. Yeah. And, Jay, you've hit metrics, which is, like, one of my topics that I have obsessed about recently because ex you're exactly right because metrics are just impossible. DevRel 3rd rail? DevRel 3rd rail to get involved in in entirely. And I I said, and I've said it a few times that You have to create compelling metrics for your team that connect back to the origin story for why your team was creating the company to begin with. And then simultaneously, you also have to prove value to the teams that depend upon you and that connect to you. So those are metrics that are going to not necessarily be native. to maybe the landscape of the language that you speak, but there can be metrics around sales, metrics around marketing, metrics around all the other teams that are part of your landscape in the company because they are reporting about what you do for them. And if you don't take ownership over that narrative, over what they're reporting, then they're gonna take ownership over that narrative. I'm gonna construct that for you and for your team. And, ultimately, that's about the future viability and long term success of the team lasting in a company to be able to do the work that it wants to do. And then there's the whole other question, right, which is how do you create metrics for your team, quiet your team? What is what is success for a DevRel team once you figured out how to own the narrative of a you know, of how we wanna present ourselves in in this sales funnel. Mhmm. Even if we're not sales, we need to present But once we get past that stage, what is what is the metrics that matter to us? Like, I don't think it's gonna be blog collect or blog views, that doesn't seem very compelling. And we can all argue about why that's not compelling probably in really compelling ways. But then if it's not those things, then what is it? What is it? And we have to be able to clearly state it within, like, 60 seconds, which is super hard for me to do because I'm very long winded. has to be like, it has to be a lot of short, an executive brief summary for people reporting up and across. Yeah. because if we can't do that, then we're just not gonna succeed. Right. So -- Right. I I have maybe a nuclear take on this. But so I I was -- -- slice it in nuclear. This is really funny. So I I was the the VP of dev 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 a an exercise in, like, administrative procrastination that actually makes teams less functional. And my my reasoning for this is the reason that the company exists is to make something valuable that people wanna 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 NetLify 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 1, level 2, or level 3 activated user. So I argued that our job should be to increase the proportion of level 3 activated users and and try to help increase the overall number of users total. I got pushed back on that because, like, well, of course, product's also responsible for that. Engineering's also marketing's all. I was like, yeah. Yeah. Yeah. That's the whole point. Yeah. Exactly. Right. But, you know, there's the world that is in the world that should be, and I think you had the privilege position as a VP in the company to push for those things. For those of us who are, you know, managing teams or who are senior ICs or ICs of any level, we have to operate and live in the world that is Yes. While whilst we're also pushing for the world that should be. So in the world that is, we're living in a world of corporate chess and owning things. And if we don't master that world. We won't stay long enough. We won't be there long enough to even get to the to what should be. I I have such a good story about this. So we have been Mary and I have been working on a community health metric. And one of the things I was just like blasted to the past when you're talking about this. At a previous company, I worked for one of our success metrics was active developers, like active users. and they took the number that was in our tool that said this is how many users we have every month. And then they decided, well, people usually share an account. So let's multiply that by Oh god. Yeah. Like 3. Or or 6 or something. It was a much larger number than you'd expect. because I think their argument was like, well, probably people are only paying for one account, but there's, like, twenty people using it. which is very verifiable and a great way to measure things. But really to me, it said -- If you could hear PJ's expression. To me, it said that leadership decided that we need to hit a number that is unreasonable. We have found a way to hit that number -- Yeah. -- sort of. Right. And this was a much larger company, so this is very to me, indicative of, like, when you get to a larger company and you don't have the privilege of being in a higher up position, you have to say, okay. What can I do to make my team look good so that people know I'm doing work, and people know I'm contributing. And if that includes multiplying things by 6 because I don't know, that's part of it. But, yeah, I agree with you. I think there's a lot of time spent and a lot of time wasted on what essentially comes down to vanity metrics because in at the end of the day, it doesn't matter if we think there's six people using. They're only buying one account. Right. Right? So why was that our key metric is the number of users when we were just gonna kinda make it up anyway? Yeah. This is the whole thing that kills me is, like, I remember that one of the things that we started getting pushed on was blog views. Mhmm. Hey. We need to get more blog views. And I said, why? Like, what are we actually measuring? Right? Because I could go out and write a bunch of buzzfeed style top 10 tech tips articles get hundreds of thousands of hits and not a single sign up, and are we still happy about that? Was that what we wanted? I was okay, then what do we actually measure? Right. Yeah. Right? And that was -- Get to the y. Let's that's underneath everything. Exactly. because you have, like, your lead measure and your lag measure, Which one are we actually caring about? Mhmm. Mhmm. I feel like some people are just going through the flow, and they they just go what feels natural. And Natural for this podcast is for now we move into the checkouts. Conferences, meet ups, and events. Always start with a code of conduct. A model of accepted behavior that all attendees, staff, organizers, and speakers are expected to adhere to in order to keep a safe, inclusive environment. Call of conduct.com helps with reporting when that code of conduct has been violated. When an incident occurs, staff and organizers are alerted, so issues can be resolved and everyone can feel safe and secure. Conventations can be reduced via anonymous reporting and a record of all incidents is provided after the event.