Drafting impact-driven DevRel strategy

Drafting impact-driven DevRel strategy is a topic that’s near and dear to my heart. I feel that there are some optimizations as an industry that folks can make in terms of developer relations as they're drafting that strategy, to ensure that we're prioritizing things correctly and reporting the things that we need to be reporting.

DevRel is like navigating an escape room

I think about DevRel strategy in a variety of different ways. As we engage with one another, we start to talk about our challenges and the things that we struggle with, and I think a lot of us struggle with prioritization and making the right decisions in the right way.

Oftentimes, that comes down to being very strategic and being very clear on what your focuses are, what your program needs to do, what your company needs you to accomplish, and what that's going to look like.

I started thinking about an analogy for DevRel. What’s it like to work in DevRel without a clear strategy? My head immediately went to an escape room.

Inside escape rooms, you don't know what you're doing. You're unsure of what the puzzle’s going to be, but you know that the goal is to get out. So, if we know that our goal is to get out, what are the steps that we have to track back towards so that we can actually escape the escape room?

DevRel is very relatable to an escape room; there’s lots of chaos and trying to figure out how to get out.

And when we get into those escape rooms, we essentially start to think about what the first step is, and the first thing is always action. We’ve got to move forward, go find something, and start to solve the puzzle.

But when you think about that, if everyone's just willy-nilly trying to solve the puzzle and there's no teamwork, strategy, direction, or priority of how you're trying to solve that puzzle or who's doing what, it can feel really chaotic.

You know that you have to get something done, whether it be serving developer users, driving acquisition, or improving customer satisfaction. Whatever that might be, your end goal is to escape that room. That end goal comes from our company and comes from the program needs that we have.

So, if we can pretend we're in an escape room and figure out what we need to do to work through the steps to actually get out of the escape room, or in our case to launch and facilitate successful developer programs, we just need a little strategy and a little bit of togetherness to bring this together.

This is where my DevRel framework comes into play.

Introducing the DevRel framework

I’ve had the amazing opportunity of working in developer relations for a variety of different companies. I’m currently the Head of Platform Developer Relations over at Snapchat.

As I've worked through these various programs, I've helped at companies as a full-time employee, I've also coached and done advisor work, as well as contractual work to come in and build developer relations programs.

I've had the great opportunity of getting to see and follow through with several different programs in different industries, different stages of company and product cycle, different levels of investment, developer first versus developer plus companies, and this is the framework that I’ve found the most success with.

We're going to start with discovery. It's the idea of thinking through, what do I need to know?

Oftentimes, we spend a lot of time in discovery when we first join a company. We're getting to know the team or getting to know the company. We're getting to know their goals and their objectives. What’s their mission? Why am I here? What are we trying to do and accomplish together?

From there, you start to dive into product, you start to understand the product more, and you start to work a little bit deeper in that space. It's all things that we always do when we first get into that role.

Coming back to a discovery stage after you've joined a company can feel a little weird, but it’s something that you should continually be considering because things change. So, spending a great deal of time on the discovery is incredibly important.

From there, we're going to learn a lot, and then we're going to start to draft our strategy doc.

The strategy doc will forever be a living document that we’ll continue to add to at least during whatever timeline you want to build your strategy doc for.

I tend to build out strategy docs on an annual basis, and from there, I have a playbook for our team. We talk about our team objectives, what our team does, what we're skilled at, what we're focused on, and the DevRel programs that we maintain on a routine basis. And that all goes into our playbook.

But for our actual strategy, we're talking about what we’re hyper-focused on and what our ruthless priorities are for that timeframe during our strategy.

So, you're going to start that strategy doc in step two, but you're going to continually be coming back to that strategy doc as you plan, as you ideate, as you work through things, and as you start to improve. You're going to learn a lot and you want to come back to that strategy doc, continually update it, and just make sure that you're always working with the latest information.

And then we're going to get into ideate and plan. Once we strategically understand what it is that we're trying to accomplish, whether it's company goals, program goals, or deliverable goals, we're going to have to come back and brainstorm. We need to accomplish this goal, but to accomplish this goal, what are the steps that we have to take to get there?

In some cases, it might be acquisition. Maybe one of the goals is bringing 100 new developers into our pipeline. They don't necessarily have to register, but we want the opt in. Some type of call to action to share their contact information, email, join a newsletter, join our community, whatever that might look like.

So, thinking about that, if we're trying to bring in 100 new leads, what can we do to accomplish 100 new leads? So it's breaking down those ideas.

A fun thing about developer relations is the ideation and knowing roughly what we want to do from an excitement and a passion level because we’re engineers ourselves, and we really want our peers, our friends, and those that we work with to be happy and successful. We can get really excited about ideating.

I've got some great tips to keep it very prioritized and focused, but it's just such a fun stage of building out your developer program and working through all those ideas.

From there, you're going to plan out those ideas. We'll work through them and then figure out what ideas make the cut and what we’re eventually going to bring into our strategy roadmap to work on.

And then we're going to build and launch. We're going to work on the deliverables that we commit to in that planning phase, we're going to build those out, and we're going to do all the great work. That's where all the magic happens. And then we're going to launch it.

It’s so exciting, but there’s so much that goes into it, like repurposing content and thinking about measurements and calls to action and campaigns.

When we do that, we've got this great work that we want to contribute to, but we need to come around and measure and improve that work.

I know that measurement is such a hot topic in developer relations. I'm excited to tell you my secrets and my tips and tricks in terms of how I think about metrics and dashboards and all those things involving numbers.

But more importantly, I feel that when we look at a lot of these measurements in our work, it provides a lot of information in multiple ways. Is the work that we're doing driving an impact? Is it fully driving that impact? If the idea was that we had to gain 100 new leads, did that idea actually take us to 100 or did it take us to 50? If it took us 50, how do we revamp that idea, improve it, and then get ourselves to 100?

That last step is always to measure, You want that data. Be very data-driven. And you want to improve what you're working on based on the data, based on what you're learning, and what's working or not working.

As a whole, this is the DevRel framework in its entirety. But when you think about it, you're constantly going through this stage. It's almost like a flowchart of a circle because you're going to discover and you're strategizing a plan, and then the next quarter’s going to come around and maybe something changes.

Maybe you've got a new product feature and you have to rediscover the new features or something that's a part of those new features, and then work through this process again and bring that back into your strategy doc.

That’s my high-level view on the DevRel framework that I've adopted, and I’m excited to dive into each one of these steps in more depth.

Discovery: Understanding the company vision and product offerings

As we think about the discovery phase, this is the stage that you want to be spending the most amount of time in, especially in that early strategic, building up your developer program stage.

Discovery is all about learning, research, asking the hard questions, and pushing the boundaries of understanding your company, the product market fit, the products as a whole, your audiences, your approach, and their vision. All the things that you need to understand to successfully launch and develop a developer program.

So, understand that company vision and the offerings, and the competitive landscape. Do research and dive into all of that. Understand the key functions surrounding your team and organization and connect with cross-functional stakeholders.

I can’t reiterate that enough. It’s so incredibly important for your developer program’s success that you're able to communicate, work, and engage with your cross-functional stakeholders in a very efficient and meaningful way.

They can help take you and your programs to the next level, but they can also be hindrances if they don't understand the work that you're doing, what your objectives are, why you're doing that work, and what you're trying to get out of that.

I think it's really important to build those relationships, but also on the flip side of that, just communicate with those folks and really try to think about what their needs are, what they’re looking for, and how you can bring their needs into your developer program.

When you can help accomplish some of the needs of other cross-functional stakeholders, when times get tough or if things get economically tight, they can go to bat for you. When you've got marketing or sales or product who feel that your team is incredibly valuable, that can be really important for us.

Evaluate their current experience by facilitating a developer experience audit. This is incredibly important. And I'm going to tell you as a pro tip, do the audit when you either first join the company or when you're first diving into this. If you don't have the product knowledge yet, you’re going to be in a really great place to see the problems.

When you've been at the company for a while or you've been a part of the product for a while, it's a little bit harder to see some of the hurdles or problems because you see past them. It's like when you're ever looking at a blog post that you're writing, or any piece of content for that matter. Sometimes when you make an error, your brain sees it as correct, and it's not.

Capturing those insights and being able to see what that developer experience looks like from the beginning is just so incredibly important.

So, looking at that discovery phase, it’s all about the knowledge, the resources, the information, how much you can learn about your company, and how much you can push the limits of understanding what folks are working on and focused on to make sure that you're strategically driving the biggest impact.

There are lots of great resources for this phase. I’d say that a discovery worksheet is an absolutely phenomenal resource for you. It's a list of really great questions that once you get through your discovery phase, or as you're working through it, you should have all those questions answered at the end and be able to successfully dive into your strategy.

SWOT analysis is another great thing to do in this stage, and a very common thing.

Setting the strategy for effective DevRel

Diving into our next stage here, which is strategy. Strategy comes into different phases as a whole, but you want to make sure that after you've worked through discovery, especially as that team lead or the person who's building out that developer program strategy, you're able to instill all that knowledge that you just learned to your team, or to anyone else who's going to help you get this work done.

When you hit this stage, what you're hyper-focused on is starting to define things that need to be a part of your strategy.

Target audience is a very important one, and a lot of times, you can work on that with marketing, which is really great. But start to define those target audiences. Who are you going after as a developer program? Of course, we know that it’s developers, but it's about languages, focuses, and missions. What are they motivated by? That's a big thing that I like to bring into my personas and segmentation.

Understanding your audience before you get into this piece is incredibly important so that you can start to build out those segmentations, personas, and messaging that you want to use to target those users.

You want to deeply understand your company objectives and goals when you get to this stage so that you can start to develop an understanding of what your company is going after and how your developer program is going to contribute to that, as well as thinking about what your developer program objectives are.

I actually set objectives for my teams when I join a company, and it's based on my job description, the discovery phase, and a lot of conversations that start with, “Why am I here? What is it that I'm here to do?”

Our team should always be thinking about kind of those north stars. A lot of times it's ‘scale the community’ and ‘improve things.’ It depends on your situation.

It's really just about, why is your team there? And what are you hyper-focused on doing within your team?

If you're building a team and you’re bringing in additional folks that are going to be on your developer relations team, what’s that going to look like? That's a really important piece of it as well.

Strategically, where are the places that you're going to be putting the biggest effort in? Are you going to be doing a net new community? Is that something that you need a community manager for? Or someone to lead and moderate and nurture? Are you on that side of getting those resources out there and improving the developer experience?

There are different focus areas and different offerings and programs that come out of that, so it's really important that you’ve worked through that discovery phase and truly understand what’s necessary in terms of your team to be able to understand what you need to build out.

If you don't know this right now, maybe you need to go through the ideation and planning phase. You might have figured out something like, “We absolutely need to host meetups. We're going to do eight different locations, it's going to be our early outreach, and we’ll start to build up brand awareness.”

Thinking about some of that stuff is also about how that comes back to strategy and how you make sure that those things happen, and how they’re effective and impactful.

As you start to get into the strategy phase, you're going to start that strategy doc and you're going to end up coming back to it. And we'll get to that in one of our next stages here.

Ideating and planning for DevRel programs

Now we're going to ideate and plan. We know what our goals are, we know what the company needs from us, we know what our team is going to look like, what our developer program is going to look like, what those objectives are, what our developers need from us as a company and as a team, and now we're going to start to ideate.

The biggest, most helpful thing for me is understanding the objectives that we're going after, and then understanding some of those individual goals.

If one of the objectives is to improve our customer pipeline or our developer pipeline, what needs to happen to improve that developer pipeline? Is it a matter of outreach? Advocacy? Marketing? Or is it a matter of, “Hey, you know what, we're just not going after the right fit. We need to reevaluate our target audience.”

It’s thinking about those goals and understanding what we have to get done. It'll make ideation so much easier.

Coming into ideation, you should have clear goals and clear objectives to be able to say, “You know what, these are going to be our big brain ideas. If we want to bring in 100 or 1,000, what do we need to do to make that happen?”

Dream big. If there were no budget limitations, no security protocols telling me, “No,” and no resource limitations, what would I do? That can be such a fun and liberating exercise and something that you should continually maintain.

As you start to build out your program, go back to your ideation and brainstorming from seasons before and say, “That idea seemed crazy at the time, but now I can actually do it because the team size and the budget are there.”

Once we ideate and work through that really fun exercise, we want to start to narrow that down because sometimes when you're thinking these big brain ideas, the ideation can get a little out of control in a good way. There are so many ideas, and DevRel and software engineers are problem solvers. When you bring our types of people together, we end up with some great things.

So, long story short, we want to narrow and sort those ideas. We want to do that based on goals, and we want to do that with the effort and the impact matrix. If you've never used that matrix before, it’s an incredibly important matrix.

When you're thinking about your company goals and what you're trying to accomplish, I go back to our ideas and I start to associate a goal. Is it going to accomplish one goal, two goals, three goals, or all the goals that we might have for our program?

Something that accomplishes more than one goal is going to be ranked higher than something that only accomplishes one goal. So it really starts to naturally prioritize your list of ideas.

Thinking about the impact versus effort matrix, it's all about how much effort this is going to take me versus how much of an impact this is going to make.

If something is high impact and low effort, that should rise to the top of your list because it’s something you can likely make happen in a minimal amount of time if you've categorized it as low effort, but can drive a great impact for your team. And those are the wins that you want to leverage whenever you can.

So, as you're ideating, think of those things. What goals is it going to accomplish? What's the effort involved? What's the impact of the activity or idea?

Once you start to define the work that you'll do, then you can start to plan that out. So when you're going through and sorting and filtering and starting to prioritize those ideas, things are going to naturally rise to the top, and those things will just become a very clear place for you to start to plan.

Coming back to that 100 devs into our pipeline situation, we've landed on the idea that we need to accomplish 100 devs, and we're going to do this meetup roadshow idea. By the way, I'm not saying meetups are the thing to do, I'm just giving you an example.

If we take that example and start to pull that apart and define that work, that's when we get into that planning phase. What does it take to make that thing happen?

If it's meetups, logistically, there's probably a planning doc and there's going to be a project plan. In that project plan, we're going to reference our strategy and our playbook, and we're going to come back to the things that need to be reiterated in those other documents. But we're going to be very clear with our project and our plan about what we're doing and what we're going to accomplish out of that.

This is where I strongly recommend that folks pick up a project management system like Asana, Jira, or Monday. Whatever it might be, bring it into a project management system so that you can start to see some of these things and you can sort by some of those criteria.

And then, of course, we're going to add our plans to our strategy doc. Inside of that strategy doc template is a roadmap section. I do a roadmap kind of view because I like to say, “Hey, here's what we're doing now, and here's the future,” and then I align that back to my objective. So my roadmap might look like A, B, and C objectives, and the things I'm going to do to contribute to those objectives below.

You're going to bring all that back into your strategy document. I find it to be incredibly successful when I can integrate the project management, my strategy doc, my plans, my ideation, and my playbook. Think about these resources and documents and the solution that can help keep you prioritized and on track.

In DevRel, there's so much work that we can do, so it's very important that we’re hyper-focused and prioritizing everything that matters.

Building and launching: How to make the magic happen

Now we're going to go into building and launching. Not all of us are technical in the developer relations field, but we understand software engineers and we understand conceptually the idea of building and launching and being able to accomplish something and get it out into the world. This is where we shine.

But sometimes, when we think about things from the engineering side, we miss things that we really need from that DevRel side. We want to make sure that when we're building and launching, we're also communicating our plans with all of our cross-functional stakeholders.

It’s not necessarily just communicating it like, “Hey, we're going to do X. It's more about getting in the weeds of those details. For example, “Hey, marketing, we're doing a meetup roadshow and we're starting to pull together a campaign for this because we want to market and drive registrations to this meetup roadshow.”

Communicating your plans in a technical space feels different from communicating your plans to cross-functional stakeholders. So really think through that and consider that.

Repurpose your content. If you write a blog post, turn that into a short-form video, and turn that into a long-form tutorial.

What does the blog post cover? And can we expand upon that? Can we turn it into an educational piece? Can we cut it apart and pull different quotes out and turn that into social content or content that you put in the community forum? Can you shift over the verbiage or the focus and bring it into a forum and turn it into a conversation or drive engagement with it?

Think about every single thing, not just content. Think about every single thing that you work on and how you can repurpose that.

Thinking about our meetups, what can we do with meetups to repurpose them? Can we record the sessions? Can we share those in the community? Can we get feedback inside of those meetups and then share that back out with community members who can expand upon that feedback?

There's just so much that goes into that repurposing, and I love to challenge people to truly think about how you can take a deliverable and make it more impactful.

Check your wins and accomplishments. I know that this is common sense, but the thing about DevRel is that it's always about doing this so I can get to this so I can get to this.

So, as you’re starting to think about that, sometimes you can stay hyper-focused in the stage that you're in and not actually see the greatness that is what your program is doing. As we know, sometimes it's just constant relationship driving and constant connections and touch points with our prospective developers, and we don't always know when that lands.

Just make sure that you're tracking your wins and accomplishments as you see them, as they come across your plate, and making sure that those are being communicated.

Develop a campaign mindset and drive the greatest impact from your work. I know that the campaign mindset comes into play for marketers, but here's the thing - when we're doing these deliverables, we're creating this content, and we're building something, how are we going to get this to the world?

I know that a lot of DevRel teams struggle with this because when you come from a technical nature, you don’t think about campaigns, you don't think about marketing, you don't think about all the things that go into that. So, start to develop a campaign mindset and work with marketing and the folks that you have around you to teach you what that means and how you can bring all of your deliverables to life.

The one thing that I want to drill home is associating your call to action. Whenever you’re doing any sort of work, whether it's a meetup, roadshow, or a blog post, you need to have a call to action.

If we're going to have a meetup roadshow, we've decided that we need 100 developer leads, so email addresses, contact information, and whatever leads that we can communicate, nurture, and engage, that's our call to action.

When you think about meetups and those folks coming in, you might accomplish your call to action through the registrations because everyone's going to provide their email address, and then those are the leads that can go into those 100 leads that you're bringing in. So your call to action for this is actually registration.

Let's think about a blog post where we're trying to shed some light on a new product feature. When you think about that kind of blog post, the call to action in that case is for them to go and use that new feature.

So, if you’re thinking about the fact you wrote a blog post with thousands of views on it, that doesn't matter. Who cares if someone looked at it if they didn't take action? So, if somebody looks at the blog post, then takes action and goes to try out that new product feature, that’s something that you measure and that's what you want to share because that's the true impact of your work.

Measuring and improving through calls to action

Here's the thing - we can debunk this whole thing with our CTA. I understand that conceptually, we're going to report back to our company objectives, we're going to report back to our program objectives, and then we're also going to report to our work and our objectives. So, that blog post or that meetup roadshow that we're talking about.

Coming back to that blog post, what's the CTA? Did they use that new product feature or did they not use that new product feature? This is where we’d debunk it. It's very clear that when you leverage a call to action as the unit of measurement for your success, it becomes so clear how you're going to measure that.

Our overall goal is 100 developers bringing in contact information that we can nurture into that pipeline. That CTA for our blog post, or that meetup roadshow, if we're going to go back to that example, is registration. They need to register, you need to capture their email address, and that's your CTA.

So, when you come back around to measuring this effort or this kind of deliverable, it’s you speaking back to those 100 devs that you're trying to accomplish in that case.

You've got that work, and you want to say, “The meetup roadshow brought in 75 of the leads we wanted, so we had to supplement that with another deliverable or a blog post to capture those remaining 25 leads.”

You report that in your actual work, but in your developer program, you're going to share statistics and metrics because one of your big goals is to bring in those 100 leads.

Then, for your program, you're focused on the metric about the 100 leads, and for your work, you're focused on saying, “We had X number of registrations because that led to leads that we captured.”

And then you're going to leave that up to your company. Your company's at the top, so whatever your company goal might have been. Maybe it's a new company, so it's a very vague goal of raising awareness in the developer ecosystem in a very niche industry, a very niche product offering, a very niche language, or whatever it might be, and working through that.

It becomes very clear that regarding registrations for our CTA, we've got these leads, and that's what we're reporting for a developer program because we're going to continually care about the leads that we bring in. And then on a company level, it's an overall company goal to start to build awareness in the developer ecosystem.

We can use the same metrics for other work to say, “Hey, here's where we're at in terms of building out that developer ecosystem. We committed to 100 devs, we've accomplished that goal with these different deliverables, and here's the CTA and the work that made it happen.”

I know that it isn't always that easy to track these things, but it can be when you really think about things in this way and you're working through the DevRel framework to make sure that you've got all the information you need.

You've strategically planned, you're hyper-focused on the work, you're building super efficiently and making sure that you're repurposing things, and you’re being very impact-driven and data-driven in your decisions to prove that impact.

DevRel is no easy function

So, it's that easy, right? It’s just the simple five steps to make your developer program wildly successful. Of course, you know, I know, and the world knows that I'm definitely joking.

It's not that easy. Developer relations isn’t an easy function. There are so many bits and pieces that we think about. There's always something to do, and sustained hyper-focus is just so incredibly important.

Get your free copy of the Developer Relations playbook for insights, tips, and know-how that'll help you enhance your relationship with your technical audience.