Empathy is a big theme in developer relations but we’ve got to remember that it goes both ways. RedMonk’s James Governor makes the case for taking care of ourselves in dev rel as we also care for our developer communities, in his Stones-inspired talk at DevRelCon London 2018.

Transcript

When I talked to Matt about coming and speaking here, he said, “Look, you know, you have to deal with all these boring big companies.” And not everyone here is used to that experience.

So why don’t we talk a bit about that and the challenges of, like, scaling some of the things we’ve spoken about today. How do you scale empathy? How do you maintain a vigorous community and ability to talk to all of them, when you’re a company that might have 400,000 employees?

Is it empathy or sympathy?

So we came up with a title, I thought it was kind of clever. It was empathy for the devil, so I thought let’s talk about having some empathy for the big companies.

And kind of yesterday, I was at lunch with a guy called Alexis Richardson, from Weaveworks. Tamao, I think, might be here and works with him, you might have heard from her earlier giving some great tips about how spirits ambassadors is a good model for DevRel.

Anyway, he said, “No, no, you’ve got it wrong, it’s actually sympathy for DevRel.” So great, okay, I’m going to throw out all my slides and start again. There’s a guy called Alvaro Videla, and he said, “But obviously, if you’re going to do that, it’s, you know, you got to run with this Rolling Stones theme.” So anyway, I am @monkchips, very noisy on Twitter.

You probably shouldn’t follow me if you’re interested in high signal to noise. My company RedMonk, we really focus on developer-led adoption of technology. So we’re an industry analyst company. There’s, you know, loads of those. You know, the big one is one is Gartner. It’s very much about top-down adoption of technology. We’re very much about bottom-up adoption of technology, basically by the kind of people that you’re working with every day.

So we spend a lot of time trying to understand the influence patterns to developers that gets platforms chosen and adopted more broadly. So yes, “Sympathy For The Devil.” I think it’s an interesting track in that…you know, in the most famous aspect of that track is the “Woo, woo,” right? And I did think about getting you all doing that, but Steve tried crowd singing earlier, and I thought, actually no, that’s not going to work.

Working for the Man

But wait, should we do one? Should we do one “Woo, woo.” Woo, woo. Right, so the “Woo, woo” was actually Jimmy Miller, he was the producer. So he’s not in the Rolling Stones, he’s the producer of the track and he was messing around when they were recording it. And that was not actually supposed to be in the track. In fact, it ended up being re-recorded by the band themselves.

And then of course, what happened is the record company said, “We really don’t like that, that’s really stupid. What you’ve got to do is get rid of the woo, woos, right.” How different would history have been without the woo, woos, right? And that is what big companies would try and do to you every time, so you got to sustain that energy. And you know, when Jimmy Miller says “Let’s add some woo, woos,” you’ve got to run with it.

So how do you know that you work for the man? Okay, good, this hit really well, none of this material is mine. This is Alexis and Alvaro. Again, it’s all about learning and packaging the community experiences and making them pop, which that just totally did.

I think the Concur one in particular, like who here has used Concur? If you haven’t, you’re really lucky, right. So okay, I don’t need to talk any more to that slide. This is good, I’ve made progress.

Let it bleed and Paint it black

So let it bleed, right. So one of the things is that ROI thing, you have to spend money on DevRel. And the big companies understand this, and the small companies have to understand this.

Kind of interestingly, hearing from OutSystems today was about their journey to DevRel, right, been doing DevRel for three years. And there was a real sort of apology about it, you know, sort of, “Well, actually, we’re a commercial company, so we’re not really sure DevRel was for us.” What hippies did they think we were, right.

So yeah, yeah, we’re all here because we’re trying to get people to adopt technology, and, you know, get paid and, you know, that’s all good. So you got to spend money to make money. And one of the things is look, listen to the DevRel… I mean basically, it’s just me ranting. Make sure that your bosses understand the work you’re doing is valuable, and yeah, sometimes you’re going to spend way too much on beer.

So that’s okay. Paint it black. This is what not to do, right. You know, this is not Henry Ford. Developers want to have choices, and they’re going to want to integrate, and do weird wonderful things with their technology. And not everything is going to be you can have anything you want as long as it’s black.

And I think this is super important and again, something that DevRel tries to persuade the company of, tries to persuade the Man of, and it’s just super important. That at the end of the day, there isn’t just one choice.

Get off of my cloud to getting (no) satisfaction

Get off my cloud. Obviously no developer, imagine that, is going to say that, right? He’ll try to do the opposite.

But actually, in terms of this world of choice, sometimes you do. So you know, if you look at Google, they’re like actually portability is important, the entire Kubernetes phenomenon has been about saying what Simon Phipps talked about earlier. Freedom to leave, open source gives you choices. And actually sometimes, you’re like fine, we will support you to get off my cloud, but if you wouldn’t mind getting on it first, that’ll be wicked.

Right. Can’t get no satisfaction, that’s developer’s. Nightmare. The only thing they want to pay for is Max. And you cannot please them no matter what you do, sort of you just… doesn’t matter what you give them, they’re going to want more. You will get kicked in the nuts, there is…well, that’s a bit gender specific. Code of conduct, sorry. You will get kicked, you will get kicked.

So anyway, I used to run an event space and I gave it for free to certain communities that I thought we were supporting. One was WordPress, London Node User Group, the London Java community, so they would use the space and we got our stuff for free.

But I’m not going to say which community it was, but I had this wonderful moment when everything had been free, but like we’d found out that like, “Look, can you at least…we’re not going to pay for the pizzas.” They wanted to buy from Pizza Hut and we said, “Look, can you use our supplier because that way we can at least make a couple of quid on this thing.”

And the next day, I got a call, “Do you know what? Way too many olives on the pizza.” So people are not going to be happy, that goes without saying.

You can’t always get what you want

You can’t always get what you want. And you know, I think this cuts both ways as developer relations professionals, people doing DevRel, you know, you can’t always get what you want, but you might get what you need, you might get people adopting your technology.

And I think the thing is though developers are…you know, they’re not going to be satisfied, but things they do like, and they will, from time to time, like something, then, it’s not you doing the advocacy. It’s them doing the advocacy. And I think that’s what’s so important about…I mean that’s where so much of the satisfaction about this role comes from. When your users, when the developers you’re talking to are actually your best advocates, that’s just incredible, and obviously, that’s what you’re trying to achieve.

So I mean one of the things… so it hasn’t been, I thought it might be a theme today is what are the differences between the different disciplines that we do? And you know, some people are very keen for advocacy, developer, experience, they’re all sort of related. And bring that empathy thing in. I began to think is empathy like sort of where you are in the experience?

So like developer advocacy, you’ve got empathy for the decisions that people are making, and you take that back, and you take it to engineering. So empathy is sort of back-ended, it’s an after the fact thing. It’s like you’re listening, you’re bringing that back, and that’s a strong advocacy position. Developer relations, that’s sort of in the moment, you’re doing your presentation, you’re trying to bring people in, you’re doing the demo that they like.

Our language and experience

Developer relations is empathy at the point. And actually, developer experience is all about empathy, it’s not front loading the empathy. And I think there are some critical things here. We talk about inclusion, code of conduct has to be part of DevRel. It’s not just the events we go to. It has to be part of sustaining inclusive communities. Basically, you’ll have better communities.

I thought the point about language from Alex was absolutely on point. Language is super important and thinking about that, the code of conduct. Documentation is about front-loading empathy, like let’s try and make this easy for people. And you know, who does this really well? Stripe does this incredibly well. I think what’s interesting about Stripe, is they’re, you know, absolutely crushing it.

Sorry, I’m getting a bit dry. But their developer experience team is quite small, it’s like 12 people. They really focus on flying less and writing more. So they’re not going to every single conference, but what they are doing is creating amazing content that ties into really well-designed APIs.

So it’s video and amazing content, they’re not constantly in the air. Which again, goes to the kicking the hornet’s nest earlier that we can’t be on the road all the time. Visual Studio Code, it’s amazing, right, so that team that’s like 20 people that build it, 13 engineers, many, many great software projects, all small teams. It’s only developer experience, there are no evangelists.

Think of all the users they got because of the experience they’re creating for people that want to code in various languages. And I think that’s an incredible phenomenon, and it’s remarkable work that Erich Gamma’s done.

Catching the wave

MongoDB, Mongo gets a lot of shit, right. Loads of people are “MongoDB, it’s, you know, whatever. They were created by marketing, you know, it’s not the best database,” and all this sort of thing. But the reason they won is that they were so accessible and easy. They caught a wave. It’s like people needed a document database for JavaScript. They were just like, “Okay, we’re going to use MongoDB.” It was the easiest, it had great sort of language bindings, it felt good, so they used it.

And it didn’t happen because they spent loads of money on marketing, unless marketing is creating a great developer experience. Twilio, I think Twilio is really interesting because, I mean, you know, they got to their IPO out of industrializing DevRel. It’s amazing. They hit that, sort of, you know, hackathon wave so perfectly.

Twilio is just like there at every hackathon. It was like, “Well, here’s the moment when we’re getting off the computer and on to the phone. It was just interesting the way they industrialized that so cities around the world working incredibly hard and that really made Twilio. And I think it’s quite… because that was definitely DevRel. It was great people getting involved in hackathons and getting people banging away on these APIs.

IBM, totally different, obviously. So what do I want to say about IBM? So IBM is interesting, we got some IBM people here, I know that, so I’m going to be slightly cautious. So from the top down, IBM is always sort of, you know, are we interested in developers or not?

We sort, we’ll say we are, but we may not entirely be. Really interesting thing about Red Hat acquisition is IBM moving down the stack, saying we actually do need to be talking to infrastructure people. But I think the thing that I think is really interesting about IBM is it’s like Rome, right. It’s just the people out in the provinces doing stuff.

Supportive, inclusive environments

The team here in London is doing great work, the folks in Hursley doing… I mean, anyone here use Node-RED for IoT? Great platform, and it just sort of started out of people building stuff, it was engineering-led, and IBM just let them get on with it. So R&D, creating great experiences, it hasn’t been a top-down phenomenon.

Azure, I think, is interesting because… I mean Jeff Sandquist says when he rejoined Azure from Twitter, it was all about creating amazing documentation, he was there to fix Microsoft documentation. Now, I like Jeff a lot, but I’m not sure he has fixed their documentation, however, he has hired everyone.

Oh my God, the talent that he’s got at his disposal now is incredible. Now some of that is just the budget they’ve got. You know, they’ve got these incredible franchises so they’ll invest in that. So you know, yeah, and it just goes on and on. I mean, is Chloe here?

Chloe? No. Anyway, their latest hire, so everyone is joining them because they are paying above market rate. And just it’s a supportive environment. They’ve done a brilliant job of inclusion. The women on that team are going out and persuading other women to join them because of the great experience they’re having, absolutely smashing it.

DevRel is hard

So it’s like, “Yeah, this is great, we’re doing really well.” But DevRel is hard. It’s like this, it’s like debugging in production. It is really scary, right. You’re out there, you know, you’re trying to get Wi-Fi to do your demo. That’s breaking. You know, you’ve basically forgotten a string that you needed in your demo, something’s breaking, you’re trying to work it out.

You’re working really hard, you’re worried that you’re not going to be able to keep the audience happy. There’s a lot of nerves that go on in DevRel. You know, we talk about impostor syndrome for a reason, I mean, we’re always potentially in a room with people that are better at what they do in terms of the development than we are.

It’s part of the thing, it’s a big challenge. I mean, for any tech talk you ever do, that’s the case. So impostor syndrome can be a thing. I think there’s a lot of…there’s so much fear and hard work and emotional labor that you do in developer relations that’s really not fully appreciated by the companies you work for.

You know, this, to me… I mean, Paige Bailey, she’s amazing. She left Jeff Sandquist organization. What’s the chance of that happening? So Microsoft hired everyone, Paige has just joined Google. But here’s the thing. She said, “I need a vacation, yeah, I’m taking one on Saturday and Sunday.”

That’s the weekend, what are you on about? What are you on about vacation? That’s not a vacation, that’s a weekend, come on. So you know, that, to me, was… I was just like…and honestly, the Microsoft team is incredible. Honestly, I don’t know, they haven’t had a chance to say they are hiring, they are hiring.

I want more people to join that company because so many of those people are my friends, and boy, are they doing a lot… and girl, are they doing a lot of miles. It’s so much travel and they’re internalizing this, right. I mean, after a few years in DevRel, DevRel life, this is a 29-year-old DevRel professional. They look pretty good when they started at 23, but let me tell you.

The company is not your friend

So here’s the thing, the company is not your friend, they’re really not. Companies are sociopaths. I actually don’t think they’re people either, what with their voting rights and all that weirdness.

But you know, a company is not your friend. They might get acquired by somebody. They might have to do a resource action. The company is not and never will be your friend. They are, by nature…I mean well, they’re not people so they can’t be your friend, right. And I think that we commit so much to them, we’ve done all this emotional labor on their behalf, but they’re not your friend.

And I think it’s really important in developer relations that you remember that. “No” is your friend. Saying no to things is the most important thing that you can do in developer relations. Fly less, write more. Explain that you’re going to spend time on documentation.

Just say no

Explain that you’re not going to go to that conference. You know, there are some great conferences, but you can’t go to all of them. It will kill you. So just say no to things. You are really good at what you do. And not just that, but everyone is hiring, right.

You are amazing. You work incredibly hard. You inspire people every single day. And I think, for me, you know, thinking about this, the point of empathy for you, the point of sympathy for DevRel, is exactly that, you have a choice, right. Reach out to your friends, spend time with your families, do self-care, you know.

How many of us are like, “Oh, I didn’t have time to do the exercise I wanted to do, or I can’t eat well when I’m on the road,” or all of that stuff. You have choices. Say no to things. And as I say, everyone is hiring.