Made by
Made by
Ade Oshineye
Developer relations is maturing at pace – and with this maturation comes new ways of looking at common team problems. In this interview, recorded at DevRelCon London 2017, Ade Oshineye, Senior Staff Developer Advocate at Google, talks to Peter Cooper about approaches for people heading up advocacy programs, personas, and the loneliness of the one-person-devrel-team.
Peter: Hi. I’m Peter Cooper. And I’m here today with Ade Oshineye, hopefully I got that quite about right, from Google.
Ade: Close enough.
Peter: Close enough. And you gave a talk this morning about DevRel leadership, which I think is a topic that… Well, you got everyone to put their hands up if they were a leader of a DevRel team. And it was very few people. So this is a niche thing, but it’s a very important role, especially since it hasn’t existed like, for a long time, you know, a very short brief period of time. You’re kind of an expert on this and…
Ade: That’s a little exaggerated, but I’ll take it.
Peter: Well, I mean, exactly as you say, it has been going on for such a short amount of time that just knowing whatever amount you know can kind of make you an expert in these areas, right?
Ade: Sadly true.
Peter: Exactly. It’s a young game. But one of the things I found very interesting, you were talking about, was if you are in a leadership position and you’re doing development relations, is that kind of internally in your company, you need to think of yourself as being customer number zero? And I like the way you explained it by saying you’re not the first customer, because you’re not targeting yourself, but you need to, kind of… It’s just like the old “Eat your own dog food” thing.
Ade: It’s like “Eat your own dog food,” but it’s more than that. So, it’s customer zero, not customer one, because you don’t count. You’re not the target customer. It’s different to dog food because you’re a lot more aggressive, a lot more structured about capturing what works and what doesn’t about your product. You are thinking about, “Where can I use the feedback I collate from the work I do here, to change the product, to make the product better?” So it’s not just, “Hey I tried our thing and it works,” or “We have a new thing. I built a sample. Yeah, it works.” It’s “Can I get in early enough that I can try the thing, keep detailed notes about changes that would make it better, so that when customer number one turns up, the product actually works well, smoothly, predictably, easily? So when customer one says, ‘How do I…’ oh, you have an answer. ‘But what about…’ oh, we have an answer. ‘And then how does…’ oh, you have an answer.” It’s that feeling that somebody has been on this user journey before you and has smoothed the path, so that you’re on a well-lit path, rather than being the first person to explore.
Peter: Does some of this have something in common with the marketing idea of having like an avatar, like where you’re told it’s in…you kind of have this idea of this dream user or this kind of, like normalised user that you’re likely to have. Would you kind of internally build up those types of personalities and be like, “How does our content or how does what we’re saying jive with those kinds of people?” Is that part of this?
Ade: I think that can be part of it, but personas, as they’re known in the UX world are surprisingly difficult to use well. It’s really hard to create personas that reflect your actual users or that cover enough of the surface area of your product. It’s very easy to do them badly. And sometimes it’s better to not do them at all than to do them badly, because that false certainty that, “I understand my users so I don’t need to listen to feedback from actual users,” can become problematic. So you have to start thinking about, let’s say, here are some poor screen personas. I know that they are useful models, not rather than accurate models. And so, as I develop the product, when people tell me things that don’t fit in those personas, I accept that rather than saying, “That doesn’t fit my model. It must be invalid.” So that can be very effective.
Peter: Awesome. Unfortunately, we haven’t got a lot of time today, but I just wanted to make the point that we are at DevRelCon here in London. It seems to be going really well. What’s been your kind of feel of the event, feedback, that sort of thing?
Ade: It’s been a really, really positive event. I’m discovering that so many different DevRel teams at different stages – from the one-person-DevRel team I met, to the large, multinational organisations who’ve got dozens of teams, that I’m also seeing here. So that’s been pretty fantastic.
Peter: Would you say that the one-person-DevRel team is still kind of the plurality of all DevRel people… Like literally, a lot of companies, a start-up for example, would have just like, “You’re the DevRel person now.” Is that the most common thing we’re seeing?
Ade: I would say that’s the most common. The challenge for the one-person-DevRel team is to go from, “I’ve got this job that nobody really understands, and I don’t understand, and nobody can tell if I’m doing it well or not. And nobody will know if I take like six months off.” To go from that to a model of “I have a very clearly understood purpose that everybody in the organisation understands and agrees with, that is linked to specific goals that matter to the company. And then I have metrics to show that I am achieving these goals.” So that when people find out that I’m doing some event somewhere, they can say, “Oh yeah, that event is gonna move these metrics, which will drive these goals, which will achieve this purpose,” rather than, “Why is that person gallivanting around the world again?” or “Why is that person working on this toy sample?” So I think that’s really important and I think that’s what we’re starting to see happen here.
Peter: Yeah, it’s really cool just to see the industry mature and we’re seeing it live happening at events like DevRelCon. So thank you very much for talking to us, Ade. It has been a pleasure. Thank you very much.