Made by
Made by
Matthew Revell at DevRelCon San Francisco 2019
In his talk at DevRelCon San Francisco 2019, Hoopy’s Matthew Revell looked at some of the changes we need to make for developer relations to be more sustainable.
The team at Hoopy, we work with people doing consulting around Developer Relations. And this isn’t a sales pitch, it’s a segue into explaining that we do consulting, but also, if you’ve looked in your delegate bag, you’ll see that we’ve done this thing called the State of Developer Relations Report.
And that’s where we spoke to lots of people doing dev rel through a survey, but also through interviews and things like that, to try and understand what’s going on in dev rel, how people are performing it, how it affects people’s lives, and how companies view it, and how it can work both for developers, for the developer advocates, and also for the companies paying the bills.
And if you saw Naomi’s talk yesterday, you’ll have had a sneak preview of what I’m about to talk about. But we asked this question, as well as, you know, how big is your team? How do you measure things? We also said, “Is there any other in insight regarding the dev rel industry that you’d like to share? And people wanted to share. And so they started telling us things like, “Well, you know, it’s important for us to build alliances between each other so that we can effectively be stronger together.”
“Sometimes it can be hard to get our bosses to understand what dev rel is all about and why it’s valuable.” And then, you know, as I started reading through the responses, I started noticing some themes. And some of them were quite negative, such as, you know, “Well, dev rel’s really misunderstood and it’s a hard slog to do dev rel in a world that doesn’t understand it.”
“Sometimes we have to focus on really short-term goals because we’ve got an end-of-quarter marketing or sales target. And that’s impinging on what we want to do instead of long term stuff.” “Doubling growth year on year, I mean, that’s hard for anyone. But in dev rel, what does growth even mean?” “Juggling a million things while staying effective.”
And then the one that Naomi focused on yesterday, “Figuring out what the hell we’re doing.” And the truth is, as Jen said last night in her keynote, dev rel can be stressful for some people, at sometimes. And, you know, there are lots of really amazingly positive and wonderful experiences when doing Developer Relations.
But we have to understand that, actually, the reality of it for some people is a stressful role. Because there are mismatched expectations, not everyone understands Developer Relations in the same way. And so when you as a dev rel team have a different understanding of that as the executive who’s responsible for your budgeting and reporting into higher executives, then, well, that becomes a problem.
And ultimately, the way that I think some companies are doing dev rel, and the way that some of us as individuals approach dev rel, not because we’re bad people, not because we have bad intentions, but just because maybe some bad habits have built up, or because there are unrealistic expectations of what we’re doing, we end up with an unsustainable situation. And I see that…
Oh, okay, no. First, let me ask this question. And I really want all answers from the audience here. Why do you do Developer Relations? Anyone?
Audience: … Because it’s interesting?
Matthew: Okay, cool. Anyone else?
Audience: Tell others.
Matthew: Tell others, yeah, absolutely. Yeah. Two really good reasons. And there is another reason, though. Though, perhaps, is in the back of your mind. But actually, the reason we’re doing dev rel is to make this guy rich. Ultimately, we come back to there’s someone who is expecting a return on their investment, there’s someone out there who is either a member of the three-comma club, like Mr. Hanneman here, or, you know, there’s some manager or some investor somewhere who wants a return on their investment, quite rightly. But okay, most of us are doing Developer Relations at the forefront of our mind because we want to achieve something for ourselves. We want to help the developer that we work with or the developers that we work with, or we have an interest in somehow achieving some business goals.
And I think if we get these three things in balance, then that will lead to a much easier way to create a sustainable Developer Relations for everyone involved. Let’s look at you first, you as an individual, as a developer relations contributor. So, towards the end of last year, I saw this tweet.
And if you don’t follow Emily Freeman on Twitter, then you absolutely should. And she made this joke, “Dev rel folks get sick in December because it’s the only time they can.” And, you know, it’s funny because it’s true. But that set me thinking about my own story in developer relations, and about what I see happening, and how it relates to sustainability.
And it made me think of this number. Back in 2013, I was working for a company that was described as the frat house NoSQL company. Thankfully, in the London office, we were slightly less frat…boyish. Well, I visited 40 foreign cities in 1 year.
And, you know, that’s like one every eight days, if you average it out across the year. But actually, the way that we did it was we’d fly into a city, see a customer, because, of course, dev rel was doing presales in this company. And then we’d do a meet-up in that city.
Then we’d get on another flight maybe, or an overnight train or something to another city. We’d do something there, get on another flight, and then we’d kind of daisy chain these trips across Europe, mostly. And it wasn’t sustainable. It wasn’t a good time. You know, we helped developers achieve things. We made friendships.
We learnt. But ultimately, the company went bankrupt. So why did I put my life on hold effectively for a year in order to do that? And we see this a lot, right? There’s this #DevRelLife. And you see people who are… humblebrag is an interesting word. But, when you see people who are making a statement about what it means to do Developer Relations that I think is unhelpful.
And that people aren’t doing that because they’re bad people or it’s coming from a bad place, it’s just an expression of frustration at some of the ways in which Developer Relations can be played out in an unhelpful and unsustainable way. And so you see tweets like this, you know, people dressing up Developer Relations as a lifestyle that means, effectively, burning Antarctic ice, by flying across the world, by talking about how they’ve achieved status.
You know, status on an airline is not a benefit, it’s a trap. I found myself idly wondering about what trips I could make between May and the end of this month, in order just to nudge myself order into gold status. And then I thought, “Oh, what am I doing? What am I doing with my life?”
And I realised that that was not a good way to live. And, yeah, so travel is necessarily a part of what many of us do. But I think we’ve got to be careful about how we present ourselves, and how we think about the impact that we’re having on the environment, on the budgets that we are custodians of, and on the developers that we see. And I’ll talk about that a bit more in a moment.
But the main thing to remember is dev rel is a job, it is not a lifestyle. It is not something that we should be seeing as an aspirational kind of Instagram existence, where we talk about all the different and photograph all the different places that we’ve seen. Now, Brandon, yesterday, spoke about, you know, some of the real great upsides of being privileged to travel in our jobs.
And don’t get me wrong, I’m really excited to go and see a new place and to meet new people and to connect with new developer communities. But I think there are some things that we should understand what it means when you travel too much. Basically, you get exhausted. I was talking to someone yesterday about how the average lifetime of a Developer Relations person…not their life, but their existence in a role, used to be about one year and eight months.
If you went across different companies, then, you know, about 18 to 20 months into the role, people would go, “Oh, I’ve had enough, I can’t do this anymore.” And that’s also with mismatched expectations, is to do with lots of travel and so on. But then, you know, when I was doing those trips in and out of cities, and kind of showing up and doing almost a drive-by dev rel, the result, actually, was often indifference from the developers.
You know, you’re not forming meaningful relationships with people if you’re skipping from one city to the next. You’re going to a meet-up, and you’re doing your thing, and then you disappear, and then they don’t see you again for a year, or ever again. You know, what does that really mean? And how is that sustainable? How are you building something meaningful for the developers there that you’re trying to reach? And for the business, someone’s going to ask you, eventually, where is the return on this investment that they’re making in you?
And so, I think there are some things that we need to do every time before we book a flight. And, you know, think about how you can serve your overall strategy in a different way, write a blog post, fix a bug, write some documentation, reach out to someone on Slack, who is in the geography that you want to reach, and see if you can partner with them to deliver the content or the experience you want to deliver, without getting on a plane, without getting on a train, without getting on a boat, maybe, I don’t know.
But, maybe make someone in your community feel valued and help them to then reach out and become a centre of…you know, a contributor to the community. So, we talk a lot about social capital in Developer Relations. If you can help someone build their social capital, then they will, in turn, help others build their social capital within the developer community.
And that’s probably more valuable long term than you speaking at a conference, where maybe 20 people come to your talk. The main thing, though, is, before you get on a flight, ask, “How would this trip serve our strategy?” And if you don’t really know what your strategy is, take a step back and work it out.
But also, we need to be conscious of how we present ourselves. Like I mentioned, that kind of Instagram lifestyle is…it’s easy to get into that trap of thinking, you know, “How can I maximise my points?You know, what next place am I going to see?” But I think it’s… In order for us to have that longer role in the company, and, you know, there are companies like IBM, or Google, or Facebook, or Amazon, where dev rel is really part of the infrastructure, and it’s there to stay.
But if you’re in a smaller company or a company maybe like a bank that’s just getting into dev rel, ultimately, you’re going to fall into that trap of maybe being seen as the party people. And so I think we got to be careful about having fun on Twitter, sure, but also being able to back that up with something serious, something that says, “This is the contribution that I made to the people that I serve, whether that’s the developer community or the people that I report to as my managers, my investors, whoever it is.”
Okay. So what about the business then? I think, often, sustainability here is a problem of mismatched expectations. So, as we come down this kind of very simple org chart, I think the understanding of Developer Relations increases, but we get more and more distant from the people who have the power.
And so, a CEO might see Developer Relations in terms purely of marketing, for example. And so they’ll expect you maybe to have a set of metrics and a set of ways of working that don’t actually fit dev rel, they fit something else that looks a bit like DevRel.
And, you know, maybe that’s partly our fault. You know, maybe we haven’t always been that great at communicating back into the business what dev rel is. And, you know, I’ve worked in teams where they actively siloed themselves out. Well, okay, let me say, we actively siloed ourselves out from the marketing team. We didn’t want to be involved with the CMO, because the CMO was doing things that actually were actively harmful to our perception amongst developers.
And if we do that, and we don’t engage with the business, we don’t engage with our colleagues and explain the benefits of what we’re doing, then it’s understandable that maybe when there’s a downturn or a new CEO comes in, that dev rel isn’t maybe seen as a top priority.
And I think we need to explain to our colleagues that dev rel is a process, it’s something that goes on, and on, and on. And I really hate this phrase because it’s kind of tied up in militarism and so on. But you can think of it as a war of attrition, almost, which I want to find a better phrase than that.
But you’re taking one step at a time, you know, people kind of come in, and, you know, I’ve spoken to startup founders, and they say, “Hey, we want to have a really amazing impact. We want to have this, you know, hyper-growth moment amongst developers.” And, you know, Daniel spoke about not looking for the idea but looking for how you can serve.
And often, it’s a case of luck and being in the right place at the right time that leads to that idea or that way of serving, blowing up into something that really turns into a hyper-growth moment. And most of what we do in Developer Relations, it is a process, it’s not magic, it’s not, you know… and marketers have the same problem as well, of people who don’t understand marketing expect great things to happen after, you know, a Google Ads campaign goes out.
But actually, it’s a long process. And I think, also, we need to get comfortable with explaining dev rel to our colleagues in terms that make sense to them. And so if they understand what we’re doing in terms of marketing or product, then explain it to them in terms of marketing or product.
You know, like, there’s this phrase, “If it walks like a duck, sounds like a duck, and looks like a duck, then maybe it’s a duck.” And I’m not saying that you have to go and pretend that what you’re doing is marketing, or pretend that what you’re doing is product, but at least be prepared to explain what you’re doing in terms that your colleagues understand, and that your management understand, because then that helps us to then have a more sustainable way of doing things.
And this is a kind of difficult place to say this, but a lot of how we practice dev rel is almost kind of Silicon Valley imperialism, you know, or cultural imperialism. We’re going out there and trying to replicate a model of addressing developers, say, in Nairobi, or in Munich, that works here, but wouldn’t necessarily be culturally appropriate there.
So I think we’ve got to be very careful about approaching dev rel in a way that is appropriate to local communities and norms. Because otherwise, again, it won’t be sustainable. Okay. So quickly talking about the developer and sustainability there, you know, there’s a problem of overfishing the same developers, because, even in our communities, we find that there are like 4 or 5 people, or 10 or 20 people, who are really responsive, and really, really engaged and so on.
It’s important that we work with them, sure, but we’ve also got to make sure that we don’t burn them out, we don’t tire them out, and that we find ways of making this a repeatable process, a sustainable process, where we can work with other developers well and build other people up in the community. Also, we got to be careful, like I said, about relying on the same techniques with developers.
So, when you do a meet-up, you know, beer is exclusionary, you know? We had beer last night, that’s fine. But if you hold your meet-up in a pub or a bar on a Wednesday evening, then you’re going to be excluding people who don’t feel comfortable in bars or have childcare issues in the evening.
So, we got to be careful about not just having a photofit kind of identikit way of dealing with what we do. And also, t-shirts. I mean, t-shirts are great, don’t get me wrong, and I love a good t-shirt, and I love the fact that we give them out. But, you know, it’s hard sometimes to stand out if all you’re doing is using the same techniques as everyone else.
And then that becomes unsustainable because you won’t get the results that you need. And so, I think it’s important to be very aware of what a developer looks like, not having this kind of idea that they’re generally under 30, or under 40, and in a certain phase of their life, in a certain way of being, you know? We need to be open and reach the people where they are, rather than just where we’ve done it always before.
And so, in that way, I want to talk quickly about something that Scott Hanselman talks about, the idea of the dark matter developers. There’s a whole group of developers out there that we can’t reach through our normal ways, because at the end of the day, they shut their laptop, leave it on the desk, and go home and do something else. So you have these hard-to-reach people.
And it’s really important that we don’t just keep mining the same group of people because they’ll become less and less receptive to our message if all we do is always speak to the same people. If, you know, 20, 30 different Developer Relations programs are all trying to get in on the same group of people, then it’s going to be really hard. So we’ve got to find creative ways to reach these other developers who aren’t coming to meet-ups, aren’t going to conferences, don’t read Twitter, don’t go on the same blogs that we use to reach people.
And I think at Hacktoberfest, they’ve been doing this, it’s an amazing way to show that you can reach, even using, you know, the same techniques that we do, you can reach other communities, you can reach other people by incentivising and going out and finding them. So can we fix this situation? Of course, we can.
You know, I’m not saying that things are bad, I’m just saying there’s one or two things that could be better. So, I think we’re going to look at developer relations as a virtuous cycle of you do something that builds up developers, developers then do something that builds up your business, because ultimately, you know, they’re paying the bills. And then that feeds you and really becomes a Venn diagram of goodness and just supporting each other, and that becomes then sustainable.
So what can we do on the you side? We need to present ourselves in a way that resonates with the audience that we’re talking to, whether that’s the business, or the developers, or other dev rel people. Working ourselves at burnout is not going to help anyone, we got to have a strategy and act strategically, and remember that it’s not a lifestyle, it’s a job.
In terms of the business, basically, have a really well-worked-out strategy that serves the broader strategy of your business. So that, when you’re doing dev rel things, you’re doing them in line with what the rest of the business is doing. Don’t swim against the tide. And if you find yourself in a company where you would have to adopt a dev rel strategy that you think wouldn’t work or would make you feel uncomfortable, then it’s okay, go and find another job.
You know, Phil, in his talk yesterday, spoke about how, sometimes, you know, companies change or people change. And don’t see that as a blight on you, instead, take advantage of the really buoyant job market and find somewhere where your goals align better with our business.
In terms of the developer, I think we’ve got to be really creative about how we try and reach people. You know, beer, pizza, and t-shirts works only for a certain group of people. So try and understand the needs of developers that you want to reach, and that aren’t being reached now, and who could be built up by your program. And be creative in meeting their needs rather than just mining the same group of people over and over again.
I’d like to invite you to join the DevRel newsletter, but also, I’d like you to submit your talk for DevRelCon London. Thank you very much for listening. I’ll be around, obviously, if you want to talk. And that’s it. Thank you.