Made by
Made by
Naomi Pentrel
Naomi Pentrel, Communications Engineer in the Office of the CTO at MongoDB, created an open source resource to help teams define dev rel strategy for their products. In this talk from DevRelCon San Francisco 2019, Naomi walks through the key steps in the strategy planning process.
I’m Naomi. And until quite recently, I was a developer advocate at MongoDB, and before that at mLab. Right now, I’m a communications engineer in the office of the CTO, still at MongoDB.
But I’m not actually here today to talk about myself or the teams I’ve worked on, except where this is going to help you in planning your team’s dev rel strategy. And that is the title of this talk. And before I continue, I’d like to say that this is not a talk that targets team leads in particular, it is really for any dev rel practitioner.
So I’m going to take the about 19 minutes that I’ve got left to tell you a bit more about this, starting with why you need a well-defined dev rel strategy. Then I will tell you how you can go about creating one. And last but not least, I promise that you will leave here with a set of resources that will help you on your path to defining your dev rel strategy.
So let’s jump right in and talk about the reasons why you need a dev rel strategy. When I joined the two dev rel teams that I’ve been on, the first thing I’d always do is I’d ask, “Okay, what are our goals? What are we trying to achieve? How do we pick which events we go to?” And things like that.
And part of the reason I do this is because I get somewhat anxious around whether I am doing my job well, and whether I am doing what I’m supposed to. And part of what I’m trying to avoid with that is that later on at some point stakeholders might say, “Hey, we actually wanted you to do this thing and you never did it.”
And if I wasn’t told that they expected me to do this thing, that’s not great. So I try to ask for expectations and make all of this very clear. So why I need and why I care to have a well-defined dev rel strategy is that I need clarity and alignment across stakeholders, which then makes me a lot less anxious.
A side effect of this is that this clarity and alignment across stakeholders makes the value proposition of your dev rel team very clear.
The second big reason is that having a well-defined strategy and knowing where you’re headed can increase productivity and can make you have a more targeted impact, because you know exactly where you should be focusing your time and what you’re trying to achieve, that way you know what to prioritize and what not to prioritize.
And this need for a strategy that I feel is a common theme. So, if you look at Hoopy’s the State of Dev Rel report, they actually looked at what people think are the biggest challenges in dev rel right now. And they found four major things.
And one of them was strategy and measurement. And about half of the quotes on this page are about strategy, my favorite one being on the left side in pink, the one that says, “Figuring out what the hell we are doing,” and I found that quite entertaining. But this wasn’t the only bit where strategy was mentioned in this report.
So, in Phil Leggetter’s opening, he spoke about who defines a strategy. And what he says is, “Many leaders and businesses now understand the need for developer relations. However, there still seems to be a lack of understanding with what the business actually needs from an individual or a dev rel team. And everyone seems to be looking for a director, a VP, or a head of developer relations to define the strategy.”
And what I’d like to add to this is that I don’t think you actually necessarily need the leader of the team to define the strategy. Ideally, you want your entire team to work on the strategy together, and I think that’s very important. Now I realize Phil doesn’t actually say that this should come from the director of dev rel, but I think that’s a very important thing to keep in mind as we talk about this.
The other thing that Phil says is that it’s already quite difficult to hire developer advocates. Hiring someone who also has the expertise to define strategy is even harder. And to that, I’d like to say, hopefully, after this talk today, you will have the resources to define a strategy and get started with that.
So, let’s jump right in and talk about the steps that you would probably go through when you’re defining a dev rel strategy. And those are about five steps, give or take, and depending on what your team is like, you would have to adapt these.
But the first one is probably getting to know your product very intimately. And with that, I don’t just mean knowing it well technically. What I mean is more getting to know the strengths and weaknesses of your product, knowing the competitive landscape of your product, and things like that, so it’s a bit more of a deeper analysis of your products.
The second step you would then go through is analyzing your team, actually, and the initiatives that your team is responsible for. By analyzing your team, I mean, just knowing who’s on your team, where they’re based, what languages they know, what programming languages they know, and what their aspirations are.
If no one on your team knows PHP, or Python, or some other language, and later on in this strategy definition session, you figure out, “Hey, we really actually want to be focusing on PHP,” then you’ve got some issue there to address, so you need to keep that in mind.
The second part of this is knowing your initiatives. So, what I mean by initiative is either a defined project or something ongoing like your hackathon sponsorships, those are sort of initiatives that I mean like that.
And what you’d be doing here is you’d just be taking stock of all of the initiatives that your team is responsible for, or was at some point. And that could be quite a few. And it’s just making sure that you’re aware of what you actually have, and also talking about how well things are going with those, whether there’s any ideas for improvements, new ideas for new initiatives, etc.
Then the next step is to define overarching themes, so setting the bigger, long-term goal that you’re trying to achieve. And then going back to the initiatives you discussed in the previous step, and making sure that those that are aligned with those themes.
Step four is to define an event strategy if you are a dev rel team that does a lot of events. And that then goes through creating some selection criteria based on which you can decide which events you should actually be going to and which you shouldn’t be going to.
And the last step is setting SMART goals, and that is sort of on a per-initiative basis.
So, this is actually quite a lot to do. And if you’re going to discuss all these things in a team setting, someone on your team is going to have to prepare this, and prepare resources and materials for your team to have something like a planning session. And that can easily take you upwards of 80 hours.
And I can tell you that it takes that long because I did this for the MongoDB team. And when I was doing this, I did this in a way that would make it easy to share with the community. So, what I created is I created a GitHub repo called DevRel Strategy: Step by Step. And this is an adaptable framework for preparing a strategy planning session for your dev rel team, and it’s available at bit.ly/planningdevrel.
Now, a lot of the things that are in this framework are based on materials that community members prepared, and this is, of course, pointed out where it’s adapted from. One of the very big things that helped me in creating this framework is Hoopy’s phenomenal dev rel training. And if you haven’t taken that, I’d really recommend it, it’s really very good.
And the other people I should probably thank here is the MongoDB dev rel team, because they were sort of beta testers on this and they gave a lot of feedback and stress improvements, so it’s now actually already version 1.1. So all of these resources were already out there, and this framework really just aims to make it more easy for you to put it into practice.
So what I’m going to talk about next is the outcomes you can expect if you were to use this framework, and then we’re going to go through each step and talk about what you’d be doing in those steps.
So the outcomes you can expect is a written assessment of your products, written documentation, and an analysis of your current initiatives. Defined themes for the upcoming months or the upcoming year. Defined strategies and goals for each initiative, and a written overview of where your team sits in the organization, what your responsibilities are, and what the scope of your responsibilities are, and especially what’s actually not your responsibility.
So, getting started with what the framework looks like, this content that I’ve put together is split into different steps. Each step has a folder, and in that folder is a README with some information for you that contains the outcomes for each section, an intro, some tasks for you to do to prepare, and the exercises that you’re going to be going through with your team or alone. Some notes, and then the resources and sources where this material came from.
So, the first step is, know your products. So, the tasks that you’d be going through here, the first one would be sitting down with your team and drawing up the org chart for your organization, and thinking about what teams do you rely on, what teams you generally work with, and what their goals are, and their dependencies, and things like that, and checking just how you interact.
The second thing is you’d be going through product analysis. And for that, there is a template in this folder that will ask you a lot of questions on a per-product basis that you’d be filling in about the product itself, competition, your company, the climate, and in the end, hopefully, you’ll gain insights about some interesting segments and target audiences that you might want to focus on in the coming year.
Step two is getting to know your team and initiatives. So the first thing is going through some team intros, of course, there’s a template for that too, and your team would then be filling that in. A cool side effect of this is that you’d then be able to reuse those for things like conference bios.
The other two tasks that are in this section is going through the history of dev rel at your company. Someone who has been at the company longer should probably prepare the session and just either present it or lead the discussion on it.
And then, and actually very, very cool part is, you then go into talking about the initiatives your team is doing or has done. And that starts with you just figuring out a list of all of the initiatives that you’re doing. And then once you’ve done that, going through them individually, and sort of thinking about what the health of that initiative is, whether there’s any improvements you could do, etc.
So this is the template that you’d then be filling out. It’s not at this point important that you fill in everything, but at the end of the planning session, hopefully, you’d have these coherent documents that have info about each initiative that your team is responsible for.
So, and the last step is talking about new ideas that your team might have, and then just also filling in an initiative document for those.
Then step three, says that is defining themes. And the tasks that you’d be running through here is looking at company goals, looking at Phil Leggetter’s AAARRRP funnel, articulating themes, articulating a mission statement for your team if you haven’t yet. And lastly, once you have these themes, and the mission statement, making sure that all of the initiatives you talked about in the previous step actually align with the themes of what you want to be doing in the coming year.
Step four then is defining an event strategy. And this is starting with some general selection criteria for you to think about, and then defining your own selection criteria based on your team, and in then the end generalizing that into your event strategy, so that you essentially have something like a flow chart where you can just decide, “Am I going to go to this event? Does it make sense for me or does it not make sense for me?”
And then the last thing is somewhat straightforward, at least in theory, is defining SMART goals for each initiative. And essentially, you’re focusing on the second half of this initiative document then. And again, this doesn’t have to actually finish in a complete document, this is sort of a living document, asked the initiative earner, then goes on afterwards to work on this initiative.
Okay, so these are the main bits of content, and then there is some bonus content. The first one being a section on communicating well. And if you don’t know Abby Falik’s user manuals, they’re quite cool and can help a team work together better and be less anxious.
There is a section on Documentation, that is for one person on the team to do and afterwards, take everything, every material that was created during this planning session and put it into a combined document that you can then share with all the stakeholders. And that is a really powerful and useful document, because it will set the expectations from other teams for your team. And after a year or however long you take until the next planning session, you can then review it and see whether you actually achieved what you set out to achieve.
And then there’s some other extras, so I created an example schedule that you can follow, and that created a little script to which you give some inputs and then it’ll calculate how long this entire process will take for you. I’ve put in some energizer ideas from things that our team did, which were quite fun. I added a section on 6 Thinking Hats, which our team in particular found very helpful when we talked about, or when we did smaller retros on the initiatives, because it just focuses the discussion. And then some other tidbits that you’d probably find helpful in leading this. Okay.
Now, the last thing I want to say is that I really think anyone on a team can lead this strategy planning session. And that is because the outcomes of the strategy planning session are not defined by one person, they’re defined by the team as a whole. And therefore the person leading the strategy planning session is more of a moderator than a team lead.
Of course, you’re still a leader because you’re leading this session. But anyone can do that, so if you feel like you’d really love to work on that, speak to your team lead and work out whether you can do this.
So, to summarize, what we talked about is why you need a well-defined strategy. And that is, for one, to gain clarity and alignment across stakeholders, and for two, to increase productivity and have a more targeted impact. And in the end, this leads to making the dev rel team’s value proposition very clear so that, hopefully, no one in the org is just going to think that you’re a monetary sinkhole.
Then we talked about how you can go about creating your team strategy, and that is following the five steps that I went through, knowing your products, knowing your team and initiatives, defining the bigger themes, defining an event strategy, and lastly, setting SMART goals.
And know that this is not the end thing, after you’re done with the planning session it continues and everyone who is working on an initiative should continue this process.
And the last thing, I promised you a set of resources, and again, they’re available online. And as it’s GitHub, PRs are obviously very welcome, I’d love to have feedback on this. And if you are going to use this, I’d love to hear that if you do choose to do that.
All right, and thank you very much. Find me later with any questions that you have. And I hope you have a lovely DevRelCon.