Get executive buy-in … or else

Jessica West, who heads-up developer relations for Launch Darkly, lays out the importance to any developer relations programme of having the support and commitment of the company’s leadership.

Transcript

Jess: Thank you Brandon for the introduction. He didn’t include that I really like to do karaoke and I did put that in my preferences. So tomorrow we’re doing it. Okay, so thank you all for coming to this talk. I have a very ominous title because you know, click bait and marketing and I have that background.

So I wanted to talk to you a little bit about all these conversations we’re having in developer relations right now. You know really all of it really comes back down to executive buy-in, and if we don’t have executive buy-in for anything else you know talking about what backpack we should wear, or what we should do for initiatives, or what sticker is the best really is moot point. So let’s dig into that a little bit.

So there’s three types of executives. We have the first one, they get it. They’re on your page, you they have a clear plan, there’s no question on budget or initiatives. They’re all in. The next one you have is the middle ground. So they’re like, oh yeah, I understand developer relations. I think that’s a cool thing, I’ve heard it and they’re “bought in” and I do quotes and we’ll talk about that in a minute. But not quite sure I’d maybe measure and execute. And then you have the last one, and they have no clue. And that one maybe they’re still questioning budget, they’re not quite sure what they need and you say “dev rel” and they’re like “Yeah I don’t know. I don’t need to talk about that”.

So let’s talk about each one. So they get it and how do you maintain? So when you have a executive that understands developer relations how do you maintain that? Because yes they bought in but it doesn’t mean they’re always going to be bought in. And how you can maintain it, is communication and kind of do an internal evangelism. And so a lot of times we’re going out and we’re speaking at events, and we’re doing our thing, and forget that inside we actually have to talk about that within our organization and let them know what we’re doing to make sure there’s no single point of failure.

Another thing you can do, if you haven’t already established a developer relations team and program, and your executives all set, maybe create a Roadbook for your future advocates so they know when they come in they want to get going, and hit the ground running. And when doing developer relations onboarding not only having a Roadbook but an onboarding book. What does it meant to be an onboarding developer advocate at your specific company? Because that looks different at a lot of different companies we’re at. And routine reporting, so you’ve got the executive bought in, they’re like “Yep. Let’s do it. How do you show them what you’re working on?” And not just occasionally get the scrambling in like “Hey, it’s December 28th, you know we got the budget, what did developer relations do this year?” But you know quarterly basis, monthly, maybe ongoing if you have those kind of resources. We’re going to skip right to the no clue one. So they’re still trying to work on budgets, they really don’t have everything all set, and you’re still having lots of discussions or arguments.

My personal opinion, these do not represent any employer, you should look for another job. Because ultimately you’re going to be fighting and uphill battle, and if your executive doesn’t have that buy in, there’s not a lot of point for anything else. This is going to be the majority of the talk. This is where a lot of developer relations departments and teams are right now. The executive is there, they’ve heard of it. They’re like “Yep that sounds great. How do we measure and execute? I’m not quite sure.” And you’ve got this kind of in between space. And this is really hard because you asked the very first question like, “Hey you’re hiring for dev rel. Great. I want to go would be the head of their dev rel program”. But maybe they don’t quite understand what developer relations is and more so maybe they don’t understand developer relations at their specific company. So from here, when it’s middle ground the important thing is you want to ask more questions. And let’s make a clear path to align company values with yours. So when you’re asking them “What’s the most important thing to your company?” And see how that lines up with your values as a developer relations program. And discussing what is success factors look like for that department. Communication, Team work, and ultimately, some strategy questions.

So let’s get into a couple questions that you can ask your department and your executives. I broke these into four categories and so we can go through each one of them, and also I also have these slides posted online afterwards if you want to look at them. So overall value. Asking your executive “Why do you think developer relations is important? And what value do you think it brings? And what are you looking to get out of dev rel?” These are all great questions to ask your executive and see what they say. I recommend ask a question and then stay silent. Don’t give them any lead and just see what they’re doing, and what’s their first gut reaction. Also I’m going to go through each answer. It’s totally okay for all these answers to be “I don’t know”. And there you go back to maybe it’s time for another job search. So some answers to be weary about for that one is “We saw Twilio doing it and they were great. So we should do that. We saw Stripe doing it”. Insert company name here really. But look at some of the successful programs that we have seen for developer relations and a lot of companies will come and say they did it so we should do it. And that doesn’t always work. So if you have that question and they say they saw another company doing it and that’s the only reason they have, that’s a warning sign.

Let’s talk about success factors. When you’re looking at developer relations obviously you want your program to be successful and what does that look like? And what does that look like not only for your department but also for your company and in the executive’s eyes? So you can ask them like what does a successful dev rel person or team look like? You may be that very first person coming on as your dev rel team and so maybe you’re a team of one. Which is totally reasonable for a startup. Or maybe you’re coming into an existing team, or they say “I want to build up 20 people for this team”. And you say “Great, what does that look like to you?” If you said this is my perfect idea of a dev rel program how do I look at that? And another one is “How are you measuring things?” And not just in developer relations but in the whole company. How are they measuring success for Engineering? For Marketing? For Sales? What’s the health grade for the company overall? And this is really important because then you can look at that and how does that line up with your program. And I think this is a key thing too is, what does success look like to the board? And so beyond the executives, but the next level up, The Board, when they’re having those big Board Meetings, what is the developer relations success look like? You know is it something, do they even know about it? Or they say that yes, if sales are up then developer relations is doing well. Or if I saw someone do a viral tweet so therefore developer relations is doing well. All these things you don’t know about until you ask. Some answers to be weary about: “We aren’t measuring anything or our board isn’t aware of our initiatives, and those initiatives I’m talking about specifically for developer relations”. Maybe your board has no clue what the dev rel program does and again not necessarily a bad thing, but it’s a warning sign.

Teamwork. How are responsibilities divided? And this is not just within developer relations but, how is that divided amongst the whole company? What does Marketing do, what does Sales do, what does BizDev, do you even have a BizDev? Do you have a Customer Success team? Do you have an Education team? This really all changes in scale from companies from 0 to 50, 50 onwards and that could look different at one 50 person company to another, or even 1,000 person company. I think this is really important because the teamwork and how things are broken out. Just because you have a Series A startup that doesn’t have a lot of money, they can have a really successful dev rel program compared to a public company that has thousands of employees and they may not know what we’re doing.

And I think often we often look at, well if they make this much money or they’re public that means obviously they know what they’re doing. Which is wrong in a lot of cases. And so for that one how is a distributed? What’s each team, what do they bring to the table? And how is that viewed? So you know, what is again, what is the Marketing department responsible for? Or Engineering? And are stakeholders goals being represented around the team? So when you’re looking at that for the board or for the executive those stakeholders they’re in their team, what goals are associated with them? Are those goals then represented in your team? How are they being found? I feel like you see that a lot and they say “Oh well, dev rel, it’s a feedback loop. Everything is great.” Which is cool, but there’s a lot of other departments that have dev rel feedback as part of their number one thing.

So that can’t be the only thing developer relations is for. I saw someone tweet, they were saying you know, they’d like a quote to me “If our job as developer relations is only feedback loop then you probably shouldn’t have it.” I think that’s something that’s really important because yes its part of our job and that’s something that we can help, to be a part of that feedback loop in the community but that’s not the only thing. If you have an executive that really thinks the only thing you should be doing is feedback loop, I’d question that one.

Okay so communication. How do you currently communicate? Is that all in Slack? Is there an all-hands? Are there newsletters that go internally? Externally? Is it all in a forum? This is really important because then you can see how they communicate within departments and how you can communicate as developer relations department. And how is communication handled between other departments. Between Marketing and Engineering, is there any kind of crossover? Does one person sit in on the meeting? Is it really just high level notes? How do we get feedback from that team? That’s the really important thing too. You’re doing all these initiatives and Engineering is pushing out all these drivers, how do you get feedback to that team and then also from that team on how you’re doing? This one too, ask people “For developer relations, how do you know things are going well or how do you communicate?” If they say “I see some Slack updates, I see they tweet a lot. I know that they’re never in the office”. That’s not a great insight to your developer relations team. Now that we’ve asked a couple of questions, the key here is that you need to understand your value to the executive team. Then you need to use that to measure against their priorities.

I want to define executive buy-in because I think that looks different for a lot of places and for maybe everybody in the audience. And for this purpose of this talk, executive buy-in is an executive that understands your goals at a high level and advocates for you. Not only defends you but advocates for you and says yes I understand what this person is doing, here’s the value they bring in, and I am behind it 100%.

I’m going to talk about what executive alignment looks like and then these are executives that are some of the companies outlined. So Anil Dash he’s at Glitch, Jeff Lawson at Twilio/SendGrid, David Singleton at Stripe. And these are all executives that really truly believe in developer relations. I think that Jeff’s talked about a lot because Twilio is used as our sweetheart example at a lot of conferences. So I want to focus on Anil, and Anil is someone that came on to the scene and he’s well known in technology, but I feel like he really made a big splash on advocating saying ‘I not only believe in developers, I believe in developer relations’. He was on stage at DevRelCon in London two years ago and that’s right after he’d written these ‘Ten Commandments’ on developer relations. Which is really interesting because he was coming and taking a stand and putting his whole backing of his power as an executive and as a leader in the community about saying that ‘I believe in developer relations and what does that mean to me and the the company’. It ultimately comes back to developers driving decisions. That’s what our whole department and whole team should be about. Developer relations should be out there and helping developers drive decision to that product.

Quick story time. We’re talking about all these theoretical things. This is the question you should ask. A lot of those questions I put up there I ask in my interviews any time I’m talking with companies about what are they doing in developer relations. It really helps me understand what’s happening before I even get there, or when I get there. But it’s not always been the case. So I have been at a company before where it’s I walked in and was like “Oh, this is a successful developer relations program I’m joining, I’m super excited”. We had a team that was growing, we had headcount, and we came in and we didn’t quite know what we were working on. But I was like “It’s okay, we’ll work it out. Figure it out later”.

Well we figured it out. But the team ended up ultimately going down to one. So we failed. And so in the executive’s eyes, they wondered why we should have developer relations. I don’t understand the value of it. We actually switched teams. So we went from Marketing to Engineering, and then to like “We don’t quite know. You’re just kind of like ‘there'”. And so when we were in that ‘there’ point, it was this big fight of saying “What is the value for developer relations?” And so I think this was actually a really good thing for me in my career because I got to learn how to talk with executives, and how do I fully understand what they need? So I asked all the room “What does my end look like to you? What’s important to you?” Through that exercise of digging, we found what was important to them was drivers and those language drivers, and those things that were important to executives. They wanted see more adoption from developers on the different drivers. They didn’t really care about how many conferences I was speaking at. They wanted to see adoption go up. They wanted to see more information about this language on these different forums. Ultimately we then changed and pivoted and created a whole program around developer relations and what that would look like to align with their goals. So with that one that’s where I kind of learned like some my next steps here.

So how do you get executive buy-in? You’re in that middle step, and this is tough place where people say “I believe in developer relations but I’m not quite sure how to measure and execute it”. You’ve got a road in front of you, you know it’s a little bit of pop slash. You might not go straight, you might be going back and forth but you have a path and it may not always be clear. And that one this is where I think you can kind of work on trying to find executive buy-in from the ground up. You have it, but you don’t really have it, and how do you move forward from there. Digging in and going back to those questions you have to ask to the executive team. Let’s say you come in there and they understand but they don’t quite know what to do. Go back to those questions and ask them and that can help start lining up your strategy and your goals. And after that you can discuss what to do and those priorities and set the goals for your team. Ultimately, we all want to be on a successful team. No one wants to have their validity questioned and we all want to be happy and successful in our jobs.

After you ask those questions I think these are the next three things. You want to look at how you program your initiatives. Setting up programs for what you’re working on, then creating measurements for those, and what it is that you are measuring; the number of developers using your product or whatever that is. You need to set that measurement up. And with that reporting ideally. And then communication, this is a big one. So here are the three things that we’ll go into and then where we go from there.

So program your initiatives. Segmenting your developer relations teams or your developer relations initiatives into programs is really beneficial. So this may look like an ambassador program or a hackathon program, or a different types events. Or maybe it’s your education initiative. Either way, segment these into programs and then you can have clear outcomes. For our education initiative we want to have ten demos done for this quarter. For our hackathon we want to be initiative we want to have 50 hackathons at this next year. And each one of those has a clearly defined goal, outcome, and owner. Maybe give it a fun name if your company allows you to. That helps segment what you’re working on.

Setting up measurements. This can look like a number of things and so I listed off a couple of these ones here. So number of Developer Engagements, and this can be you know how many people were in your audience. I’m giving a talk here so I can report back that x many people showed up and heard me speak. That’s how I’m going to measure my success. Maybe it’s the number of visits to your blog post, or people that tuned into your stream, or came to look at your repo, forked your repo for your demo. Maybe it’s the number of SDK downloads, or number of developer accounts created, the number of active users on your developer forum, maybe the number of people at your user group event. All these things are measurements that we can use to say what we are doing in developer relations and here’s it lines up with everything else. And maybe you don’t measure against all of those but maybe it’s just two of those because those are really important to your company. You know whether they use the forum and they want to get more people involved and take them off Stack Overflow. Sorry to any Stack Overflow people that are out there. But you want to tell them that this is our goal as a company and we want to be in this forum, and we want to measure how many users are on there, and how many active users are there.

So next thing we have is communication. I think this is the number one problem we see across the industry. We spend so much time communicating outward to people about like “Hey, here’s a product, here’s what I got. Here’s a sticker, here’s a swag, dadadadada”. And we don’t communicate internally. We’re out working so hard and people are getting burnt out flying, getting on a plane, or train, or boat, or whatever you use for your transportation and you get out there and you’re giving a talk, you’re working really hard but you’re so exhausted by the time you get back that you don’t communicate that internally. That’s where we have a problem. Because then nobody in your company knows what you did. They think you’re doing work. But you have to communicate that. And that may look different in a lot of different places.

One thing I think is really cool is doing an internal company newsletter. Treat your company like they’re the customer. What did you work on this month? And here’s where our advocates were. And here’s what we worked on. We got people and we got this mention. Maybe they didn’t see that really cool tweet that mentioned how this was so easy to set up and that was great. Highlight the success stories of your developer relations team in a newsletter.

Speaking at the company all-hands twice a year, and insert whatever that looks like for your company. I think letting the company know what you’re working on is really key and really important because they may not know and maybe they missed the email because we get a lot of them. But saying “Here’s what our initiatives are, here’s our programs, and here’s where we are”. That’s really big and it won’t take much of your time. Doing an internal wiki to showcase your work. Notion is a great one if anybody’s used that one, having a “here’s what our company is up to”. Some of the guys up here before, they’ve got Atlassian if you want to work with Jira or anything of that nature. Wherever your company lives, maybe that’s just all on Google Drive, you should have a home that shows what we’re up to, here’s what we’re working on, and come talk to us about it.

This one I think is a little bit different; sitting in on other department meetings. So you may be in Product, or Marketing, or Engineering, or wherever but coming into your partner department and going and asking what they’re up to, learning about what they are working on once a month or whatever that cadence looks like is really important. And once they see like that you’re supporting them and they’re really happy to have you there and you understand more what they’re up to – if anything has changed and making sure your initiatives still line up with those.

Doing event recaps internally and externally. You do a lot of work so coming and doing event recaps for the places you speak at. Maybe you helped the Event Marketing team put something up for the internal; do a quick recap on why you thought it was important for the developer community. You can do it internally so that they can see that, you can say like yeah that was a waste of time so don’t do that again. Or you could say that this was great, here’s great resources, let’s go bigger next time. All those things are really important and giving that kind of recap and that feedback to your department of what you’re working on.

Team meetings, I think this something fun. Having open invitation for any department to come join your teams. For example, the very first meeting of the month, feel free to come to our developer relations team meeting. You can see what we’re up to, how we’re driving things and from that, feel free to ask any questions. Prep your team obviously at a full disclosure. No ones complaining about anybody. This is really gives like a nice open invite for everybody else to come in. I think it’s a really nice thing to do.

I think you need to make time for this kind of work. This is the foundation of your department. It’s a lot of work to ask questions to the executives, strategize, report, communicate. I still have a full time job. But really ultimately without this, your full time job is going to go away if your company can’t see what you’re working on and if they can’t see those results of all those initiatives that you were working on. I don’t think you’re ever too small to start a strategy or process. A team of one can have a whole strategy, processes, all those things we talked about. Those initiatives, measurements, and doing recaps. I think Roman from Stripe is a really good example of that. He was a team of one for a long time, and clearly had a strategy that was lining up with the company and was executing on that routinely. If you go to two, three, and four, and then people start questioning that headcount and they’re asking what the strategy and process is.

So hot take, TL;DR. I think asking what department dev rel belongs in is kind of pointless unless you have an executive sponsor. If it’s two to three then that’s a discussion you can talk about if you have a sponsor that’s the CPO, the CMO, the CTO, great. I want to know what company that is, but usually if you’ve got one and then it’s an easy choice. It doesn’t really matter if it’s Marketing, or Engineering, or Product, or your own. But you need to have some kind of executive sponsor otherwise what are we doing? And I think asking those hard questions, getting those answers, setting up time, communicating – these are all really key and from that you can then make sure you have successful program. And that’s it, thank you for your time.