DevRel Leadership: all the pieces matter

Ade: I'm gonna talk about their DevRel Leadership. And also, I'm gonna play a game where there's going to be a little subtextual references to "The Wire," and "Babylon 5," throughout this presentation. They'll be very subtle. Come and see me afterwards if you get the references. For example, all the pieces matter. So, I'm Ade. As you can see, I've been an iPhone user for a long time. You can follow me on Twitter but I prefer if you followed me on my blog. That way, I'd feel more pressure to publish a post more than twice a year. I run the patent developer relations team at Google in EMEA. And I'll tell you a little bit later about what that means. This is later.

So, I work at Google. We have a slightly different context to most of you. We've been doing developer relations for about 10 years, we have hundreds of people, we have hundreds, arguably, thousands of products. You can add a joke in there about how many of those are messaging products. But, what you can see from this, and this is from 2009's Google I/O, is that we've been doing this a long time. We have a lot of different products aimed at developers and we're always launching new ones. So, the challenges we face as a large, I wouldn't say mature, but long-lived developer relations organisation, are the kind of things we think you will be seen soon as you grow.

Rock stars and cargo cults: what is DevRel?

So, we have some fundamental questions like, "Who the hell are you people?" I know we've been doing DevRel for 10 years but people still come up to us and say, "So, what is DevRel?" And we go, "Well, what do you think is DevRel?" And then, you sort of cringe because they tell you, "You're those people who do hackathons and go to the conferences for a living." And you go, "Well, it's technically correct but it's not really the whole thing," and they go, "Yeah, yeah. But you guys, you know, people who blog and tweet but aren't social media gurus." We go, "Yeah, but that's kind of a little unfair."

And then, sometimes, they claim we're rock stars. Now, I agonised for a long time about including this slide because, on the one hand, I don't think that overdosing is something we should take lightly, but on the other hand, we should point out that people, when they call us rock stars, they actually mean it in a positive way. And you kinda go, "Well, it's true but not really because of the positive things but because I see a lot of people in DevRel who travel a hell of a lot, who become disconnected from their families and from the companies they work in, and can end up being very unhealthy states whilst getting, you know, public admiration, as they drive themselves off a cliff." So, that's something I worry about a lot. Especially if you're in a small or young DevRel organisation and people say, "You guys are rock stars," and you feel that pressure to go and be that.

The other thing I worry about is whether we're a cargo cult. So, does everybody know what a cargo cult is? Okay. So, small digression, back after the Second World War, there were these islands where the U.S. military had landed and it basically showed up by doing this, cool stuff would drop from the sky. And so, after they left, the people in those islands went, "All right, I'll just make a thing like that and I'll do this," and cool stuff did not drop from the sky. And so, my fear is that you read Tim O'Reilly and you go, "Wow, if I create more value than I capture, I will automatically build a cool successful Web 2.0 platform that gets lots of users," right? I just need to wear the hat.

Beginning at zero

And I see people spitting up DevRel teams or DevRel organisations and they're not really sure why they're doing this. They've just heard that it should. So, one of the big questions for me is, what should a DevRel team be? What should we be? My personal belief, and the thing we tend to use at Google, is that if you find some way to combine being Customer Zero, anybody not heard of Customers Zero? Okay. So, Customer Zero implies that when some team within your company builds a develop product, you're the zeroth people who use it. You're zero, not one, because you don't actually count, you're not the target user and you have to be very aware of that.

When I was in the social web team at Google, we did a thing, we put it out there, and it turned out not everybody else was intimately familiar with the oil spec. And we were like, "But, I checked. We have a diverse team of developer advocates here and we all know of." And it turned out we weren't representative of the people in the outside world. That was a shock, especially at Google.

So, you got Customer Zero, you're the people who try it first, you're the people who deliver the feedback initially about, "I see what you're trying to do but that's not going to work because..." something. Or, you know, "You need to change it like this to make it more acceptable to the target user." And one of the great things about being customer zero or developer zero is that when you then have to support this, you get to say, one, "Told you so," when other people struggle to understand the concept you said they would struggle to understand. But also, you then have to help those people be successful with the API, or SDK, or platform that your organisation has built. I think that's a really big part of DevRel.

Bi-directional advocacy: DevRel as a bridge

I think another really big part of DevRel is this notion of bi-directional advocacy. We speak to the Google, in my case, Google teams or internal teams, on behalf of the external developers. We also speak on behalf of the internal team to external people. So, we're this bridge. We stand between the something and the something. And basically, we're these people in between who try to make sure that both sides understand each other's needs and it does mean that sometimes we're the people who are super annoying to both sides.

Because you're going to the, you know, engineering team, "Look, you need to do this because external developers are begging for it. They need this." You know, and they go, "But you wanna postpone it," like, "No, no. This is really, really important." Then they'll go to the external people and say, "Hi, the thing you want, it's not ready yet. But, we're working on it and I'm so sorry." And they're going, "Yeah, you're just a shield for those people." And then you're going to those people and saying, "You need to do this," and they're going, "God, whose side are you on?"

So, bi-directional advocacy is a really important, really stressful part of DevRel. The fact that both sides hate you equally is probably a good sign. Ideally, both sides love you equally because they both feel that you are helping them be successful, but sometimes you have to settle for what you can get. So, that's sort of a very quick overview of what it means to be DevRel.

Becoming a leader

But, what does it mean to be a leader in Developer Relations? Who here runs or leads a DevRel team? Put your hand up? Okay. So, quick, wait, keep your hands up. Give everybody else a chance to look and see. We actually have a lot of people around who lead DevRel teams, you should go talk to those people. They probably know what they're doing.

So, I've been at Google 10 years, I've been in DevRel 7 years, I don't know what I'm doing. Don't tell my manager. And part of the reason I don't know what I'm doing is that the job changes every day. The thing we were doing isn't the thing we're doing. When I started in DevRel, I joined the social web team. Then we became the buzz team, then we became the Google+ team, and then we became part of the developer relations, and where we work on all of Google's early stage stuff with a small set of Google's top partners.

For the last several years, I've been the developer advocate who've been primarily working with the Facebook companies. So, the biggest thing I've done over the last four years was launching the Google Drive WhatsApp backup process. So if you use WhatsApp on Android and you back up your messages to Google Drive, I made that happen. Four years of my life. It's literally the only thing I've ever done that my relatives in Nigeria actually feel is valuable. But, that's not what I do. But, the funny thing is, that's not what I joined DevRel for. I joined DevRel to do cool stuff with APIs. I didn't join DevRel to build things that could have been useful to people. So, if you're leading a DevRel team, a big part of your job is to articulate and re-articulate the purpose of the team.

Because, the person who joined to do this thing is going to feel very uncomfortable if your product changes or your mission changes. Maybe you started off, "We're just here to drive adoption of cool, open, social APIs, man," and then, open social starts being a thing. "Oh, what do we do now? Why are we here? Does it matter what we do?" So, you have to be able to explain to your team and to all the other teams why does this team exist, why do we matter, why should we continue to exist? Small tip, if you stop doing this, or you fail at doing this, your team will stop existing. Ask me how I know.

Putting it in context

You also need to be thinking about, "What's the organisation I'm in?" If you have a purpose, that purpose doesn't exist in free space. It's connected to things the rest of the company is doing. It's connected to things the rest of the industry is doing. It's connected to things the community is doing. So, you need to have a pretty good map of all of these things and how your purpose fits in. Is your job to drive adoption of stuff? Is your job to help improve the quality of the things we're building?

So, if you ask me what is the purpose of the part in a Developer Relations team, I have a cute one-liner about how, "We're here to work with early stage products and Google's top partners to help drive those products to maturity for the mutual benefit of those groups." You should say it less cynically. But basically, you need to have this very clear explanation of what you, why it matters. And you have to, hopefully, believe it because you've got to sell it to everybody. And when it changes or when it stops being valid, you have to find a new purpose for your team.

So, who here has heard of Dadela Meadows? Okay. There'll be a link when I post the slides up, you should take a look at her stuff, she's much, much better stuff than me. But, she has this whole thing about how in any ecosystem, there are points of leverage, places you can intervene to make a real difference. And it's a very long list and if I start talking about it, I will digress and we'll lose like the rest of the day.

But, one of the things you want to do with this map of your organisation, your ecosystem, your community is to think about, where are the places where when you intervene you can make a difference? Because, that lets you prioritise what you do. It also lets you shape your organisation.

Getting the right design

So, one of the harder things about being a leader in DevRel, especially as the team or the number of products grows, is you have to start things from the design of your organisation. In the beginning when there's two of you, yeah, it was easy. You do that bit, I'll do that bit. As you grow, a lot more complexity goes in. For example, my organisation recently re org’ed, and so now, we're regional.

So, we used to be, you know, divided in verticals. And so, I worked with, you know, all the social and publisher companies, which was great. But, it did mean I have a regular fortnightly meeting at half past midnight with Facebook. And I've had that for three years. Not great for work-life balance, but you got to do really cool things that people in California have heard of. We've gone to a regional structure because, well, people would like to go to sleep before midnight but also because the size of the team and the nature of the problems we're trying to solve has changed. So, we had to re-org.

If you're thinking about building a developer relations organisation and you've got this map of the ecosystem, you can start to think about things like, "Should we be focusing that outreach?" Should you be thinking, "I want boots in the ground?" Any time there's a conference about this topic, I want somebody from my team there in a branded T-shirt, waving the flag, because otherwise, nobody's heard of our product. Maybe, in the beginning, you need to do that, but when people start saying, "Cool. How do I use your thing?" Oh, well then you need to have people focusing much more on samples.

And again, it may not be the same people. The people who are great at going out there, hitting every conference in the world, may be too burned out to actually be any good at writing samples. They may not have had enough time to go really deep on the product and really understand it to be able to write good samples. They may not be plugged in to the right developer communities.

One of my favorite examples of this, and we're all friends here so you can keep this quiet, when Google launched gRPC, There was a python sample that was written. It was great. I was reading it, and the funny bit, I was thinking, "There's something odd about this," and then it hit me, it had semicolons at the end of each line. Now, that's perfectly legitimate Python code that nobody in Python has written in, I don't know, 10, 15 years, and I've been using pythons since the late 1990s.

And I just realised whoever wrote this isn't really embedded in the Python community. But, I suspect there was somebody whose job it was, they were writing a bunch of samples in a bunch of languages, and at some point, they got Java in the brain, and it was just, everything is Java. And I went, "Oh, okay. I'll just send you a poll request to fix this." But, you need to have people who are embedded in those developer communities if you're gonna write good samples for those people.

The most suitable support

If you are going to do developer support because it turns out people are trying to use your thing now and they have questions, you've gotta say, "Okay, where are those people going to be?" The temptation is to say, "Well, we're on Stack Overflow, they should come to us." "You want support? We'll be on this street corner between the hours of 2 and 4. Come to us." Or, the alternative and probably the better approach is to say, "We go to you. And then, we support you where you are, how you like it." Are you on Slack? We'll go to that. Are you on GitHub? We'll go to that. Are you on various random forums? We'll go to that."

So, but that's it, again, it's a very different kind of organisation. And the people who sign up to go and do cool conferences may not be interested in waking up every day and saying, "All right, there are 20 questions in Stack Overflow. I will go research, and debug, and answer them for people." As you get larger, you may start realising you can get a lot more impact by one really amazing integration with a cool partner than by doing lots and lots of small ones with individual people.

So, the WhatsApp Drive integration that I spent four years on, like, was it worth it? Well, we have 430 million, the actives, you know, that's pretty good. It's bigger than anything else we've ever done for drive. I can tell you this because we present with them at I/O. The thing is, at the stage of the lifecycle that Drive is in, that kind of thing reaches many more people and better exercises the APIs and the SDKs than having the 50,000th developer do a very small thing. And so, then you need a very different organisation to do this.

Helping your people grow

You've got to look at business development people. You've got to be comfortable having C-level meetings and talking about cross-functional integration. You've got to be happy with things like case studies. You've got to be happy interacting with people in suits. But, again, that's a very different set of people to the people you started with. And then, as time goes on, and this product becomes more stable, more mature, you've gotta start thinking about building a healthy community. Something that is going to have longevity.

Again, that may not be the same people who are happy hanging out with a suit and tie crowd. Now, you can't be firing people every time you wanna change because that's not a healthy organisation. But, you can't just be, "Oh, we'll just add some suit and tie people, we'll add some BD people, we'll add some marketing people." You've gotta be thinking about how you manage these transitions.

So, I've put these two together because, well, one, I couldn't draw a nice little diagram about how they feed into each other in the beautiful circle of life. But, you've gotta help your people grow, and you've gotta manage your stakeholders. What does that actually mean? Well, when I think about how people grow in your DevRel organisation, I need to have some answer for them that isn't, "You sit there answering tickets, and growth will happen. Trust me." You need to have something better than that.

Don’t lose touch with the external community

You also need to have an answer to this question, "If I stay here for five years, will I be better than I was when I started, or will I be worse?" A funny story about something that happened to me and Guido Van Rossum once at a Python conference, a guy comes up to us, I say "Us" but the let's be honest, they came up to Guido, I was standing next to him, and the guy had a question about, I think, Virtual M, I think it was. And he came up to us and he said, "Hey, I have this problem. Can you help? And Guido and I looked at each other, awkward silence, and then turned to the guy and said, "We work at Google. We don't use that because we live in our own parallel universe of internal tools." And the guy's face was so disappointed, although, again, mostly at Guido.

But, the thing that captivated me was that, if you stay in a big organisation for a long time, you have to watch out for this effect where you focus on your API, your stuff, and you slowly lose touch with the external community you should be a part of or you're trying to help. And so, you have to be taking actions to prevent your team from just rotting in place. Because, if I'm running around the world doing conferences, focusing on the next release of our API, doing that, doing that, I lose touch. I start to decay. I become less valuable in the external community. I start thinking about, "Well, what jobs could I do after this?" And they're not as cool as the current job. I'd have to go back to then go forwards again. That's not healthy.

Measuring happiness

And then, finally, and this is most scary of all, are they happy? So, I do one-on-ones with all my people and I always ask this super cheesy question that I got from my manager, which is, on a scale of 1 to 10, how happy are you? Everybody knows it's super cheesy. Everybody knows I always ask it. And everybody gives me a fake answer, every single week. Because, it's easier than having to really think about how happy you are. But, every now and again, somebody who's been saying, "I'm a 9, 9, 9, 9," for two years, will say, "I'm an 8.5." And you go, "Oh, what's changed?" And you can have a really useful conversation about what's changed that's meaningful.

Whereas, if you were to ask them, "So, I see you're unhappy," or, "How are you feeling?" Or, any kind of touchy-feely thing, people feel uncomfortable having that conversation with you even if you've been their manager a long time. But they will tell you stuff like, "Well, I'm a 8.9 today," and they won't realise what they just told you. That something dramatic has changed in their life that caused this tiny shift.

You will also get people who'll be 2 forever. And then, they'll be, "I'm a 5 now," you'll be like, "Woah, what just happened?" And they'll be, "Oh, I'm getting married." And then, "Oh, that's amazing." The thing is, you have to know that person and you have to understand the implications of these small changes especially if you've got a DevRel team that's distributed or travels a lot. You have to, as the manager, as the leader, to go to extra lengths to connect to them.

The Hawthorne effect

Same thing happens with your stakeholders. You've got to know who they are. Who here doesn't know who their stakeholders are? Liars. Basically, your stakeholder isn't just your boss, it's all the different people who have a vested interest in your success, or failure. You gotta know what they want. And finally, you've got to know, are they happy? Because, you can end up in a situation where somebody says, "Look, I want you to get a million Twitter followers," "All right, fine." You go out, "I have a million Twitter followers." And they say, "Oh, I'm not happy." "Oh, what was it you wanted?" "Oh, I didn't want you to get a million Twitter followers, I wanted what I imagined would be the outcome of that."

Or, "I want you to make a YouTube video about this new API and I want it to get 1,000 views, "Okay I've got 1,000 views." "I don't care. I wanted actually 1,000 people to click through from that video to our thing and sign up to start paying for it." "Oh, but you didn't say that."

This is not a reference to Leslie, it's another Hawthorne. So, the Hawthorne effect is basically this thing where when you tell people you're measuring something, it changes their behaviour. If I'm gonna measure how many retweets you get, you're gonna change your behaviour. If I tell you I'm measuring how many stars your repo gets on GitHub, it will change your behaviour. Not always in healthy ways. Even if I tell you about a Hawthorne effect, it will change your behaviour.

I recommend you look up the project where this came from because it's a fascinating example of people's behavior changing as they discover the Hawthorne effect, and then changes because they've now heard about it, and then changing again. I've seen this a lot in organisations where you end up managing to the metrics rather than to what you're trying to achieve.

Who, here, has heard of Mullah Nasrudin? Hey, we got a couple Sufis in the room. The Sufis are a little sect of Islam. But, they have these interesting stories about Mulla Nasrudin, who's like a Holy fool. And there's this story where one day his neighbors go past his house and he's out there in the dirt, scrabbling around, and they say, "What are you doing?" And he says, "Oh, I'm looking for my keys." And they go, "Oh, cool. Where did you last see them?" And he goes, "Oh, somewhere over there in the dark," and they say, "So, why are you looking here?" and he said, "Well, this is where the lamp is."

An acceptable way of failing

So, a lot of organisations get caught in this trap of doing the thing that is easy to measure, that feels natural, that feels good, even though that's not the thing they're supposed to be doing. We blog a lot. Well, that feels good. We tweet a lot. That feels good. Is that what we really value? "Oh, no, the thing we value is this other thing that's really difficult to measure, and it's kind of murky." "Oh, so we're not doing that?" "No." This is what, in the old days, on the C2 Wiki, we call an acceptable way of failing.

A lot of organisations get caught in this trap of, "There is this thing we do that we know doesn't work, but it feels good and it's psychologically safe, so we keep doing it." So, at Google, for instance, we do big launches at Google I/O. The problem is everybody does big launches at Google I/O. So, you go, "Here's my new API," and then people skydive out of a plane. So, when, at Google I/O, they did the skydiving thing, [inaudible 00:24:20] was on stage talking about an API. Nobody remembers that API. I don't remember that API, and I worked on it.

So, part of your job is to wean people off of these acceptable ways of failing. I've got one minute left, but I'd like to take 15 seconds for people to shout out acceptable ways of failing that they are currently doing. Don't worry, I'm the only one being recorded.

Male: Events.

Ade: Events, okay. What else? Come on.

Male: Twitter.

Ade: Twitter.

Woman: Blogging.

Putting all the pieces together

Ade: Good. So, that's important, you've got to be thinking about how you wean your organisation off this. And then, when you put all the pieces together, you've gotta be thinking about how you build an organisation that is purposeful and aligned. So, to do that, you've got to clarify the purpose of the team. Why are we here? What are we doing? Why does it matter? You've got to identify goals that are connected to that purpose. And then, those goals have to be measurable. You have to be thinking, what are the metrics that will tell us if we're going towards those goals or if we're just doing stuff that feels easy and comfortable but isn't helping us achieve our goals?

You then get a look at the activities you're doing. All the activities you're investing in, moving those metrics which take you towards those goals, which help make it clear that you're achieving your purpose. Are the activities that your people engaged in helping them to grow? And, what are they growing into? Hopefully, your people are growing into new leaders who can define a new purpose for your entire organisation. That's what I think DevRel leadership is all about. Thank you very much