Untangling DevRel: Using Network Graphs to Tell a Story

Kourtney: Awesome. Thank you all so much for being here with me. This talk has been kind of a very long time in the making, so to actually be here and sharing it with you is I'm I'm just so grateful. So, yeah, let's dive in. I'm gonna be speaking about untangling DevRel using network graphs to tell a story and please do not worry if you're like, I do not know what a network graph is, that's really scary.

You actually probably do, but I'm gonna explain the basics, so no need to fear. For those of you that I don't know yet, I'm Courtney Meese. I grew up here in the Northeast over in Massachusetts, but I've spent the last eight years in Austin, Texas. I have been a developer advocate at Box, Traceblank, and as was just mentioned, I'm actually starting at Amazon on Monday. So really excited about that new journey.

And then this is my second year at DevRelCon, but my first year speaking. And outside of work, I am a really avid reader and I have a million houseplants. So if either of those of you are your thing or you just wanna chat about the cool stuff you're doing, let's nerd out together after this. Come find me later today. Okay.

So let me give you a quick summary of what we're gonna cover. So first, I'm gonna give you a background of how I got started on this idea and some existing models that I explored as a foundation. I'll talk about the gap I saw with those models that led me to develop my own, and then give you that quick overview of network graphs, the basics you need to know, and the uses I see for implementing the model and some next steps I'm gonna be working on in the future. Okay. So when I started at TraceLink, their platform just launched and the DevRel function we were starting to build from the ground up.

And in those early days, we were really uncovering a lot of things that needed to change. And those ranged from like back end pieces of the architecture to product features like tokens that needed to exist before we could even like think about putting something in front of a developer. And so I started asking this bigger question, which is what would a company need to think about as early on as possible to set DevRel up for success later on? So that we wouldn't have to come back and spend time making all these changes and we could get to work. So I wish that I had had a model to answer this question, but instead, I thought about something my dad used to say about problem solving when I was growing up.

And that's a quote by Stephen Covey, begin with the end in mind. And yeah, that seems so simple but we often forget to do it. So I started mapping out everything I could think of. What would the most mature program look like and what are all behind the scenes activities that would have to happen to build that mature model. So then the state of DevRel 2024 report came out and it validated what I had been thinking.

So as I began to map all this out, I was realizing, wow, like, this isn't just a tool for planning, it's actually a way to visualize the impact of DevRel. Like especially when we were working with leadership and stakeholders who don't work in the day to day. They maybe never even worked with a DevRel team before and they just like really don't know what they don't know. So if you're not familiar with this state of DevRel report, it's by DevRel agency. It's probably one of the most widely referenced surveys in the field and it reports on things like how are teams structured, what are they focused on, what challenges are they facing, and it found that 61% of DevRel professionals were were saying that they were finding it difficult to prove their influence.

Half were struggling to raise awareness about their contributions. And then for the first time, proving business impact jumped to the second largest challenge. So if I built a model, maybe it wouldn't just be useful to me. Like, maybe there were people out there that wanted to prove their impact and ultimately make their work more visible and more valued. Alright.

So I didn't wanna pour any more time into this if it had already been done. And there was a piece of me, like, kinda hoping I was gonna find it. Unfortunately, that was not the case. I had asked, is there a model out there that visualizes the internal structure and impact of DevRel programs, especially as they mature and grow over time? And again, what I found was no.

No one that I could find had done exactly that before. But what I did find were a couple existing models that had pieces of what I had been thinking. And they didn't tell the whole story, but I could I could take the pieces that I liked and make something else. So the first one I'm gonna show you, you're probably familiar with. This is by DevRel Agency.

It is the developer journey map, and it takes stages of the developer journey and maps them to touch points. So if your program was just getting started like ours was at TraceLink, this was a really helpful tool because it made sure that we were prioritizing the right touch points early on, and then as the program matured, we shifted to other touch points. And then here is the also by DevRel agency, the develop Mind the Gap Developer Journey Tube Map. It builds on the last framework I or model I just showed. Oh, no.

Okay. But love that. Okay. So this one's the same, has the same touch points, but it adds a layer of complexity on top of it that shows that the developer journey isn't actually linear like the last one. So developers can enter at any point that you see, they can take different paths, they can jump between the tracks as their needs and the journey progresses.

So this was honestly a really valuable model that highlighted that nonlinear journey. And then the last one I'm gonna show you is by Sean Wang and it talks about monthly active developer metric. And this argues that your North Star metric should not actually be monthly active developers. Why? Well, that's a lagging indicator.

It's multi causal and instead, you should really be focusing on what you see on the left hand side of your screen, which are leading indicators, and those are things that you can have more direct impact on. Okay. So all of these models I just showed, they're really great. They have a time and a place, and I've referenced them very often. But the problem was is that I felt like all the internal functions were missing from those models.

I mean, there's cross functional collaboration that has to happen. There are dependencies. There's foundational choices that have to be made. There's maturity over time, and the team ownership of all those things that have to happen. So, again, I did wanna highlight that the path is nonlinear, but it is interconnected.

So I made my own model. And the goal is to visualize that internal structure of DevRel and impact as the program matures and grows over time. I'm calling this the worm model because it visualizes work streams, ownership, relationships, and maturity. And as cute as this little guy is, this little Texas worm, I had to decide like, okay, what's the model actually gonna look like? So I was brought back to my middle school days.

Our teachers would have us make mind maps, which you'll see on the left hand side of your screen. And what you'd have was your central topic in the middle, then you would branch out with your related ideas, and we did things for essays when we had to break them down. But I knew that wasn't really gonna cut it. This is what DevRel looked like in my head. You had your central function, and then you branched out with all the teams and things that you were working on, but DevRel doesn't just branch out, it's actually more like a web.

It has to go in all directions. And so that brought me to network graphs. This is a network graph. Might not have known it was called that, but you've probably seen something like this before. And these are structures made to show exactly that kind of complexity.

So three main things you need to know about network graphs that are important. The first, we have circles that are nodes. These represent individual entities. We have edges. Those are lines that connect nodes to each other and show interaction or relationships between two nodes.

And finally, have direction. Those are the arrows on the edges. They can be bidirectional, and they show the direction of the relationship or the interaction. Okay. So I'm gonna reveal my model now, but I do want to give a disclaimer.

So this is going to be the worm model I built at TraceLink. This is not a one size fits all model because we all know that DevRel one size fits all is actually impossible. So the goal here would be to tape what I show you, use it as a template, and then adapt and remix it for your enterprise, your needs, your goals, your challenges. I will give you details at the very end of how to access this presentation, images from it, the templates at the very end. So the goal, because things are small to get it all on the screen, don't worry about all the details.

I'll point out exactly the high level things I want you to look at. But I want you to get a really good look at the the general overview and structure. Okay. Here it is. This is what you've all been waiting for.

Okay. So this is the first variation that I built while I was at TraceLink. You'll see it is color coded into the high level categories which are listed on the right hand side of your screen, and this represents not just activities that we were doing, but this was me mapping like the most mature version of our program that I could think of. So we were involved in conversations about the business. So like, what target personas do we have?

What's our strategy for the platform? What's our partner program gonna look like? But we also needed to be involved in really technical conversations, like, what authentication methods do we wanna support? And like, how are we gonna handle our API versioning? So in the early days, we didn't have metrics.

Like, there was nothing that we can meaningfully really report back on. It felt like we weren't moving the needle at all, but we were. Like, it was just invisible, all these really important conversations that we were having. And that's where this model came into play because we started to be able to visualize it to people that we were making progress. Okay.

So this is the next variation of the model. So we took the base model, and then we added another layer of health and status to it using color coding. So you'll see I used a tool to create this called draw dot I o. Super easy, intuitive, and free. But there's a lot of software out there you could use to recreate this.

But what I love about that tool is like it's super easy to go in and really just edit like the colors of each individual nose quickly. But for example, anything that we had released, it was in a stable place and was just like entering a maintenance mode, we put in green. Yellow was for things that were in progress. And then anything in red, blocked, needed attention, and white was just like, we haven't even touched or started it yet. And one important conversation that you have to have if you're using this version of the model internally is like, okay, well, what are the what are the criteria that nodes need to hit in order to move from one color to the other.

But this became a really great visualization for our leaders and any internal stakeholders so that they could we could put this on a slide and one glance gave them a really high overview and insight as to how things were going.

And then, here's the last one I'm gonna show you. The color coding shifts again but this time in navy blue, we put things that we were targeting for that quarter. Green represented anything that was already done. We had our yearly targets moving forward in yellow, and then I do wanna call out anything in gray was things we weren't targeting. And this is arguably really important because it helped us it was a forcing function.

It helped us have really difficult and often like challenging awkward conversations about like, okay, well, in other mature programs they have this, but does it really make sense for our program to have that? We could revisit it at any time. Mean, we just had to go in and change the node's color if our program got more mature and it started to make sense, but we did want to document that a conversation had been had and we made a decision on it. So this version really became our North Star as we were planning. Okay.

So if any of this, like, resonated with you, you want to spend more time digging into the specifics, I've made the full presentation, all of the images and downloadable templates available on my GitHub. Just scan the QR code. If you do use this model or you even just like sit with it for a bit and have some thoughts, would really love to hear them. What made sense? What didn't?

What did you have to add or change? I really think that this kind of work, it it only gets better when you share and you use it in the real world. I wasn't intentionally gatekeeping this but what better place to release it than here. So I know that this is not the final answer. Criminally, like AI is not on the model.

So like, I have work to do. I know that. But I would love to hear at different types of organizations, like, I've never worked at a marketing centric dev rel function. So I know that's fundamentally going to change the model. So what are what do you guys think about that that I haven't had at previous roles?

So please, there's a bunch of contact information on the GitHub, like, please reach out and share that with me. A couple acknowledgments I wanna make. If you know Jonathan LeBlanc, he is really wonderful. He got me into DevRel and gave me some really awesome feedback on this presentation and force kind of gently nudged me to release it and give it to all of you. So shout out to him and also Chris Tirano's, he's my next manager and he also gave some really great feedback as well.

I do wanna highlight some next steps that I'm thinking as I build this out further. So I do wanna do a deep dive into each cluster of those main clusters you saw on the original model. You'll see I only went from the main node down one level, but it could have continued to go deeper and deeper. So I wanna give a breakdown on those of, like, at the three companies I worked out, like, what have I learned about each of those areas? And I think that could be helpful to share with others.

So I wanna do deep dives. I also, as I said, like, I wanna showcase the different flavors of DevRel and have templates for each of those to showcase how that changes things. But, yeah, if you are in the early stages of building a program especially, I would love to chat. If you need a sounding board or have any ideas that you wanna run by someone, I I would love for you to reach out. Again, my name is Courtney Meese and you can add me on LinkedIn.

But thank you so much for your time. I appreciate it.

MC: Thank you, Kourtney. We have a couple of minutes if anyone has any questions for Kourtney.

Audience member 1: Can we go back to the slides, the network graph, your network graphs? Yes, that one. So can you speak just a little bit to the different sizes of the bubbles and how you organize that, please?

Kourtney: Yeah, so the largest let's see here. The largest bubbles you'll see are the main areas I broke it down into. So these are all listed right here. Anything that was, like, slightly bigger was just one level deeper but had these these other nodes. So, like, example here, we have architecture and we had to talk about authentication and authorization.

And then one level deeper was all of our options that we had to say yay or nay to for authentication. So it really outlines kind of the the higher level topics that you wanna make sure that you might not be owning, but you need to have a conversation about and make sure that you are connected with those people. So again, like, the idea here is that when you're starting the program or or somebody is starting a company period and they wanna make sure they're looking forward to set you up for success, you can have these these conversations as early on as possible. So you don't have to go back and fix things and, you know, waste some time. You can just jump right in and get started.

But again, I would love to go more than three levels deep because all of those, like, I could have dived into. But I was like, wow, like, visually, no one could parse that and then eventually it would mean nothing. I was admittedly, I was really hoping to make a model that truly is that visually complex just for like the shock factor of like, look at the mess that we deal with. Like, now you can see it and like, clearly, like, we're valuable because we do all this and if you don't have somebody doing it effectively, like, how is all this working? So

Audience member 2: Hi. Sorry. I really love the focus on the internal activities of a DevRel team. It is often overlooked. But sometimes, those activities were way more an influencer than an owner, to your point that you just mentioned.

Like, we clearly own the webinars or the events. But when it comes to those internal activities, you know, we're we're nudgers as often. Or, so is there any challenge with listing a bubble for something without kind of over claiming responsibility and how do you like walk that line?

Kourtney: I think, yes. Like, that's always going to be a challenge. One variation that I haven't created but I have thought about is, like, doing another color coding for different teams and what they own. So you could, like, show that to leadership and and break it down for them or even for just stakeholders that, like again, it's not just leaders. It's like people like have never worked with DevRel and they're like, oh, I thought I thought you just like wrote some documentation and like that's all you owned but like no, this is this is everything that we have to touch.

So one idea I had was was to do a version that break breaks down the color coding. But I think like that does raise an interesting point to make sure that when when you are having these conversations, like, we're not trying to necessarily own all of this, but, like, there were conversations, so at TraceLink specifically, like, if you don't know what it is, like, it was pharmaceutical supply chain software and they had they were an interesting setup, say this one side of the business that was successful and profitable, and then they launched their platform and they were using that success to, like, pour money into this, like, experimental piece. And so, you know, people were, like, set in their ways, and like, they already had all these conversations and they didn't even realize when we came on board that like, we needed a seat at the table, and we were now bringing like a new perspective in, and like, again, we didn't wanna own it. But like, needed to be able to report that we've made the connection, we are at the table, we're making progress with it, so that, you know, you do bubble that up to leadership and say, like, I was in this really important conversation, and, like, you're not gonna hear about it really anymore from me, but, like, I'm there and I'm important.

And that's, you know, really what I'm hoping the model does because we we use this at our North Star. And so every every time we met with leadership, we'd include this in our decks, made this the standard for what they were gonna see. And it it significantly helped us have conversations. Think we might have time for one more.

Audience member 3: Thanks. So just picking up on the theme of ownership and things like that. Maybe comment on this version of the slide on timing and, you know, kind of how your team picked what to work on this quarter and why some of the, you know, external nodes got worked first?

Kourtney: Yeah. So one thing I did not touch on is really the fact that you kinda have to work from the outside in. So like your central nodes, like you have to have a lot done before you can mark that central node as like everything has been released and functioning. So it does really work outside and then down to the bigger nodes. This is kind of where those other models come into play and help you decide like, okay, what stage are we at with developers and and which things do we need early on?

So that's why I said like, other models are useful and have their time and their place. And luckily, like, Jonathan was was my manager and leader at the time and he has years and years of experience in DevRel. So we we had worked together previously and we had a good idea of like which touch points were kind of low hanging fruit. Like what could we move the needle on to show leadership some easy wins that we were, you know, proving our value and that we were gonna stick around for a couple years and I think one thing that really I love about this version is I could have honestly we could have sat down and put twenty twenty six targets, twenty twenty seven targets. When we talked behind the scenes, were like, wow.

We have five years plus of work that we could outline right now that we know is going to happen. So when we were having those conversations with leadership, it would have been awesome to put in front of them like, hey, I think that you think that we're gonna be in a great place in maybe a year. That's definitely not the truth. Things are moving slow because we have to have all those conversations and all those cross functional collaborators that have to get in line and work on things and release products. So just giving them that that high level overview.

But, yeah, picking was really using relying on other models and then also just our our previous knowledge about what what we could move the needle on and what was ready. Mainly at tracing what was ready. A lot of the product was not, so that made it that made it kind of easy.

MC: One last one.

Audience member 4: You. Have you thought about, like, how this intersects with, like, Sean's model or the other ones as well? Because, like, I feel like this is a lot of the internals. You captured a lot of that but like the external things like and I can't quite read all the text. So maybe it's there.

Kourtney: Totally. So while this is, like, I want to make clear the internal functions, there are external functions on here too. So let me go back one really two really quick. So for example, like, dev tools okay. Maybe not working here.

But for example, developer experience over here, we have Outreach. So we have blogs. We have we have our API reference. We have newsletters, all of that. So those pieces are included because again, you're having internal conversations about them like even if you haven't even released a blog post yet, you're creating strategy, you're having conversations, work is being done.

So I think by nature, like, hopefully, all of the externals also included in this model. But yeah, really meant to have those internal conversations.

MC: Alright. Thank you so much, Kirti. Let's give it up for Kourtney.