Engaging across the business

Tim: I live in Berlin, which is nowadays becoming the city for developer relations. I hear making friends, we still love you. So reason why Berlin is actually a great place to find developer relations people is we are very, very funny. If you have a slide like that, if you have a slide like that, you need to have at least 20 seconds for people taking pictures because that's the one moment that everybody keeps. I'm sorry I don't get that. And we're also great networkers, which clearly is being demonstrated over here. I get that we have a lot of culture. So the title of my talk, you might've seen it on the website, is called Engaging Across the Business, which is a very vague thing.

So we talked about the buzz wordiness of a talk title. Maybe that's one of them. What that really means is I want to talk today about how to keep in touch with people who actually build stuff and beyond those people.

So I used to work for Samsung in the developer relations department. I was part of the PayPal and Braintree crew, and nowadays I actually work at Google and there is a lot of different varieties of doing developer relations. As we learned, I mean pretty much throughout the whole day, but you all know through your daily cycle for your daily duties that sometimes it's very easy to be in de row and sometimes it's very hard to be in death row. So I want to give a few different perspectives on how I try to approach this, what I learned now at my time at Google, which is more than eight months already. So I try to share a bit of insight of how we do that, but I learned in my previous gigs and where I see some sort of red line of what works and what actually doesn't work well.

So what I'm going to talk about in my talk today is three different things. The first thing I like to call the great Divide, it's pretty much we stayed off developer relations and people who build things and often it turns out that there is a huge gap in between the two of those things. Then I would love to talk about managing expectations. I know Ray is also coming up here afterwards and he's going to share his thoughts and metrics. We have seen lots of discussions on how efficiency and value of a developer relations team is being measured. So I would like to add some thoughts to that as well. And then actually probably what matters, really how to provide real value, how to make sure that what we do actually really matters and not just to us as a team because we want to be people that want to talk to developers and startups all day, but also internally because we need to have that support and we need to actually also bring benefits to the company.

So if we go to the great divide, if we start talking about this kind of big gap that sometimes occurs at companies and sometimes it's actually non-existent, I mean literally something that turns out when developer relation teams emerge, there is usually two different stories how those things happen.

On the one hand, there is a marketing department as we learned that thinks, well we should actually reach out to a new target audience, so let's do that, right? And they have people that are good in talking, good in writing, good in some sort of skillset, starting to talk to developers and that might or might not work. But today what I want to focus on is literally the difference. I want to talk about developer relation teams that usually start within engineering. So Phil earlier actually said that a few different teams within companies are part of different product groups, part of different business units like sales, like business development marketing at Google, it actually happens to be that we sit under engineering.

So for us, it is maybe a bit easier every now and then to justify our means, but it still actually is something where we need to provide value. So it doesn't mean it's the holy land where everything is great just because we talk to engineers. So if pretty much whenever a developer relation team kicks off, it starts with people that are passionate about sharing what they do that are really caring and that they are proud of what they built.

So they go out to be developer growth and they start talking to developers and then usually it starts to crystallise out that there is a few benefits with that employer branding, recruiting new talent, attracting people to the company because clearly you build cool stuff, you have an amazing stack. You might use open source, which used to attract people a couple of years ago. So maybe I am actually interested in working for you.

That is a great reason why people do that. Another one is product marketing. Of course we have maybe an SDK that is developer facing or startup facing. Sometimes it's even just actually reputation management. So there's multiple reasons why companies start supporting those that actually start building something like a death rail community over the course of the years.

Usually what happens is then that the two groups slowly start diverging into two different entities because it turns out people that go out and talk a lot and people that actually have to do engineering full time, they have different kind of ideas of what they should be doing all day. And we all know it's very hard to have context change every day. If I go and I bid an SDK or if I actually bid on the main product and then I have to go out the other day to actually give a talk about this, I need a lot of time to prepare that.

And sometimes managing both things at the same time can be a huge hassle. So what happens is there will be a few people within those teams slowly crystallising out, becoming kind of the phased of engineering within the developer community. And then what happens, and that's what I've seen with a lot of companies, the bigger the developer relations team gets and the more attention that team gets, the bigger is the need to actually formalise that as a dedicated team. So once we have that team, once there is this crew of people that do this on a daily basis, a disconnect actually is being created because suddenly you're not involved in engineering on a daily basis. You're not necessarily at every standup because you might be travelling, you might be speaking at a conference, suddenly you actually are not doing this thing on a daily basis.

And that creates what I call that big gap, the great divide.

So I today want to talk about this divide and how you can fix that and how if you want to and if it makes sense to you here in the crowd, how you can actually leverage that even to be more efficient. If we look at developer relations, we just had a talk pretty much about different roads within developer relations and there is so many different definitions of advocacy versus evangelism versus different programme managers versus marketing and so on. And I'm going to go into a few of those that we actually have at Google because that helps kind of clarifying how we keep track of what engineers needs, what our community needs and how we communicate that. So one of the very prominent roads that we have is a so-called developer programmes engineer. Those are people that sit with the developer crew with the engineers of different products and they actually build sample code.

They are active on Stack Overflow. They are an outlet from the developer community within Google, but they are very much involved in doing development on a daily base.

So you'll see them less often on a stage than maybe other roles. Another role that we have is the developer advocates. We actually don't employ evangelists, but it's literally the same thing. So I don't care. And what they do is honestly, so what they do is they concentrate on two things based on what they do. There is partner advocates who go out and they talk to high profile partners. They have great one-to-one relationships with them and they make sure that those partners get the best support needed, that they also could have an outlet into the engineering teams. They can provide feedback, they can gather that feedback and make sure it's actionable.

So those people are doing partner advocacy and then there is developer advocates who go out on a stage and they give speeches and they are an outlet to many, many developers at the same time, which is what some people might know as scalable efficacy.

So at Google we have two of those and it turns out to actually work very well for us. So the other role that we have, and that is actually what I do, our programme managers. So we sit more in the back and work on the strategy of developer relations. We try to come up with which communities we actually want to work with. We don't necessarily do speaking all day, but we can. And you will see throughout the definitions of those roles, a lot of them intersect, a lot of them overlap and that is per purpose. You will see developer relations programme managers, which is a very long title that love going out and actually speaking on stage and you will see some advocates who actually do very few speaking gigs.

But what we do as programme managers is very much we try to work with people on a one to few to many base.

So we work with influencers, community managers, we work with lots of different stakeholders like conference organisers and try to make sure that they get the resources from Google that they need to be successful. And then finally we have the community managers who are really, really important as a piece for us because we want to make sure that communities again have an outlet within Google that they have somebody to talk to if they have any problems and that they know who to approach whenever they actually want to talk to all the other initiatives over here. So community managers should all across Europe, all across the country, all across the world actually. And they are a great outlet to really make sure that communities get to talk to them on a regular basis that they know that there is this friendly phase to approach and they are a huge, huge help for us as a team.

Now there is obviously this huge difference between our insight perspective of how we as derail people perceive our job and obviously how our company might perceive our job and how the external community might perceive that, right? Because obviously for other people we are still all kind of doing the same thing but not really. So let's quickly go into that.

So if we talk about the company and the intersection between the developer community, there should be an overlap by definition. So Google has that anyway because Google builds a lot of products that are developer facing. So we'll probably most of your companies still obviously because there is different interest and there is definitely different tasks at hand. We need to make sure that this overlap actually becomes productive. So how do we channel feedback from A to B? Of course you can have your product managers and your product owners go out to events and talk to people, and I highly actually encourage you to do that.

But still actually helping those people to find the right events, find the right outlets, it's something where we can actually provide value. So obviously developer relation teams sit kind of in the middle between the community, kind of representing the community within the company and representing the company within the developer community.

So that is kind of now setting a baseline for my assumptions throughout the talk. Actually for PayPal, when I used to work there, we had another audience in there and that made our lives sometimes a bit easier, sometimes a bit harder because we didn't just have the develop a community in there. We also had another community that we had to interact with. We so-called merchants. So it can get confusing for a lot of different groups because your company's idea of who to interact with and who not to interact with might actually be different because for PayPal or other companies, a merchant is the person that actually creates the revenue.

Various V developer who actually builds the experience is not necessarily the person causing the revenue directly. So it always makes sense to try to understand who builds the product and who creates revenue or whatever you're looking for to measure. So who owns that piece and how can you manage that?

And now if you think about developer relations and my previous graph, where would you put developer relations in here? That suddenly becomes a different task. So I said that the second bit of my talk is going to be managing expectations because obviously metrics are a huge thing. We need to provide benefits and value to our company and we also want to make sure that we actually are helping to grow whatever our company does. So it turns out there is this kind of interesting graph between time investment and immediacy in return. So if we think about classical sales, even code sales where somebody gives you a call or sends you an email or hits you up on Twitter, chances are high that you get very immediate feedback.

Somebody might say, oh yeah, sure, I'm game and you just made a sale. On the other hand, if we go into a realm of business development, you will see that that's a very much different thing because suddenly transactions take a long time.

Sealing off a big, big deal of that scale of what usually BD teams kind of care about can take months and sometimes even years still once they actually land that deal. Is that something that can have huge impact? So I find that business development and developer relations is very much alike when it comes to that because building trust, again, that is not something that happens within minutes. Of course, I can set the baseline for trust and I can set the baseline to work with you folks over here, but to really prove that I'm a credible person talking about Jess's point about the authenticity of a speaker or a deferral person that actually takes months and ages to establish.

So we need to be very careful in how we do that. So I mentioned that there is one to few to many relations and we need to manage them. So if you look into that, you will notice that it is actually very close to word of mouth marketing. So in word of mouth marketing, I make sure by having a great product or a very clear talking point, eventually people actually carry on my message to other people.

So of course we can try to scale and hire more people and talk to more people, but that is not necessarily always the best thing to do. So that's why our team very much concentrates on talking to the influencers, talking to the stakeholders, going to conference organisers, making sure they get what they need so that then eventually our message carries on to the community and from the community to even people that we don't necessarily interact with.

So the value bit is something that I care about a lot because obviously this is actually where we get to justify why we work for the company, why we get our budget and why we get to travel to amazing places. So truth is managing those expectations can be really hard and we all know because you might be under marketing, you might be under engineering, all of those different functions actually have different expectations. So we need to sit down with those different stakeholders and provide them with a menu of different options and actually involve them in choosing what they think is right for developer relations in your company to do. So. If your goal in a company is to drive revenue because maybe you're a startup, you just started developer relations and you want to make sure you broaden your target audience, then maybe structure your developer relations team around that.

But if you want to raise awareness, you might actually care more about building up early adopters that then can advocate for you as well.

And that pretty much leads to influencers. And it turns out all of us talk to a lot of them on a daily basis. So I understand talking to people as some sort of portfolio management to be honest, because what we do is we meet all these amazing people and you might have this situation that I have every now and then you go to a conference and you actually get a tonne of different business cards and it turns out that those business cards happen to be in the upper right stash over there. And then I go back from a conference and I go to my desk and I just throw all these business cards down there. I might actually not ever go back to them because I just got these cards I returned from a trip, I don't really act on them.

So how about all these contexts that we actually make throughout the lifecycle of being an evangelist, of going to events, of going to meetups, we use those contexts, start to kind of categorise them in whatever categories might be relevant for you and then act on them because there is a lot of really valuable knowledge in there that you can provide to your company. So if we use this, we make this actionable and not just worthless LinkedIn context. If somebody is from LinkedIn here, I'm sorry, we don't just want to grow a number of people in our following, we don't just want to grow our network by having a virtual number.

If we make context and they turn out to be interesting, get back to them every now and then. Talk to them every now and then. Make sure that they know what's up, what you're busy with, invite them for coffee.

It's our job. It's part of what we do. And to me this really leads also into being able to efficiently manage communities. So if we talk about communities, we need to understand what they care about. And often if people, it's their first kind of outreach programmes, it turns out they actually don't talk to those community stakeholders.

There's this ideal perspective of what community outreach should be and what the benefit behind it is. But we quite often actually frankly don't know what communities really need. Is it financial support? Is it content? Is it help in actually running events? Is it any kind of introductions to other speakers, right? There's many ways in which we as developer relations can be helpful, that helps us then build up that trust that we need in order to be efficient. So for Google, if we look at the community, there is a few different programmes that we kind of intersect with.

There is the Google developer groups in the lower right corner, which is actually nowadays active in more than a hundred countries with more than 600 organisers running, sorry, actually more than 600 chapters, more than 2000 organisers and more than 3000 events in the last six months. So quite active community. And those people are amazing because they literally, they are not all technical, lots of them are actually enthusiasts that just care about Google, but a lot of them actually go for it. They run events to educate people, to make sure to include more people into technology. They want to get together and build a network. Then we have amazing other groups like women tech makers who get together to drive inclusion in technology. Another group that we love to work with are the, so-called Google Developer Experts, which are influencers who usually work in companies, oftentimes lead developers or something like that.

They mostly have a huge following on social media.

They might be great public speakers, active and open source bloggers, you name it. There's different categories of that and all of them are completely valid. And then sometimes something that kind of falls down in lots of different deral programmes is working with freelancers and agencies because those don't necessarily always belong to a company. So we cannot necessarily track how effective working with them is or not. So for us, they are actually quite big target audience. And then around that is all these other communities which might not necessarily be Google owned communities, but still highly relevant to us.

So the last bit of my talk before I go on stage is actually starting to provide actual value by providing and facilitating feedback exchange. So what does that mean?

We actually have this portfolio of really valuable context, oftentimes people that work in startups that work in companies that we actually signed NDAs with. So why don't we actually do cool stuff with them like running early access programmes. So what we do is, and that's something that we did with, I'm not sure if you've heard about Firebase, it's a product that we relaunched this year at Google io. Google acquired Firebase a few years ago and then build it up to be this amazing suite of different functionalities for developers. So beginning of this January four or five months before Google io, there was an early access programme to get feedback in from agencies, from freelancers, from Google developer experts, from different companies to make sure that the product actually fits what people are looking for.

So oftentimes in companies, it's very cumbersome to set up those NDAs to make sure you get all the legal tidbits kind of sorted. But I promise it really, really changes the value that the product teams see in developer relations because suddenly you can actually sit people next to each other. You can make sure that they facilitate feedback exchange.

So highly recommend looking into this. We talk about boosting product adoption. So again, having early access programmes really helps with that because suddenly as soon as your product goes live or a new version of your SDK is being released, suddenly there is a few people that actually know how to use that already and hopefully they actually start talking about it. If your product is good enough that it attracts a following, hopefully the positive word, hopefully positive messages around it are going to spread anyway. And that very much leads to what you might know as the Gartner hype curve.

So developer relations very much sits in between all of these different phases. You want to make sure that people that are early adopters get the right kind of amount of attention so that they can start trying out the technology because before it goes mainstream at the top over there, the peak of inflated expectations, you will have all these articles in all different media outlets saying this is the new best thing to use and everybody's going to jump on it before they actually realise that a lot of it is actually not applicable. And then eventually it turns out there is a lot of really cool use cases.

I think one of the main technologies that literally just went through that is iot. So people thought IOT and smart Home is going to solve everything. Turns out it's actually oftentimes very cumbersome to set up, very cumbersome to manage, and then more and more companies emerge that actually kind of had a grasp on how to actually do this.

And before I go to the stage, what I really want to recommend is being part of the actual team. And there is a process for us to do that. We call it, first of all, getting the people that build things on the stage as well. Because of course we as developer relations, we as evangelists, as advocates, you name it, we love being on a stage or writing articles or publishing open source and we like to be that outlet for our company. But giving those people that actually bid things, that airtime that outlet as well, giving them that time to share their thoughts and getting that feedback face-to-face is incredibly valuable.

So make sure they come with you to events that they join you on stage, that they talk with you about their experiences and that really helps also make your life much, much easier. And then what we do as we final point is we introduced point of context.

So we and our team have selected a couple of people that work with those product teams on a regular basis. We join them on their regular calls. We are part of the roadmap. We make sure that Google developer groups and all these other programmes we have are part of their strategy. And even you might know that Google uses OKRs. So different key results that we try to measure, we actually try to become OKRs of those groups and they become OKRs of our team.

So we actually commit to doing something together and it really, really helps. So I highly recommend looking into a POC model where one or two of your team members, obviously if you're in a smaller team, it might be easier to just sit in with more product teams. If you have larger companies like Google or Facebook or Twitter and so on, try to implement one or two of your team members within those bigger product teams, making sure you're in the loop. You also can raise the word for V developer community. And with that, I would love to thank you for your attention and hope you have an amazing lunchtime.