Made by
Made by
How can dev rel practitioners ensure that what they’re doing is sustainable for the business, for the community, for the environment, and for themselves?
So, as Taiji you said, I’m Matthew Revell. I, along with some other people here, work at a company called Hoopy, and we help other companies to look after their developer relations strategies. So, the first question of this talk is why do you do dev rel? And I’m interested to hear from you in the audience, from a couple of people, why you do dev rel?
Anyone? Yeah. – [Man 1] Because you get to help steer engineering teams and community.
Kind of like build your community to your enterprising parts basic needs.
Sounds good. Okay, so… – [Man 2] Because developers hate marketing.
Because developers hate marketing, because you get to build community with engineers. I tell you what, I think there’s another reason. And the reason that we’re all doing developer relations, apart from maybe the people working at Mozilla or maybe one or two other companies is that we’re making this guy rich, right? At the end, if everything I do at some point, there’s an investor, there’s a VC, there’s some shareholder, someone, generally a white man in Silicon Valley that we’re trying to make rich.
So what has that got to do with sustainability? Well, I think it really influences a lot of the approaches that we take to develop relations and it’s partly one of the reasons I think that, in some ways, develop relations isn’t in a sustainable place right now. So, what does sustainability look like for developer relations? I think it’s about balancing three things. One is you, as the developer relations person, the developer advocate, the community manager, whatever your role might be.
The other is the developer themselves, the developer community that we’re here to serve. So as much as we might be ultimately looking to make things better for an investor, it’s the developer that we’re really here to serve. But then there’s a third point as well, is the business. Whatever organization that we’re a part of, we also need to keep that in balance.
And so, developer relations is really if you want to make it sustainable, it’s about keeping these three elements in check, keeping them in balance. And so, over this next few minutes, I’m going to look at some of the ways that I feel that we’re not quite in balance right now and some of the ways I feel that we’re not behaving sustainably as a developer relations profession.
So, I’m not calling out individuals but just some of the trends that are there and perhaps some of the ways that we can become more sustainable in how we approach developer relations. So let’s start with you. And I choose that background very carefully. This is a tweet sent last year that kind of kicked off my thinking about this talk.
And it’s a joke. It’s “DevRel folks can get sick in December because it’s the only time they can.” And it’s the idea that, you know, there’s, particularly in the West, there’s an end of year holiday, and it’s the only time when there aren’t any conferences and nobody is expecting you to get on a plane or do anything like that.
And I have my own story around that. A few years ago, in 2013, I was working for a database start-up. And in one year, I visited 40 cities, most of them a plane ride away. And so, if you think about that, that’s an average of like one every eight days or so.
But actually, most of the time, it was flying to a city, do something, get on the train, go to a nearby city, do something else there, maybe get some sleep, then fly to another city, do something there and so on, and then maybe have a week off. But for me, this was unsustainable. I did it for a year and then it wasn’t possible to do it. And ultimately, you have to look back at a year like that and wonder what did you really achieve.
And in my case, probably not a lot because that startup went bankrupt. So, you know, that was 40 trips of hardship, in some ways, and fun and, you know, we achieved things, we made a positive impact on the lives of the developers that we spoke to, but ultimately, it was for nothing. And there’s a trend, a small trend, but there’s a tendency, I guess, at the moment, for some dev rel people, to talk about this kind of thing on Twitter under the hashtag, #devrellife.
And I think this is an example of two sides of the same problem. One is that a lot of dev rel people are doing too much and trying to fit too much into the week to the point where they end up harming their health, both physical and mental, they end up in burnout situations, and they’re not actually serving developers well, they’re certainly not looking after themselves and they’re not necessarily doing the right thing for the business.
And so, again, without calling anyone out in particular, you know, there are tweets where people are saying basically, “Oh my God, look at my life. It’s only ever in airports I eat breakfast, it’s only ever on airplanes that I really, you know, value my time.” You know, and we’re kind of almost tweeting about how to optimize the travel experience and how, you know, what office are you from all the united lounge.
You know, it’s this idea that, on the one side, to an outsider, it looks like a stream of humble bragging because, actually, a lot of what we do is the sort of thing that many people would love to do. You know, we get paid, in develop relations, to often go to different places in the world and there’s all these things.
And okay, when you’re experiencing it, it’s not always that fun. But I think both these shows that develop relations people are trying to pack too much in for one reason or another, but also it shows that the image that we’re presenting to the outside world isn’t always the strongest one that we could be.
And I think what it comes down to is that we should remember that dev rel is a job, it’s not a lifestyle. It’s not, you know, we’re not on Instagram trying to show what a good time having. And at the same time, we’re not really gaining all that much from our lives if we work ourselves into an early grave because we’re trying to meet some target that isn’t really well understood or if we’re trying to meet all the developers we possibly can in person.
And so, it really is about these three things being out of balance. You know, if you do too much travel, if you try to be everywhere at once, then you get exhausted, your managers will be asking what the return on investment is, and the developers will probably be indifferent because you’ll be too tired to give them really the attention that they deserve.
And sure, absolutely, travel is only one part of the developer relation’s life, but I think it’s symptomatic. It represents something deeper at work here. And as a profession, developer relations isn’t always well understood by other people that we work with, but even by ourselves, you know.
So it’s easy to go out there and think, “Well, I’ve got to go to as many meetups and as many conferences as possible.” You know, and that’s the kind of thing that happens. You end up, the phrase is “cargo cutting” a way of doing dev rel because you’re not quite sure what to do. And so, again, it’s not just about flights, but I think there are other things you can do that maybe is beneficial, if not more, than getting on another plane.
One is, write a blog post. You know, how many developers can you reach through content instead of going and seeing 30 people at one meet up? Could you improve the developer experience of your product by fixing a bug or writing some documentation? You know, could that have a more meaningful impact on the lives of the developers that you’re serving, and so the business that you work for than going and standing behind the booth of yet another conference?
Or could you do something to make one of your community members feel valued? Can you call them out for the great work that they’ve been doing? Whatever it is, ask what you’re doing, how does it feedback into your overall develop relation strategy?
And if the answer is to get on a plane, then do it, that’s great, but make sure that what you’re doing is justified both to you as a person, to the business, and to the developers that you’re serving. Also as a quick aside, I think we should conscious of how we present ourselves. How many people here have heard of entire develop relations teams being fired all at once? Yeah.
I mean, it happens, right? And it happens partly because the business doesn’t understand the value that we bring. And I think sometimes that’s our fault, sometimes it’s the business’s fault. But we’re in a weird time for developer relations. It’s growing massively and so it feels like it’s a really good time to be in dev rel.
But also, because it’s growing still, not everyone understands what we’re about. And so, no not everyone understands how to measure the value of what we deliver, which means that it’s down to us to be very careful about how we present ourselves to our colleagues, present ourselves to the world. So if we’re tweeting about flying here, there, and everywhere, you can’t blame your colleagues for saying, “Oh, that’s the team that just gets on planes and spends money.”
If you publicly talk a great deal about being a developer advocado, that’s fun, but then you can’t blame your colleagues for questioning whether you’re serious or not. Okay. Let’s go on to the second one, the business. So, I think we have a problem with the business side of things of mismatched expectations.
This group of people, starting with the CEO, the CEO does not care about dev rel, all right? They might say they care about it, but that’s as a strategic thing that’s happening right now. What the CEO cares about is finding the most efficient way of giving the biggest return to the shareholders, all right?
If developer relations is the right way to do that for now as part of the strategy, then great. But as you go down this list, you will find that they may be getting more and more interested perhaps or maybe not at all, maybe none of those people care. Sorry. And that’s partly our fault. That’s partly because we’re not always that great at explaining back to the business what it is that we do.
So, developer relations is a process, all right? It’s a thing that you repeat, you do some things, and eventually, a result comes out at the end. But the problem is, because developer relations isn’t that well understood, often, it seems a little bit like magic, you know, and that sets expectations with people who don’t understand developer relations, that you’ll be able to do some things for six months and then achieve hyper-growth, which is a really wonderful turn.
But actually, you know, there is another group in our organizations who face this problem of people not realizing that what they do is a process. And we have a phrase in English, “If something walks like a duck, sounds like a duck, and looks like a duck, then it’s a duck.”
And we spend a great deal of effort and energy in dev rel telling everyone that we’re not marketing. Who’s that serving, all right? Think about it. Does it make us feel good? Maybe, because, you know, a lot of people from a tech background look down on marketing.
Does it make developers feel good? Maybe actually. But when it comes to explaining dev rel to the business, if you couch it, if you explain in terms of marketing, then you might feel a little bit bad, but at least the people in your organization will have a chance to understand what it is that we do.
So, don’t shy away from describing it in terms of marketing because people will have an opportunity to get what dev rel is. We have another little bit of a problem on the industry’s business side of things. It’s going back to that guy standing in front of the McLaren sports car. It’s that a great deal of what we do is funded by VCs.
And the VC model is for 9 out of 10 companies, fundamentally unsustainable. It’s about spending millions of dollars in hope that one of those bets will make billions of dollars, all right? And so, that leads to us, kind of, getting into that mindset, as dev rel people, of going out there and spending as much money as possible, trying not to let the opportunity slip away, trying not to let the competition get ahead of us in order that we can get in there and have first mover advantage in all of these sorts of things.
And I’m not saying the VC model is entirely bad, I’m just saying that it’s given us a heritage that means, at times, the way that we approach dev rel is not as sustainable as it could be because you’re out there and trying and spend all the money before it’s gone and hope that it will come back in the next funding round. And profitability is the fault of the person, or the problem of the person, who eventually acquires the company or the shareholders who buy it in the IPO.
Okay. Now, coming to the developer. These are the people that we’re really serving. I mean, sure, okay, the investor is the one pulling the strings in some ways, but most of us, I think, come into dev rel to serve that developer community. But we have a couple of problems with sustainability here, one is overfishing and the other is that we’ve relied too much on the same techniques over and over again.
By which I mean, beer and t-shirts. Now, a few years ago, buying beer for developers was a pretty good way to reach developers because a lot of developers were of a certain type. But thankfully now, the developer world is becoming way more diverse and people from all sorts of walks of life and backgrounds are becoming developers.
And so, if you want to reach anyone other than people who go to pubs and wear t-shirts, then you need to think about what you do. And okay, a lot of people are being more creative about dev rel now, but you’ve got to ask, ” What does your developer look like?” And it probably isn’t that slightly overweight guy with a ponytail and their favorite t-shirt. It’s a single mother who can’t get to your meetup in a pub in a 60 cent an evening, it’s someone who doesn’t drink, it’s someone who is cheese intolerant and doesn’t eat pizza.
You know, you’ve got to think, as Sammy was saying, very eloquently earlier, diversity makes us all stronger. And so, if you’re only going for a very narrow group of developers, then we end up with a problem a bit like this. If this is your total addressable market of developers, a great deal at the time, we just go to that tiny easy to reach group at the top.
And because we overfish them, we keep going back to them time and time again. Some of us go from one company to another, going back to the same developers that we knew at the last company. Then what happens is that group gets smaller and smaller because they become less reachable by those methods, they’ve heard it all before, or you’ve converted them into a paying customer and, you know, they’re no longer a target or they’re just too busy doing something else.
And then you have this whole big group of developers who Microsoft’s Scott Hanselman refers to as the dark matter developers. These are the developers who wear a suit and tie sometimes, in America, in Europe, that’s really rare, and they go home at the end of the day and they don’t look at hacking news, they don’t get stuck in flow, they might not even have a computer at home.
They don’t care about it as a passion, it’s a way to pay your rent, okay? But, nonetheless, those are the people, but if we become more creative, if we work a little bit harder, if we bring ourselves outside of these unsustainable over phishing techniques that we have now, that we could reach and we could start to help convert some of them.
So the question is, can we fix it? And if you are a Bobby Builder fan, which is probably unlikely here, then you know that the answer is, “Yes, we can.” So, really, what we have is a virtuous cycle. If you feed the developer, then the developer will hopefully some of them meet the goals of the business is probably reasonable, all right?
And then, that then helps you to meet your goals and so that helps you to become sustainable within the organization. And basically, it becomes a nice overlapping Venn diagram of happiness in the middle where you, as the developer, aren’t overworked, the developers themselves… Sorry, you as the developer advocate, are not overworked, the developer community feels served and that they’ve got the product that meets their needs, and the business is happy because you’re ticking off some boxes, sorry, you’re meeting your KPIs.
So, on your side, you know, in summary, let’s be careful about how we present ourselves to the outside world and to our colleagues. It’s okay to have some fun amongst ourselves, but we are still a vulnerable group, okay, as a developer advocates. We get fired because people don’t understand us, okay?
So let’s be careful about how we present ourselves. Also, if you feel like you’re being recognized by your colleagues for the work that you’re doing, then you won’t try and do all the things all the time and end up getting burned out. And the way to do that is to act strategically. We’ll look at that in a moment. But also remember, it’s just a job, this is not a lifestyle.
It feels like one, but it’s a job. It’s a way of doing something with our lives, it’s a way of making money, it’s a way all sorts of things. But yeah, it’s a job. On the business side, we need to make our dev rel work align with the goals of the business.
So, research what the need is. What is the need of the developer community? What is the need of the business that you’re working for or the organization? Then agree realistic goals with that business, create strategy to meet those goals, and then stick to the strategy.
You know, one way of describing a strategy is as a framework for saying no to things. If you have a strategy, it’s easy to say that you’re not going to go to that conference with three people that’s a four-hour flight away. Yeah, and also, I say that don’t fight the framework through which your colleagues understand your role. Swallow your pride and be accepting of the idea of describing what you do in terms of marketing.
Oh, and also, something that dev rel teams are sometimes really bad at is reporting their successes within the organization. Go back to your colleagues and be proud of what you’ve done. Okay, maybe the last slide. So, in terms of what we do to serve the developer, be creative. Don’t try and fish the same people, don’t try and use the same techniques all the time.
Instead, meet the needs of the developers that you want to serve, reach those unseen developers, and focus on building long-term mutually beneficial relationships. It’s not just about bums on seats, it’s about what can you do, over a course of years, to serve those developers to help them meet their needs?
All right. Thank you. I am Matthew Revell. If you want to reach out to me, that’s my email address there. And thank you, I’ll be around. Cheers.