Developer relations versus developer marketing

Michael Ludden: I'm Michael Luddon. I, am with IBM Watson. When I joined the company, was doing developer relations. I have a new role, which is not developer relations. That's new as of November 1.

Very happy about it, though. It's working on developer focused products. Can't talk too deeply about it until the beginning of next year, but I'm pumped. I've been wanting to shift more into pure product management anyway. But my background is in developer relations.

Oh yeah, that's my Twitter if you want to reach out to me. So this is my background. This is why I'm on stage talking about this, because I have a perspective having done both in my career. So there have been lots of stops along the way. I classify what I did at Google, Samsung, and at Nexmo as developer marketing, and what I did at Watson until November at HTC as part of the developer evangelism team, and Quicksy as developer relations.

So what do I mean by that? Well first, a few caveats. I kind of touched on them already. I'm going to talk real world versus ideal world, like in my ideal world how this would break down versus how it really is. So take it with a grain of salt.

It may be impractical in your organization to try to take a hard line and enact some of these ideal world changes. Big company problems versus startup problems, they're very, very different. As you can imagine, I deal with big company problems at the moment. But I have dealt with startup problems. And I know many people because I live in San Francisco, the land of startups that deal with startup problems on a daily basis.

Semantics do matter. We're going to talk a lot about semantics, semantics being phrasing and what you call yourself and what that means. It may seem like something that a pixel pusher designer would do, but actually really matters. And I'll tell you why. And then yeah, I'm opinionated.

Feel free to disagree with me. Feel free to disagree with me during the Q and A session and the talk. I love being challenged and I would love if I'm off base on this for somebody to give me their perspective. But I really do feel like I'm probably going to be preaching to the choir. Last night when we were having some pints, I was chatting with people and they were talking about exactly what I'm going to bring up today.

So I think I'll try to vary my portion on developer relations from Mr. Twitter. All right. So what I'm sorry. I didn't catch your name, but we'll catch you later.

Mr. Star Wars fan Twitter guy? Okay. What is developer marketing? So it's marketing to developers.

I mean, in my opinion, that's what it is. When you talk about developer marketing yeah, a little clapping there. When you talk about developer marketing, you're talking about marketing to developers in the same way B2B marketing would be marketing to businesses, not to consumers. That's how I feel about it. And I'm trying to proselytize that.

It's very simple on that front, so I'm not going spend too much time. But basically, typical marketing roles will do things like this. They will do demand generation. Anybody ever seen this before? Demand generation funnel of joy, I like to call it.

So you got lead generation. It's a lot of digital marketing campaigns, email campaigns, content calendars, viewing in the PR zone. The thing is your audience is just developers. So the output is going be a little different. The thing that I really hate, and you guys can probably agree with me, is when people treat developers like they're like an alien species.

Like, oh no no, you can't market to developers. They don't they don't stand for that. Well, it's like the the concept of marketing is is salient for all of the of humanity. Right? You basically just are ultimately, hopefully, making a compelling case for what you want them to do in a way that makes them interested in doing it.

And developers are no different. If there's something that's going to solve a problem, great. So maybe it's not as much ads. Maybe it's more community management. Maybe you run some banner ads or a promoted keyword on Stack Overflow.

The output might be different, but the marketing techniques are the same. And I've done that. I've done developer marketing. When I was at Google, I did developer marketing for Google Play. It was the most pure marketing I've ever done in my life.

So that's my opinion on developer marketing. I'm going spend a lot more time on this. But what is developer relations? So I agree with a lot of what was said today. Basically it's a new hybrid role that is a bit unicornish, hard to find.

There's a hybrid skill set. I mean it requires a lot, right? And I think that it's underappreciated how difficult it is to be a good developer advocate or a good developer evangelist or whatever your company might call it. But basically it's a software engineer who is great at public speaking and who in an ideal world again we're talking ideal world some people have stronger skill sets in one part than on the other. And I would also posit that when you have a developer relations organization, a dedicated one, you can have individual advocates that specialize in different things, certainly regions, etcetera.

But perfect developer, most complete developer advocate would be able to be great at public speaking, generate incredible sample code, flawless that just makes jaws drop, great with online communities, great reputation, know, do the whole kit and caboodle. And that is nontrivial, really nontrivial. So it's both of these things. I've heard developer evangelist, developer advocate. Personally, I know that ship has sailed, and I get why the religious overtones because when you're evangelizing a product or a programming language, it does get religious, as we all know, from time to time.

I don't really like the word evangelism, I'm going to accept it because that ship has sailed. So the way I like to break it down is developer relations is evangelism and advocacy. So this is Mother Teresa solving a problem for somebody. Is a hungry person, and she's feeding him. This and I'm going to talk in a moment.

And this is an extreme form of preaching the good word, proselytizing. So there is outreach and there is advocacy. So if I were to break down what I would consider evangelism and really, some of these you could put on either side. It doesn't really matter. Just take it for what it's worth or if it's helpful for you.

But evangelism would be public speaking, social media, outreach, conferences, office hours, content, blog writing, how to guides, online sample code demos, hackathons, etcetera, etcetera. The spreading the good news part. The advocacy part to me, and this is the part that I think a lot of developer relations teams, organizations, and individual advocates don't always get right. It's not necessarily always their fault. It's very hard to put this mechanism in place.

But the feedback internally from the community that will actually affect roadmap and improve the product ultimately is so important for long term success, and it's very underrepresented, I think. I don't want call out specific companies, but there are companies in which it was all one and not the other. And you know, it's hard. It's hard to go out there and talk about something that ultimately you're not going to be able to believe in because you know that whatever feedback people are going to give you is just going happen again and again. All you can do is be like, mhmm, I got you.

I hear you. There's nothing I can do. I'm sorry. Just buy it. So the advocacy portion would include product specific feedback, documentation feedback, feature requests, developer quotes, tooling feedback, market research.

That means understanding who we should be going after, helping marketing out with that. And I'll go more in a minute on the overlap because there's a lot of overlap with marketing, with developer relations. Roadmap advice, web feedback, a lot of this really depends on personnel. One of the things that I've learned as I've been learning about product management is you've to lean by influence because a lot of your stakeholders do not report to you, and you have to figure out ways to motivate them. Well, it's the same thing with advocacy.

So you have to find product managers, you have to find the engineers that will listen to you, that want to hear what you have to say, that are interested in the market feedback, and you also have to present it in a way that will help their job. So whatever their metrics are, whatever is going to move the dial with their boss and make them look good, figure out an angle. You'll find yourself a rock star within the company, and hopefully affecting positive change and improvements to the product roadmap and all that. User feedback, yes. But Michael, isn't there overlap?

Sorry, that wasn't as funny as I thought it would be. Yeah, there is. So there are overlapping metrics metrics between marketing and developer relations. So there's developer satisfaction. So let me also say this.

In my mind, I am treating this as if this is a developer facing product that there's advocacy for and marketing for. So in that sense, developer satisfaction like Net Promoter Score, which we're probably all familiar with, these are things that can be shared metrics between the two. Product improvements should I guess that's not an overlapping metric. I'll take that out later. But user retention, market growth, revenue adoption, etcetera, all of these metrics.

A lot of people just focus on the revenue and adoption and storing the betaB out with the bathwater. Because if you get a million sign ups for your product and everybody hates it, you're never going to get another million sign ups, right? Unless you just throw money at it and you're ultimately going to fail. So I think choosing when to use those bullets and when to drive adoption when you feel like, all right, now we're ready. We have everything around it and the product's good and it's compelling.

Then we push adoption. And then we look after revenue. But in a lot of ways, at least developer relations is playing the long game. And at some point, though, you do have to tie your efforts to things that higher ups who may not be technical can understand, especially at a big company. You have to be able to walk the walk while you're doing the things that you know will lead to long term success.

So that's not easy to do. In one of my developer marketing roles, we had communication issues with groups. And one of the ways that I was able to overcome that was I was able to actually get them their numbers. So Okay, we need to have this many downloads. Okay, got that.

Check. That's one thing. That's not what we're really working on, but we can do that. And that will make us get the buy in for what we really need to do. It's not easy.

Hopefully, organization has better communication. That's always optimal. But if not, just think of that. Overlapping job functions, of course. Online community building, public speaking, outreach.

So ideally, you need to work with marketing. Developer relations groups need to work with marketing. A lot of developer relations groups work for marketing. I'll get to that in a second, org structure stuff. But you need to work with them on a campaign you both agree upon.

And to a certain extent, you're going to function as the boots on the ground executing that outreach strategy, whether that's public speaking, whether that's online community building, etcetera. But you need to be in the room with marketing and insinuate yourselves into those conversations, or else inevitably you're going to be tasked with doing things that are dumb. So communication is good. All right, overlapping org structures. Let's see here.

I have seen it all. I've had developer relations groups that report up to marketing. I've had dedicated developer relations groups that I've been a part of that I've not been a part of. I've had developer relations group that I was a part of report up through Enterprise, oddly. And here's what I think.

In an ideal world and again, this is assuming a lot of things. And it may be different from big company to small company. This is how see it in the real world most of the time. So you got the CTO orphaned over here if it's a smaller company. And CMO has marketing and under marketing is, in quotes, developer relations.

I say in quotes because many, many times, many of you can probably attest to this, it's just about pushing sign ups. It's just about what's the largest audience, not about the right type of developers or even whatever. There's no context. It's about pushing sign ups and downloads and this and sales and that. And it's, again, throwing the baby out with the bathwater.

In an ideal world, developer relations would report up through the CTO or whatever the structure is to the CEO, and marketing would report up through the CMO. Two would collaborate very strongly, but also be independent. So if developer relations felt like something was really just not something that they should do, then they won't do it. And nobody's going get fired because ideally you have the buy in of the CTO, conduct the CEO, etc. And that sort of forces more collaboration rather than sort of top down edicts when it reports up to marketing.

Now that said, I know that generally marketing is going to own developer relations because people don't yet understand what this new hybrid unicorn ish role is and what its purpose is, which is really to build trust with developers' communities, which leads to long term success and long term revenue goals being met, etcetera, etcetera. We all know the value of that. I don't think I have to restate what a lot of people have said probably better than But a lot of people don't know that, and so it will report up to marketing. And if that's the case, would just say, yeah, get in the room during the strategic planning. A lot of people just want to build sample code and go do events and stuff, but it's important for the company's success and for your personal success.

It can really help out your career and your growth if you are assertive enough to say that it's important that you're in the room because you have a valid perspective. A lot of times marketing just wants to do this and that. Not all the time. But yeah, get in the room. And I would say also that big company problems differ from startup problems.

The importance of org structure changes. In certain companies that I have or maybe still are a part of, there are a great many orgs. And so to a certain extent you have to ignore the noise and don't worry about who reports to who and where and what. I like to ask forgiveness rather than permission, especially at larger companies. Don't tell Ivy on this.

But you will get caught up in red tape very quickly. The truth is when you've only been there a year or two years or you've never gone through a process, you have a built in excuse. Like, hey, I just thought this was the right thing to do, so I did it. Here are the results. You can slap my hand if you want.

Next time I'll do it this way. But usually, if you already have successful results it was a successful engagement. It was a good hackathon. It was a blog that everybody loved that you weren't supposed to publish because PR was going to be angry at you. But already you've gotten a ton of positive feedback in the market.

Your hand can't be slapped. But you promise to follow the guidelines the next time. And generally the guidelines will change is what I've found, which is great. And it's kind of egoless. That's the real thing, right?

You can't rub up on people's egos. All right, so just sort of scatterbrain key takeaways and then I'll do Q and A and finish up. Naming matters. So let's all agree on these definitions, please. Developer marketing is marketing.

Developer relations is developer relations. And you can have advocates or evangelists or whatever you want to call. You can have popes. You can have you know, Jesuit priests, whatever you want to call your developer. I don't care about the religious terminology.

Just, just agree that that's different than developer marketing is really the key thing for me. But I do like using the evangelism and advocacy piece. They need to be in balance. They need to be fiftyfifty. You can't have more than one of the other.

You can, and people do, but that's that's the optimal solution in my opinion. Job role specificity matters if you want to keep your job and also for company success, meaning people need to know what you do, not just you, but other people within the company. And you need to have a clear perspective about this is the value that I bring to the company. This is what I'm doing. Otherwise, people are going to misunderstand what you are as a developer advocate, which is my preferred term, the way, developer advocate.

But I digress. Developer relations done right matters, yes. Developer relations done wrong can kill developer marketing efforts. Indeed, that's another important piece because when you talk about motivating people and leading by influence, well, what's going to influence the marketers? Oh, these metrics are going to get us killed.

If we just focus on sign ups for a shitty product, pardon my French, then we're all going to be fired in here. That's a very powerful statement to make. And people will listen. You don't have to make it that extremely, that kind of thing. As we know, as everybody's talked about, great developer advocacy builds trust by solving real problems for developers.

It's not a hey, a big banner sign or something. It's like, hey, here's a problem you didn't know you had, and we're going to solve it, and it can do this and that, and get to the value proposition. And building trust, of course, it has to happen over time. And so collaboration between marketing and relations is unavoidable and can be mutually beneficial, as I mentioned. For example, marketing usually has more budget.

Marketing can execute big global strategies. And with the influence of developer relations, that's a good marriage. And don't leave these things unsaid in your companies. It's important that people understand the value, especially if you don't have a Twilio type of situation where everybody's like, yeah, absolutely. We're all on board top down.

That's just not the real world that most of us live in, unfortunately. Hopefully in the future. But have the conversations if they need to be said, if they have not been said. And those are my opinionated thoughts on that. Fight.

No. Do I have time for Q and A or am I done? Think no. All right. Well, I'll be around when it's really a show.

Thank you.