But why does the business care?

Michael Heap
Michael Heap
Director, Developer Relations at Kong
DevRelCon 2021
8th to 10th November 2021
Online

Michael joined Nexmo as a PHP developer advocate and left as the Director of Developer Experience. It wasn’t his technical skills, ability to present, (or charming wit), but the fact that he focused on the question 'why does the business care?'. In this talk from DevRelCon 2021, he spoke about the things he did to ensure that DevRel was aligned to the business’s needs.

Watch the talk

Key takeaways

Takeaways coming soon!

Transcript

Speaker 1: Good morning, afternoon, or evening, wherever you may be watching from. I hope you're enjoying this iteration of DevRelCom as much as I am. I'm Michael, and I was previously the PHP developer advocate in Nexmo, which then became Vonage. But we ended up building a team of 25 people focused on developer experience. I'm now the director of developer relations at Kong, where I'm aiming to do it all over again.

Speaker 1: And when I joined Kong, I asked, why did you hire me? And one of the big reasons was that I focused on business value and measurement in the interview process, which brings me on to today's topic. But why does the business care? Because we all know that we add value, but how do we show that to our employer? And there are few models out there that aim to communicate what we do.

Speaker 1: There's the art model if you're more product focused. There's the orbit model if you're building a community, and the awareness enablement engagement cycle to show all the composite parts of being a DevRel team. I want to share something with you, and it's something that you've heard a couple of times today, but I just really want to drive it home. DevRel is a cost center. This is why it's really important for us to show our value.

Speaker 1: Because if you cost more than you contribute, there's no reason for the business to keep you around, and the DevRel team is not cheap to run. We've got salaries, swag budgets, travel budgets. Each DevRel person can end up costing twice what a product manager or an engineer costs when you take into account everything else. Now the best way to show value is to tie your team to a revenue figure. But we're not salespeople.

Speaker 1: You're right. We're not. We don't have quarters, and so much of what we do is intangible. And that's the issue, isn't it? It's hard to measure.

Speaker 1: How do you measure the number of people that would have failed if you didn't spend that time improving the documentation or the number of people put off by the tone deaf email campaign that you helped to salvage or even those that never have heard of your company if you haven't been at that event. Today, we're gonna cover how to build relationships, select metrics, and get work prioritized. But it's important to note that the strategies presented will only work in a workplace that is at least semi functional. If your exec team want twice as much as you're currently producing and they want it yesterday, what I'm about to say won't be too useful. The same is true if your business priorities change every other day.

Speaker 1: Hopefully, your workplace isn't like that. And if it is, I'd love to talk to you about it afterwards. Alright. Building relationships. Now it turns out that the best way to make the company care is to make the people in the company care, And that means aligning to your overall goals because people will forgive a lot if you're doing things with the right intention.

Speaker 1: And it goes without saying that you should try and align to your manager's goals because they're the one that will go to bat for you when needed. But you should also work out which other colleagues outside your team you'll need buy ins from to achieve your goals. You should prioritize things that help them too. To illustrate this, imagine that you've got a choice to make. You've got a new version of your JavaScript SDK, and you want to write an in-depth integration guide.

Speaker 1: You've got two possible choices to write about YUI. Anyone remember that? And React. Wow. YUI has a target audience of three people whilst React could reach 3,000.

Speaker 1: Easy choice. Right? Not so fast. In this instance, the correct audience is actually the three people, not the 3,000. You see, one of them is a huge customer that is using YUI for their platform, and we actually can't realize any revenue until they launch in production.

Speaker 1: Yeah. Our VP of support is working closely with them, managing the frustrations that we've had to work for a new SDK version, And our VP of sales has asked me to call it down as a reference for some big pipeline deals that are coming up, but they won't speak to any potential customers until their launch. Who you're targeting is as important as how many people you're targeting. You've got to get the right audience. This story had a great resolution, by the way.

Speaker 1: The VP of support now was you a favor, and the VP of sales reached out to your manager to say what a great job your team did. That's worth its weight in gold. A big part of any role is managing upwards. And it doesn't matter if you're a new graduate or a CEO, someone is going to ask what you're doing and what impact it's having. The best way to tackle this is to make sure that what you do is easy to consume, and don't make people ask.

Speaker 1: Push it out to them at a regular interval. Build a slide deck. We'll get it done in DevRel. Use it to show what you've shipped and what impact it had. Your boss is gonna get asked by their boss, what is DevRel doing?

Speaker 1: It is a call center after all, so make it super easy for them to show the work that you've been doing. Or even better, share it yourself. Here's a sample of a newsletter that I send out to everyone at Gong. We have three sections, content, blog posts, videos, Twitch streams, and, of course, as many puns as you can manage. We've got codes, what demos we're building, how are we improving the doc site, and finally, what we're doing in the community.

Speaker 1: Plus some of the bits that I can't show you is the related to how we're enabling internal teams too. This goes down the store, and people love hearing about what we're doing. People love hearing about how we can help them. But no matter how much you do, there's always more to be done. One of the main questions you'll get is when will it be done?

Speaker 1: And this usually isn't a question about speed, but about certainty. I learned about an interesting study recently where people were said were told, okay. You've got a plumber coming to visit you at home on this date. And they were frustrated because they had to stay the full day off work. So they said, well, maybe I could have a morning or an afternoon, but really what I'd like is, a one hour time slot where the plumber will turn up.

Speaker 1: That's just not possible because of the variable length of jobs the plumber was doing. But it turns out that people didn't actually want the hour time slot. They wanted to be able to pop to the shop and take a bath. So instead, the plumber started sending a text message when they were thirty minutes away, and everyone was much happier. You might think, Michael, we're not plumbers.

Speaker 1: We work in Devil. But the same is true of your exec team. They generally don't care how fast something will be done as long as you can give a ballpark estimate, and they can plan around that. It's just about managing expectations. And now we're back at the beginning.

Speaker 1: How do you build bridges with the rest of the company? Look for opportunities for warm handoffs between your community and the rest of the business. Mary calls these DevRel qualified leads. Can you introduce someone in, to marketing to find a case study via blog post? How about beta testers for product or hiring from the community with the recruitment team?

Speaker 1: Maybe helping the partners team with integrations. There are a ton of ways to build goodwill with others just by sending an email or two. Maybe introduction. And, yes, this also includes sales if someone's looking for additional support. Alright.

Speaker 1: Selecting metrics. Now I mentioned earlier, these align to your manager's goals. Hopefully, they have some. If not, don't panic. There should still be some high level company goals, but if not, still don't panic.

Speaker 1: So my next slide is a goal that 95% of businesses will have. You can use that to derive your own goals. You ready? Make more money. You might laugh at that, but it's true.

Speaker 1: Most companies exist to make money and deliver shareholder value. It'd be great if there is a more altruistic mission as well, but at the end of the day, without money, no one's getting a paycheck. So make more money to that as your goal. Make more money by how do we make more? Do we need to drive more people to sign up?

Speaker 1: Excellent. Let's focus on awareness and events. Or do we already have plenty of people signing up but not doing anything? It's a great problem to have. How can we how can we reduce the time to hello world and have them activate sooner?

Speaker 1: Do we have people trying the product then leaving after a month or two? Let's do some surveys, find out why they're leaving. If it's a product gap, feed that into product. If it's experience, let's set some developer experience goals. But your metric doesn't have to be all about the money.

Speaker 1: You might aspire to win the best overall developer portal award at the Ride the Docs conference. That is very valuable both internally to show that you've been recognized by peers, and it also helps the sales team. Imagine they're in contract negotiations. I mean, who doesn't want to use award winning docs? You could measure the rate of repeated questions being asked.

Speaker 1: If you get the same question every other week, and once you do your thing, it drops to zero, that's awesome. Those customers are now being successful. That's what DevRel is, making customers successful. Time taken to do something is a great metric too. It could be internal, such as the time taken to fix an error in the docs and get that live, or maybe the time taken to design a new API that meets your API standards.

Speaker 1: If you get that down from months to weeks to days, game changer. It could be something public facing, like, time to hello world. Choose your top three use cases and make them achievable in under ten minutes. If you can't test this with real customers, ask for user testing budget, establish a baseline, and then test what impact your changes have. And finally, I want to mention quantity versus quality when it comes to metrics.

Speaker 1: Because imagine that you've got a target of 10,000 new sign ups. I could hit that in a couple of weeks with the right budget and a sign up for free pizza campaign in the first week of university, but approximately zero of those users can actually pay us any money. So we need a quality metric. Target 10,000 new sign ups with a 20% conversion to paid. You need to keep the quantity metric in check, and I've lived through this.

Speaker 1: We wanted to increase activations, so we added a button to the first page after you sign up that called our API. Activations went through the roof, but conversions stayed the same. People might say, well, why not just jump straight to the the quality metric? 2,000 conversion to paid. Yeah.

Speaker 1: That's okay. But having that quantity metric lets you figure out how many people are getting into the funnel and work out if you're actually losing people before they convert. It's really good sanity check on your activation pipeline, which brings us to the final section, secret work or how to do things that don't get prioritized. You have a couple of options here. The first is to pad your estimates and use that time to do things that you know are important, but they won't get prioritized because there's no impact this quarter.

Speaker 1: You say, no, Michael. I can't do that. I should be clear. There must be an impact to justify doing the work. Like, it's got to have an impact in six, twelve, eighteen months, but a lot of businesses are only focused on short term results.

Speaker 1: And this allows you to promise under promise and over deliver. Remember what I said earlier, speed is rarely the issue, certainty is. People remember bad things far more than they remember good things, so we really don't want to miss a committed date. Another option is to sell them something they really want and do your work as part of that. Imagine customers are asking for a sandbox, and you have an open API spec and Prism from Stoplight.

Speaker 1: You can give them a self hosted sandbox in your CLI using this. But, of course, you've been meaning to rebuild that CLI, and it keeps getting deprioritized. Here, you can use the requested functionality to justify the refactor. It's a bit tough to add the functionality without doing the best work. Then we have a third option.

Speaker 1: Just don't do it in secret. If you align yourself to the business and show value for long enough, you start to build up a reputation. You can use this to push your team's agenda when representing the community. If you go down this route, optimize for the highly visible work. We did some work when I was at Vonage to review poll requests in one click.

Speaker 1: Click a button, review app spins up. You can see it all in situ. Zero fanfare. But we built an interactive tool on one of docs pages that people could see. They could try it out.

Speaker 1: It was a delight that people loved it. And I used to say this was like a bank account. You have to make a deposit before you can make a withdrawal, but that never felt like the right analogy because you can always take on debt. But then one day, one of my reports showed a similar analogy with me. She said it's like a cookie jar.

Speaker 1: You need to put cookies in the jar before you can take them out again. And I love this one. As if there are no cookies in the jar, there's no way for you to get one at all. That makes for a really sad day. This was a super high level overview of all the things that worked for me when building out a team from two to 25 people.

Speaker 1: Once again, there's an assumption that your company is at least semi rational for these strategies to stand a chance of working. If I had to choose one area from this talk to focus on, it'd be building relationships. No matter how great you are at your job, you're gonna need support from others to be effective, and that usually starts by doing something for them. But that doesn't mean you should only do it for them. As an example, I went and analyzed every enterprise deal that Congress won over the last twelve months to understand what the key drivers were for purchase.

Speaker 1: I turned that into a slide deck. We're good at that after all. And I shared it with a few people. And within a week, I have people from all across business introducing themselves to me, saying thank you, asking questions. It was a day's work, and it opened a ton of doors for me internally.

Speaker 1: Plus, I knew what to focus our efforts on when it came to building out our dev strategy. With that, we're all done. I'm Michael. Thank you for your attention, and I hope you all enjoy the rest of DevRelCom.