The DevRel Blind Spot: How to Make Your Work Impossible to Ignore

Building Effective Dashboards for DevRel Impact

(Transcript will be added after running transcription) Jeff Bull: How many of you have been asked to there you go. Ask to put your DevRel impact into a dashboard or the things you do in a dashboard. Yeah. Exactly. And keep your hands up if you've actually if that dashboard actually captures anything that you are trying to tell to senior leadership other than LinkedIn follows or things like that.

Yeah. It's the hardest thing that I think all of us deal with is building not just dashboards, but actually telling senior leadership what we do in a way that makes sense to them that fits, you know, business goals, and that's really what I wanna get into here today. Sorry. I'm having to do this but in both places at the same time. Sorry.

Skip that one. Cool. Okay. Let's go. Come on.

There we go. Nope. Not that one. There we go. Okay.

So this is what most of our dashboards most reporting tends to look like. At least that's what the ones I've tended to have usually because we don't know exactly what our senior leaders are looking to find out, and oftentimes they don't know either. So it seems like page views and follower counts, you know, vibes were good, stuff like that, list of what we did but not really what it enabled for the business. It's really just activity without context, effort without impact, stuff like that. You know, it unfortunately reads more like a scrapbook than it does, like, actual data reporting.

And I think that's honestly I know it's a little spicy take to say this, but I think that's honestly why when DevRel gets impacted by RIFs and things like that, I think this is more often why that happens because senior leadership doesn't understand how your work and all of our work actually connects to real business objectives or business outcomes. So and translating these things is really what I wanna get into because if they if those leaders cannot see the value in what we do, the question is always like then why are you here? Cool. So that's me. That's it.

I I had on the intro that most recently at Orkes because I'm actually not at Orkes anymore as of Monday this week. So it's a little little interesting to be here. It's my first time ever actually doing that. So but if you wanna connect, I'm on LinkedIn and all the socials and stuff at jeff bull tech. You'll find me everywhere.

Star Wars stuff, everywhere you can possibly think of. Cool. Move on. Just to make sure that I'm keeping up with time. Alright.

Bridging Communication Gaps with Leadership

So we all speak developer. Hopefully, we all speak developer. Whether you are a developer or not, that's a matter of a different kind of conversation about being a developer advocate or a developer, but we all should be able to speak to them and speak their language. But our leaders, your boss, your CFO, whoever it happens to be, they speak things like margin and risk and pipeline. That's what they talk about.

That's what they actually care about. And really the space between those two things, those two different languages, that's the translation gap that we really need to be able to fill because it's not really a communication issue. It's a visibility issue. That gap is why, to me, DevRel most often gets impacted whenever things are happening. I kinda mentioned that.

Transforming Community Engagement into Business Value

I've joked with this a couple different times with people earlier today that if you think throughout the week, they're like, oh, I jumped into Discord and I engaged with a bunch of different community members and it went great. But if you tell that to your boss or who may not know, what they probably just heard is, do you talk to a bunch of people online? What? Okay. How did that close did that close a deal?

Did that do like, that's what it sounds like. And so what we really need to be able to do is actually change what we are saying so that we're telling the right story about what we actually did, because it isn't just you talk to people. It's something more like you solved the technical issue before that escalated. You could've prevented support tickets, things of that nature in this example. So a more appropriate translation might be something like I prevented x number of support tickets for and freed up a bunch of different hours for engineering by interacting with these community members.

There might be a more concise way to say that, but the point of that is tell that to somebody because, oh, that makes sense. Like, engineering's already backed up with all their work. We don't need some more support. We haven't even onboarded a customer success team yet. Okay.

That's really helpful. Sounds a lot better to them than, I chatted with a bunch of folks on social. So same type of work, completely different story. The crux of the session today is just gonna be about that. We're not really changing what DevRel does.

Highlighting the Hidden Value of DevRel Work

The point of this is to change how it's seen and how it's measured so that we try to really make the whole idea of the, like, invisible things you do every day more impossible to ignore or impossible to ignore. Alright. So in my experience, the most valuable work that any of us do in DevRel is the stuff that most everyone outside of DevRel doesn't really see, and it's kind of by design. We don't want that work to be noticed in the way that most people would think. We know all this.

Our teams know this, but our leadership teams don't. They generally only see that very tip up there. And if and, unfortunately, I think I think Jen and I actually were talking about this last night or not last night. Yes. This morning or at some point.

It the idea that a senior leader is going to really focus on something that they know they can measure or they know how to measure already. So and, again, a cheesy example, but I think it's a real example, is if they understand how to look at LinkedIn and go, oh, we have this many more followers or we've got this many likes on a YouTube video, they know what that means. They that measurement makes sense to them. But what also is the problem is if you just tell them I put more videos up there, they're going to think about that immediately and, again, question, like, what is this great, but what does that actually do for our business? So they're just seeing that thing upfront.

We have to give them something else to understand. So these public artifacts like tweets and conference talks, blog posts, we all need to do them, but it's the that's the visible layer. That's the stuff that looks like marketing or thought leadership to somebody who doesn't really understand what we do. And because it's all they measure, it's all they assume sometimes is happening, which is not actually the truth. I would say probably that's like 10% of the work that we tend to do in DevRel, but it's what they notice.

So in my opinion, DevRel's not really just the community team. It's the feedback loop. It's the sorry. It's the feedback loop that makes technical adoption scalable. It's the early warning system for risk.

One of the things I I was joking around with, I was kind of coming up with some of these notes, and I put them into ChatGPT, I think, and it came up with the the term churn insurance. I was like, I didn't put it in here, I'm like, that's actually kinda funny. I think that's that could actually be really true. It's one of DevRel's one of the few functions across an organization that touches and can interact with product and revenue and brand in really meaningful ways. And if we keep measuring DevRel like it's a marketing channel, we're gonna keep underfunding our most strategic advantage.

Okay. So let's get a little bit more into this. Cool. So just referring to this as the DevRel iceberg. So the things that are commonly seen, but what we're actually doing through the our work, what's actually being accomplished, these are the things we can shine a light on that I think really, really help show our value inside of a company and allow you to have a greater impact and open up more conversations.

So top is visible. It's what gets attention. It's also the least valuable from a business standpoint. So if we go a little bit deeper, let's take a look here. So crisis prevention is an example.

I know one of the speakers earlier today was talking about crisis prevention or crisis management. You know, it's you you bring up friction before it actually turns into churn or support escalations or product failure. You can catch those signals early, hopefully, when they're still reversible. If anyone's used Common Room or Orbit, those types of tools where you can actually see conversations happening in one place, it's it's easier to actually gather sentiment and report on that, but there's other ways to do that too. Support reflection is always a good idea.

You resolve issues in the community before they even hit a your attack desk or your help desk, whatever you call it. It's not just goodwill. It's actual cost savings for the business in a lot of cases and faster time to resolution. Product influence is where you, like, represent the developer needs inside the company. Your insights share, you know, shape road map and derisk launches, hopefully.

You can prevent wasted engineering cycles, all of that. Pipeline acceleration. Actually, this is one I've been most recently working on when I was at Orkes trying to help bridge developer community data that I had with the sales development team in an actual way that they could do something with, like, come up, open up a tool, look at it, and say, oh, here's five contacts to go reach out to because they've expressed signals of be signals of behavior that are meaningful for what we do. So for me, pipeline acceleration is also really big about building trust with these other groups that what you're showing them isn't just, look at all the cool stuff happens here in the community. It's more of, like, this is important to you because of this reason.

That trust can become credibility in technical sales cycles. It can also help deals close faster and with fewer objections. So you're not just growing your community. You're actually building a network of, you know, third party builders, integrations, and advocates, which turns into a really long platforms long term platform scale for you. It's in many cases, it can be pretty silent work to most, but it's the longer the long game work that we've built and just spend our time on.

And it's honestly, it's the work that drives adoption, loyalty, and a competitive edge. You know? We see it as community building. We see people in the community, but what you're actually getting out of that is people who want to stick around with your technology and use your technology, and then sales and others can look at those intent signals and use that what your job is to show them how to do that. So today, hopefully, this session, what I'm really trying to get across is not me telling you how to go connect with developers.

Hopefully, you're all good doing that. That's kind of the point of being into DevRel. It's really how to increase the strategic visibility of your work. There there is an actual table on my screen that's, like, five of these. And for some reason, every time I copied it over from Canva to put into this format, it cut off this box.

Five Stages to Enhance DevRel Visibility

I have no idea why. But I'll re I'll tell you the five. The version I put out there for will actually have the correct image on this. The five layers listed here are that should be listed are instrument, report, align, forecast, and advise. I'll make sure everyone can have a copy of this.

So if I I'll just talk to them very briefly. Instrument, it's the foundation. This is where you need to be tagging and tracking and connecting relevant fields to data fields such as, like, your in your CRM. A couple examples of this would be, like, form fill UTM activations, new contacts from your community. You're trying to make in this stage, you're trying to make DevRel actually traceable so that you can see where things are coming in and where they're going, so people signing up for your tooling, submitting a form, all of that.

So you really want it to be the difference between we did stuff, as the thing you say, and being able to show where it happened and who it who it reached. The second is reporting. Now that you've got some data, you start translating it, and you have put actually put those into impact reports. Revenue, the it can depict revenue that was influenced. It could be support deflections, road map insights, things of that nature, but it's where DevRel really becomes legible to the business.

And you're not just talking to community in community terms anymore. You're actually talking in business outcomes. Stage three is align, which is once you're reporting clearly, it's time to actually integrate. So that's where you wanna pull the metrics you have kind of set up in the for the previous two and put it into the into various dashboards that may exist already for your go to market teams, sales, marketing, product, customer success, tools they're already using. Dashboards they're already using.

Either in existing ones or build one in the same platform that they use. There's a comfort level for them. They're not having to learn something new because, like, well, I like to build my stuff in Purcell, and you have it all in Grafana. It's like, well, then just I mean, that's a simple thing, but put it where put it where they are. Just like in community, go where your members are.

Don't just build a form and say, this is my community. Is it successful because I got people here? It's like, well, if there are roofies here, then that's where we go. Forecast, stage four. So at this point, your data, DevRel data, isn't just reactive, hopefully.

It's predictive because what you've done is now bring bring to light things that are, again, intent signals, signals behavior, whatever term you wanna use for it. You're starting to bubble that up so people can look at it and actually ask questions and make decisions based off of it. It and, hopefully, it can start to inform road map prioritization because you can see trends and make suggestions and to really discuss those details, and it can show where growth is happening and where support's gonna be needed either now or in the future. It can also help with hiring plans and go to market timing. I'll have a couple examples in a minute about that and a variety of other things.

And then stage five, the last one is advise. It's the final shift. It's where you all of us in DevRel aren't just, like, feeding insight upward. We can actually use it to shape strategy because in a we can actually say, look. You can see this.

You can see that these are the trends that are going on. This is what people are actively talking about and asking for. That's the that's the reinforcement for what we should be building or evolving in our product line. And if that's not happening, that's a road that's where you get to really show, think, even more leadership value yourself, whether you're a people leader or not, is by bringing that information to your boss or more senior leaders and explaining that sort of data driven decision making. Like, I'm telling you that or the suggestion I'm making is that we make these two changes to the road map or we add this feature to our product, and I'm saying this because of these intent signals that we're seeing.

People are asking questions. I could see it in the community data itself. There we go. Cool. And I think that's the shift that a lot of teams miss.

My the last role that I was in, you know, we were getting there, but it was definitely a challenge to make that shift because oftentimes, like the startup I was just at, the senior leaders or cofounders, they don't understand these things as well as all of us do. They they don't do this type of work, they rely on us. But oftentimes, what also happens is I don't wanna say them will believe us, but they haven't built enough trust up with us because they simply don't do the type of work that we do. So they don't understand it the way that we do. We could try and sit back like I've done many times.

I'm sure all of us would be like, come on, man. Just listen to me. Listen to what I'm saying. But I think what's we have to all realize is we're adults and as professionals. It's our job if we really wanna have an impact on the business is to figure out how to speak their language so that we can tell the story they need to hear because who did I see post this?

It was a YouTube video talking about how to get public speaking, and the person said, talk to a senior leader or present like you're talking to a five year old. It was they were trying to be silly about it, but just, like, essentially break it down to the fewest words you can to make them understand because you get, like, thirty seconds of their brainpower, and then they're gonna move on. So if we can get that to resonate, then you're good to go because we know there's a lot more nuance behind it, behind these details that we provide, but they're not gonna hear all that. They just need to hear and know that you're thinking about the things that are important to them, and then they then you have more wiggle room to continue on. So if in in some of these stages let me pull this back up here real quick.

So when you think of influence, don't just think about, like, in in these stages here, don't just think about, like, content or community health. Think about timing because the earlier you bring insight into that process, the more leverage it's gonna end up having. So see things early. You hear the confusion in real time by watching tickets come through or, you conversations know, happening in the community or on Reddit or wherever it happens to be, an owned or unowned community platform. You might see usage drop off in before a product team does, and you might hear what developers are really trying to build, not just what they ask for.

Right? This was a thought I was having earlier that one of the challenges, like, sales engineers have, but I I think DevRel, we developer advocates have sometimes too is we hear someone say, this is broke. How do I fix it? But we don't always ask, what are you actually trying to do here? And then what we deliver to them is what they asked for, and then it doesn't always that content doesn't always it could be written, video, whatever.

It doesn't always go anywhere. Like, everyone said they wanted this. But when you actually have a conversation with them, you start to realize, oh, that's not actually what their problem was. This is just the one way they thought of to try to fix their problem. I think that is one of the reasons why going through these sorts of steps is so important because I as much as I struggled when I worked in sales for a bit as an SEO at Cisco, because I hated having a number on me, but one of the things I realized is that you get a lot of experience as being dropped into a situation where someone says, this is what we're gonna talk about, and then you come in and the person's like, cool.

I wanna hear this other thing. And you're like, oh, okay. Cool. Let's let's go do that, and then you do it, and you start to realize, wait a second. Let me ask you some questions here because I don't I don't think what you were I don't think that word means, which I think if you think was that phrase?

Yeah. That word. That that thing from the Princess Bride. Like, it's I don't think what you're telling me is what this actually is, so let's kinda dig into it because oftentimes it's a lot simpler than that, or it is actually more complex, and we can offer something different to them that has a real impact. An example could be something like, you know, in q one of your fiscal year, you surfaced, like, a highly requested feature was being misinterpreted.

Very odd very much been dealing with this recently. So early feedback loops got triggered, a product conversation, and that, like, say could save some engineering time in an ideal world. So in that in that example, q two developer interest in a specific use case wasn't on the radar at all, and then your insight could actually help shape the road map for the next quarter based off of what you're seeing. And then finally, let's say q three that same year, Dev, you, like, you flagged that some technical positioning was off for enterprise buyers or whoever. That insight can actually then shape go to market story that marketing uses or that sales uses when they go talk to customers.

I was working with the sales development team at Orkes, and that's one of the things we ran into is they were positioning it in a very particular way. When I actually heard them tell me what they say, like, I'm not I don't build microservices workflows. I'm not a developer by trade, but I was a network engineer. I was an engineer for most of my career, and, like, one of the things you all of us probably have experience with is we understand systems. So we can actually talk to them.

Like, I don't need to know what you're writing and how you use your code, but I I can listen to what you're telling me and realize the thing you are trying to do with that, I don't think is what that's actually intended for, and something else here actually might work better. That's the conversation we wanna have because that right there is what can come back and say, hey. Sales team, SDRs, whoever it is. Try saying this a little bit differently to that person when you're talking, and you might see more more of it resonate with them, which could turn into, yes. Let's book it.

Let's book a demo or let's get really get on the phone with an AE or let's may possibly even move that deal from a, you know, an upside to a commit. Alright. Yeah. Look at that. Almost over.

Sweet. Cool. This loosely is based off of a framework or a journey map. Everyone probably has seen who work in who works in DevRel. I just made a slight variation of this to kind of position it the way that I have tended to approach it, which I think is the spirit of those types of frameworks.

Because in my mind, most teams track what actually happens after someone fills out a form. But by then, dev, our work is almost halfway done in many cases. And to me, that's what the journey this is what the journey can actually look like where community actually starts the conversation, and your credibility in that community is where they kinda accelerate it further in the path. And, importantly, I said this earlier, each of these is trackable, and it it's not always in the CRM, though. And they can but they need to be measured, and we really do need to show that stuff to the leadership.

I I mentioned, as a simple example, UTMs earlier. I know that's one thing that can be used, but we attribute attributing our work to something like I did x with this platform, and then I can put that someplace. I can check a box or I can mark that somewhere that can be actually tracked and reported on is really, really important because otherwise it turns into just, hey. I did a thing this week. Well, I mean, cool, but what do we do with that information?

Yeah. So in in cases like working with sales or sales development as an example, you're not trying to claim the entire deal. That's not really the point. The point is to show that DevRel or community developer community is actually helping make that deal happen or advancing it further into the deal cycle by building trust, solving problems, or getting the right info to the right person. A practical example of this is I I've mentioned common room which is twice.

I've used it many times in this last role I had. One of the things we just built is using the scoring mechanism in that tool. I worked with our sales development manager to create a score that fit how they approach sales development, like their actual methodology that they wrote out. So we built it around that and then created segmentation to automatically filter based off of their team so that all their team members had to do is come in every day and go, click click their name in the list. It was connected to HubSpot so it would only show them contacts that fit the scoring criteria that they would prioritize normally, and they would go, oh, instead of 50 people on a list, there's two.

They'd look at them both and say, great. We set up Apollo sequences, so they check it off, add to sequence. Oh, I they're like, so I'm done? Yeah. And now they now they actually had time for all the other people they were going to reach out to and actually spend a lot of time researching and really craft something unique for that that customer or that person because there was something really important there, they could get almost the low hanging fruit off their plate within minutes and move on.

You know, I it was a tool that did that, but I know, using the tool to solve the problem they were having took a conversation with them and listening to find out, what does your day look like? Like, how long has this stuff taken you? And they would explain it. Someone goes to LinkedIn and looks at this and looks in HubSpot, looks over this box, then goes over to this other platform and looks here. Then they in their mind, they put it together.

I'm like, oh, dude. Like, is just data. Like, there's no reason like, we are a we are a workflow orchestration company. Like, we make automation. That's literally what we do.

There's no reason you should be doing these things individually. It's one example, but we also ended up creating a field in HubSpot in that example where anytime that that process worked the way we wanted it to and they got they booked a demo or they got a meeting set up for with an AE, they would go into HubSpot in that account and just check a little box. And all that let us do is at the end of a month when we were recording, we instead have a dashboard that said, here's how many deals this month advance to the next stage that was influenced by a developer conversation or developer information. It was really simple, but the point of it was the developer community, developer data, and interactions are having a positive impact on progressing the deal cycle. So that was that was a really big deal for their head of sales, and I think that's the type of thing we really wanna focus on.

I'm gonna jump into something that's a little bit more, like, actual practical you can do because I know I've talked a lot, but I wanna get something kinda practical. You can call this whatever you want. There we go. It I put this term up here. Call the meeting or the the situation or the scenario whatever you want it to be.

In person off you know, online, whatever. But the idea behind this is to schedule a regular call or a meeting with the stakeholders who wanna be there and what make it short, shortish, so there's not a ton of time for, like, really in-depth discussion. That's not the point, and I'm I'm saying that for a reason. Because what you want to give them is some key information that isn't just, I emailed you a report. Look at it.

Let me know if you have questions. So examples could be give them the the the attendees of that meeting, the top 30 themes from the community, the top three things that came up in your developer community. And, again, I I I really reinforce that when I say community, I don't mean the just your owned communities, your forums, your Discord servers, whatever it happens to be. I also mean themes from conversations around your product on Reddit, Stack Overflow, Stack Exchange, wherever it happens to be. Also show where that information, those top themes, actually links directly to a company objective wherever you possibly can.

It's not always possible, but you do you really do need to try to link those themes and those topics to a company objective. And then for each of these things you put on that list, recommend one of the following, act, watch, or park. Act, it's aligned. We can move now. We should put it the road map, do something with it.

It's interesting but not yet actionable for us. Good good to know. We're not ready to move. Or park, it's not relevant to the business at this time in our opinion. We can move on from that.

That way, they everyone who's in that call can get a pretty practical idea of what is this data that's telling us we should act on something right away or we should wait, and that can make that can inform their decisions just as much as their own research is doing. And then just coming I I I mentioned some of these earlier. I'm gonna breeze through this pretty quickly, but the idea of we need to do oh, it's not oh, I clicked. We need to both track our work. We also need to be able to translate the value from that work, and that situation I mentioned earlier or just a minute ago about common room and a score and sales development, that's an example of, like, here's all this data I'm seeing, this fit and behavior data I see from a community tool.

But if I just give that to a sales to an SDR, what are they gonna do with that? It's just a lot of numbers. Like, what does that actually mean to them? So, yes, we need to track that information and have it, but it's our job to translate it into something that is meaningful for the person that you talk to them and figure out what it is they're looking for and figure out how do I answer that question or that problem for them based off of the stuff that I've tracked. And that's why I also mentioned things like UTMs and other, like, trackable data points so we can bring it put it together ourselves, and then we figure out what's gonna add value to their day to day, and then that's what we show them.

Key Metrics to Drive Business Decisions

This is the last item I think I'm gonna show, then I'll kinda wrap up. There's another one in here, but I wanna make sure that we're close to time. Yeah. The main one here the main takeaway from this is that these I mentioned earlier it's really important to senior leadership that, you know, we make it important and valuable to them and how they're thinking about the business. So these are the four questions to always be asking when it comes to the work that you do and the products we put out or the content we put out is, does it drive revenue?

Does it mitigate risk? Does it reduce costs? Or does it enable growth? And for me, it's always if I answer any of these questions with either I'm not sure or no, then it's like, well, I could still do this because it might be the right thing to do, but is right now the right time? Because if it's not fitting one of these or answering these questions, maybe we wanna put a pause on that.

So I I think that's I think we all know that inherently, but I think it's really interesting to actually make that a practice that we go through because if we don't do that, then we end up building a lot of things that either isn't important to leadership or really doesn't advance the business, and that's why I think we get into a really challenge response. Cool. The last thing I put on there is the so what test. That's what I was just mentioning on that last slide. It's the so what.

Does it drive revenue of these things? I think that's all the important stuff. Attribution tracking, absolutely do that. If you're not doing any sort of attribution, there's a lot that can be done. Track it, gather the data.

Those are the key takeaways. And then write up business impact report if you can. Either way, cool. I know it felt like a rush. Felt like a rush to me.

But I hope you enjoyed it. If you have any questions afterwards, let me know. And you can follow me on all the socials, Jeff Bull Tech and all the Star Wars stuff that I'll get myself involved in. So thank you, everybody. So