Measuring DevRel during a downturn

Ben Greenberg: My name is Ben. As you've heard, I've been in DevRel for a while now, going on about five years, which for some feels like veteran DevRel. I dunno how that happens, but it does. And I do have some thoughts on the topic, how to measure DevRel thoughts on the topic, how to measure not during recession, but particularly also during this, what we'll call crunch time. That is not a real bobblehead, that is generative ai. I love it, right? It looks like a real bobblehead. Anyways, let's start with I think is an obvious just axiomatic truth in our entire profession. Something that I think will be starting the obvious to every single one of you in this room.

It should not be a surprise. DevRel is freaking hard to measure. Really, really hard to get right because the work we do in so many ways transcend traditional conventional measurements of relationship building, community building, weaving narratives, growing people together, creating a sense of common bond with a brand, with a product, with tooling, with people. It intersects with so many different areas. And as a result of that complexity, it is really, really hard to get it right in the measurements. But we also know, as hard as it is to measure a DevRel team that doesn't measure well, has a hard time proving we love the word success to people up and around us. And that's a difficult thing. I am very grateful right now to be back in an IC (individual contributor) role, but I did spend some time in a manager role and I had to think about this question.

And this is a really annoying question, question to think about. How do you talk up about what your team does and how do you talk around about what your team does, which means you need concrete terms, concrete language to help get that right? And if you don't do that, if you don't measure, well, it really endangers the entire viability of your team. It's the truth. You know, when you're in the IC role, as I'm very grateful to be back in, again, we don't always have to think about this question, we just have to do the work and enjoy the work. But if you wanna be in the job and not have the team asked, literally and figuratively, hopefully not too literally, but definitely figuratively, it is a significant challenge. And as we mentioned earlier, DevRel, as all of us know, sits at that intersection, at that liminal spot between so many different disciplines in every company we work in.

And this is regardless of whether or not your team reports up to a marketing head or your team reports up to a product head or an engineering head, it doesn't matter. Yes, there's implications for that of course, but ultimately you are intersecting, you are conversing, you are helping and building bridges between sales and marketing and product and engineering. In fact, I would say that DevRel is one of the few parts of a business that actually touch all these different areas all the time beyond hr. HR does also touch all these areas all the time, but DevRel really, really touches deeply in all these different disciplines. And as a result of that, many other teams depend on us for their work, for the success of their work, many other teams, marketing teams, sales teams, engineering teams, product teams. And it makes us feel awesome. We're needed, we're valued.

It's brilliant. It's amazing. How awesome are we? But that also has implications If we are part of the success story of other teams, even if we don't measure ourselves against the sales funnel, I have to tell you, we, all of us are being measured in someone's sales funnel, someone's, and if we don't understand that, our team won't exist in that company. And I, that's just the truth. I've been in companies where that wasn't understood and there were serious implications for that, serious ramifications. And it's a hard pill to swallow, but it is the truth. And so as a result of that, we have to understand exactly how we show value across the organization and all the different disciplines that we connect with. If we are part of their success narratives, we need to understand that success narratives and understand those metrics. And we should take ownership over those narratives.

Yes, we helped sales in these following few ways in this quarter. We helped marketing in these few ways, sales and marketing. Ah, those words, they're a little scary. But we helped them. We did these things to help move them forward. We can certainly talk about, and we probably don't feel uncomfortable talking about for most of us, how we help product teams iterate on feedback, user feedback we developed, you know, helped them develop a new feature or how we helped engineering on, you know, the API specs or something. But we also have to think about how we help sales and marketing. And this is a great way to guarantee long-term viability for both you as an individual and your team writ large. But it, and which really answers that question of how do you add value for the following teams, right? That's the first step. But it can't end there.

But it doesn't just end there because if we only measure ourselves against others, then we have to ask the question, what are we, if we're only judged by how we help others, then existentially what are we as a team? What is the avocado fingerprint? What is the DevRel fingerprint of us? Qua ourselves? Yes, we have to measure ourselves against others and understand the narratives that they're building for us and take ownership over those and prove the metrics for them in that area and build the success narratives there. But we also have to measure ourselves on our own level.

What is it to mean? What is the story that DevRel measures itself as DevRel, it's absolutely essential. And there's great frameworks out there to help conceptualize this. One of them is from a former manager of a manager of mine, Phil. Hello Phil. Good morning. Phil is great. Who knows? Phil. Phil, yeah. Phil's amazing. Phil's got great exciting news on Monday. We're very excited for you . So Phil you know, came up with the term with the most concise abbreviated term in the history of, of acronyms are the R term, right? And there's also the orbit model and common room also offers its own framework as well. There's great conceptualizations, great frameworks to think about how to measure DevRel, how to put in the right boxes and understand exactly to quantify in real measurements and prove the success and the value for the managers and for the higher ups.

And also to socialize it across the team. And that's great, but in an economic downturn, in a time of a recession, in a crunch, those frameworks are fantastic. But you also need to be, and this I have a really hard time being as succinct as you possibly can, as focused, directed, because what is the question that higher ups are thinking about during a downturn? What are they asking? Who needs to be let go of? What do we need to do? This is a, what are we in a lot of, in a lot of context, what are we, we are a cost center, a pretty big cost center sometimes. And so during a downturn you have to fundamentally and quickly, which I struggle with so much being like concise in anything, but I'm too long winded. But you have to fundamentally and quickly answer the question, why should we still be here? Brief, immediate. And that question usually starts with framing it for yourself. Why does DevRel exist? Not in general, why does the discipline of DevRel exist? Why do we exist as human beings? Let's have a conversation about the nature of humans. It's like a great theological psychological conversation. We could have that, but that's not the question. The question is why does DevRel exist here in your company right now, in this moment? That is the opening sal of the opening framing to start measuring understanding what you ought to measure during a downturn. How do you narrow it? How do you focus it? So we start with that question by thinking about some of the most famous people in real human history. People like Spider-Man, right? Because of course they're very real superheroes. What do superheroes have? Superheroes have an origin story, right? Regardless of whether it's Wonder Woman she's amazing, or Spider-Man or any of the other characters in the whole superhero universe. All of them have a story that captures their internal struggle, their reckoning, the things that they had to grapple with to become who they are and do their day job of, you know, fighting villains and saving the world every day, right? And, and that story is not only there provide a great, you know, intro movie or a like post movies that come back and do a retro movie and give the, the deep storyline of like the X-Men, things like that. No, that story is there because without it, we don't understand the motivations of what drives a rich, eccentric billionaire to put on a bat costume every day, right? Like, you need to understand why this person does the things they do. So if the superheroes have an origin story and given the fact that every single one of you in the room is in many ways a hero in your companies, what is, that's the jump, right?

Heroes. And now you're heroes. That's how we got there. So what is the origin story? I saw the, oh now I get it. Ah, thank you for drawing the line for me. So what is the origin story of your team? What is the origin story of why you exist at that company? Because I'll tell you what, you have one, you may not know it cuz you may be iteration number two or three or four of DevRel in your company and you may have to do a bit of Indiana Jones archeological research to uncover the origin story. But there is one. And once you undercover that, that can unlock for you a great framework, a great key and how to measure yourself during a crunch. So for example, you might start with the following sentence and fill in the blank. DevRel was organized here. DevRel was created here because, and then dot, dot dot ellipses. What are the reasons? There could be several reasons why DevRel was created your company. And these are just three possible reasons why leadership in a company says to themselves one day, you know, we have great teams, you know what we really need, we really need a Developer Advocate. And why did they say that? Well, they might have said it for a few possible reasons. And these are just three of many. One possible reason was, you know, we have some great open source repos, but no one knows about them. How do we build an open source community? We we put it on GitHub, we open sourced it. I don't, I don't understand. Do we even have a read me with fun badges and no one is using it. No one has like clicked on the stars.

No one's forked it. No one's commented. How do we get this? You know, we need an advocate to build up our open source community. Or maybe they were sitting around their room and they were like their boardroom and they were like, you know, our tooling, it's intuitive to us cuz we built it, but it's really complicated. It's like overly complicated sometimes. And we don't have any libraries, any SDKs, anything to help kind of abstract away that complex complexity. So we needed hire a DevRel rail team to help ease the onboarding into the tooling. Let's start creating some SDKs. Let's start creating some support libraries. And that's why you've exist as a team. Or maybe it's, you know, our docs are being created by the engineering team as they push out new features. And for some reason the engineering team for whatever reason, doesn't like to update the docs as much as they update the code. I don't understand why they don't love docs. I, I I don't get it. But they don't. And the docs for whatever reason are just always out to out of date. And the tutorials never work. We don't even have a tutorial. But if it, we had one, it wouldn't work. And our code snippets, we, you know what, what is a, why do you need a snippet? Our real engineer builds their own code. You know, tough. Like we just don't have it, but we really need this stuff. We need a good learning experience, we need good Developer education. So let's hire some advocates and they'll build up some DevED stuff. They'll make those things that help people learn our stuff. It'll be great. So those are just three reasons and I'm sure if you think about it and do the research in your companies and your teams, you'll maybe find some of these, but you can probably find others why you were created, why you are there in the first place. And since you were created, since it could have been you were created as a team a year ago, you could have been created three months ago. Could we created yesterday? You're probably doing other things now. You probably have taken on other initiatives because you are, for many of us in this room and for many of our teams, you are seen as engineers that can talk to people like friendly engineers, engineers that can speak and they're like, wow, we could use you in doing this and this and this. Oh, and can you also do those sales calls and can you, can you do that site visit and can you do this and this and all kinds of things. And you've taken on an array of items way beyond your initial scope because you are, for many of us, the engineers that are extroverted somewhat or introverted, extroverted or somewhere on the spectrum of introverted, extroverted, you like to talk to people once in a while, you may need to go back to your hotel room and totally decompress after a half hour of talking.

Not that I'm that person, but you know what, you're not at, you're not fully introverted, Ben, look at you. I'm not. But so you may be one of those people, but yet you're that friendly engineer, right? So you have a lot of tasks, but during this time, during a downturn, when you need to be as succinct as you can possibly be, as focused as you can possibly be, you have to return back to the thing that has the highest impact. The thing that is directly connected to why you were created in the first place, why you are there and prove your value in that area. Focus. You have to focus down, if you're the manager, help your team focus down. If you're the ic, start thinking about the ways that you focus down and manage up to your manager to help them realize you need to focus down whatever it might be.

You need to narrow into the thing that proves the highest impact that's directly connected to your origin story. So for example, just taking one and these are not like, you know, revelatory metrics. I'm not here to like reveal the metrics that will solve all problems. These are basic metrics that we've, many of us have probably seen before, but they're directly connected to that narrative of origin story to metric. So for example, if you were created as a, as the origin story, cuz you have a really complex product, you need really good tooling that helps onboard people to the product. So what are some of the metrics? And again, these are not like brand new metrics, things like measuring yourself against time to hello world, right? Like how long does it take for a developer to write its for their first line of code in your thing or the number of issues and the time to resolve them or perhaps the number of API calls through SDKs.

I used to work for an API communications platform, not Twilio, the other one and, and not the other one, the other one, the other one. . so you may , you may and I see some of my former colleagues, Hey you, he's now at the other other one. So you may, you may you may use that as your metric, right? Number of API calls through SDKs. And the point here is you directly draw the line. You don't make it implicit, right? You make it as explicit as you possibly can between why you're there and what you're doing to achieve why you're there. And you draw that line for people both above you and around you at all times. So you choose the metrics and you know, smart, we all know smart goals, et cetera, et cetera. I happen to think in this context and this moment in this time I would narrow down to specific, achievable and realistic of those smart goals.

So I want it to be as narrow as it can be, right? So in other word, a synonym for narrow might be specific, right? I want it to be achievable. Something I can actually do in this time and prove it. I, this is not the time to take a risk to launch a new initiative where you're not exactly sure it'll succeed or not. Those, there are great times for those things and we should all do them during a downturn is not the moment to do that, my friends. And make sure that it's realistic. Again, synonym close to achievable, realistic and also always points right back to why you exist. Now you could be doing all these things and doing a fantastic job with them. Take in, you know, Ben's prescriptions for DevRel during a downturn and applied them perfectly and hopefully you still have a job.

If not, please don't be mad at me. And everything is fantastic and great but we all know the joke that if a tree falls in the forest, no one was around to hear it, right? So if a Developer Advocate does work but no one knows about it, did you actually do the work? It's a really important question. This is like a question of like the nature of knowledge. Like it's an ontological question if you do work, but no one knows about it. Does it actually exist in the world? It's a good question. But let's like take it from philosophy down to practicality. I would say that this is a thing that we kind of speaking in eye language that I struggle with, which is the tension between wanting to share what you do versus not feeling like you're bragging, right? That's a very hard thing.

And when I first started working at a remote company, I've been working remote companies like for two years before the pandemic. It was hard because in fuller remote companies, if you don't talk about it online with your colleagues who are distributed everywhere, then no one knows. You have to constantly talk about what you're doing. And it's so hard because you know, you were trained, at least I was trained and raised by my parents. May they rest in peace to not brag at all. Like don't who are you? Be humble. Don't talk about yourself so much and yet we have to because there is a distinction, a clear distinction between bragging and sharing. We have to share, we should try, probably try to refrain from bragging too often, although probably a place for bragging every once in a while. But we should definitely share all the time as much as we possibly can because if you don't talk about it, it never happened.

All that work you did, might as well not have done it. Might as well just sat home and watched like Netflix. Cuz it just doesn't matter if you don't talk about it. That's another hard truth. That for me was a hard truth to learn that I could do all the right things, but if I didn't actually share it, I could have just like gone for a walk, hung out with my kids more like why did I waste all that time? Because I didn't talk about it. It didn't exist. Really, really important idea, especially, especially during a downturn. So you have to communicate your origin, you have to communicate these four things in completion, in totality, your origin story, the key objectives, the things that value that connect to that origin story, your activities that are accomplishing the objectives, the specific discrete activities that line up to the objectives and how you're measuring them and proving success.

So you always have to talk about why you're there because people have, don't have the greatest, longest memories for other things that don't matter to them as much. So you have to always talk about why you're there, why we're here, why we, why we exist, why we cost you money, why we're doing the things we're doing. You always have to connect that to, and these are the big large objectives we have in this quarter, in this half a year. And these are the discrete activities we're doing in this time period that's leading to accomplishing those objectives. And these are how we're measuring against those things and building success. And we have to do those because our work is really long, it's really hard. Our work involves relationship building, right? So we help sales generate leads, we help marketing with like whatever marketing metrics. Like we help product, we help engineering.

But ultimately, at least in my conceptualization of the work that we do, we are relationship builders, we're building relationships with people and that kind of work defies a lot of the conventional standards that we have. So we're forced to try and think of some conventionality by which to apply to that work so that we can do the actual work, which is the long-term relationship building, the building meaning and over emotionality and connection and community. And if we don't do that stuff, the metrics improving success. We're gonna have a really, really hard time doing the work, work of relationship building. Thank you very much.

Ben on mic: What do you do? What do you do when you're what do you do when your origin story sucks?

Ben Greenberg: So you heard, everyone heard that question? Cause you all laughed, right? That's the benefit of a microphone. What do you do when your origin story sucks? I actually have, that's a question I can actually give some coherent thought to that I haven't prepared in advance. Cause I have thought about that. I think you own your narrative. You are the shaper of the narrative. So the people who created your DevRel team at wherever you're at, like company X, Y or Z, however many months or years ago or even yesterday, they may not be there anymore. So you get to craft that narrative and you get to shape it in whatever way. So for example, I'll give a a bit of a morbid example, right? So in my previous career I used to be a congregational rabbi for 10 years and I counseled a lot of people over funerals and and bereavement.

And people have complicated emotions with their parents. I don't know if that's a surprise. It may or may not be. People have complexities when it comes to grieving and mourning the loss of a lo of a parent because not every parent was great. Not every parent was awesome. Parents have challenges and some parents from spectrum of abusive and horrible to just like downright instilling tons of guilt all the time. And like, you're not gonna eat that. They're starving people in the world. How could you not eat that food? Like all that kind of stuff. And one, one way to when a person was ready to get to that point was to be masters over that narrative of their parent cuz the parent no longer lives. So now you get to shape the story and you have to be in the right emotional, psychological space to do that.

It doesn't happen right away. And that's in bereavement, right? So we're not, that's a serious topic, but if, if, but once someone can do that, then they get to own that relationship in the way that they construct it cognitively going forward. And it doesn't distill the trauma, doesn't distill doesn't get rid of the issues, but allows you to shape it for future generations. And the stories that are told down the line, you get to own that story. So if you could do it for bereavement and families can do it for bereavement, we can do it for DevRel stories, right? We can shape and own the narrative over how our teams were created. Even if the narrative sucks and it's horrible, we were created because they didn't know what the hell they were doing. Like, well, let's create a narrative. And you know, even if, even if the ownership of the team, not the ownership, the leadership of the team, like even if they remember the narrative, why they were created, why they created you, and they're like, oh yeah, we created them because the VC said we should have the DevRel team.

But if you come together and create a package, a story that's compelling, a story that makes sense, guess what they're gonna say? It's their story very quickly and it will be the come the company story.