Developer relations, and developer experience, are built around the idea that software developers have meaningful influence over the technology choices made by the companies they work for.

But is that really true?

In his talk at DevXcon 2017, Donnie Berkholz looks at evidence from his years as an industry analyst to find an answer to how much influence developers really have.

Transcript

So do developers really matter? Which developers matter? You know, one of those exercises a lot of times as we like to go through is trying to do developer segmentation, which it turns out it’s possible to segment down so far that you’re not even talking to anybody anymore. And so we’re gonna talk a little bit about that and walk through a series of examples. And I’ve got about 25 slides in 25 minutes. So what you’re gonna see here is I’m gonna be on this slide for 10 minutes. And then we’re not gonna have any time left to talk about any of the other things.

Yeah, so, between accepting this talk or proposing this talk and having it accepted, and showing up here I sent a surprise email that said, “Hey folks, I got a new job.” And so, now the first person you’re hearing up here is from a travel agency, instead of from a research firm. Because I got a little bit sick of talking at such a high level and not being able to put it into practice, and so now I’m working with about 3,000 internal developers and apps folks, trying to build our internal API’s, our internal experiences. So I’ve done a lot of things over the years, I don’t hopefully need to justify myself too much. But it’s been a long journey working in open source communities, working in different developer communities doing research, organizing a lot of local events. And that’s what’s turned into this talk, really is those experiences over the past 15 years and thinking, you know, how has developer experience changed over time. Because it was a different era back in the days when SourceForge was the way to go. I mean, some of the communities have gotten left behind.

And so one of the big things I’m doing now is thinking about, you know, how is this evolving over time, and how can we keep up with that evolution, right? Two of the sort of mega trends have been happening, really impacting my view of developers over the past say five to seven years, have been DevOps and data science. All right? Because who is a developer, right? Our assumptions are developers sitting there, building apps. But you could say, “Well, a developer’s anybody who writes code.” And suddenly, you’ve got people doing info coding, right? And you’ve got people who are writing in R all day long, and now we’re thinking about what’s the developer experience mean for them in contrast to, you know, what it means for a Salesforce developer, or what it means for somebody who, you know, considers themselves a developer, but is mostly doing drag-and-drop, low-code development. Right? And the experience is dramatically different for every one of those. I mean, certainly, in big companies like Salesforce, for example, it’s really challenging to try and target all those different communities at the same time.

So I promised you a little bit of data. One of the things that we did at 451 where I was previously employed is we would go and survey, you know, 15,000-2,000 sort of IT decision-makers on a regular basis, asking them all kinds of stuff. Here’s one example of a study that happens to be sponsored by Microsoft, so, thank you Microsoft.

Asking about cloud and hosting decisions, whose the influencers for the decision-makers? One thing that’s really interesting about this is, so the roles are across the bottom. You might not be able to read them all, don’t worry about that. In blue you’ve got influencers and red you’ve got primary decision-makers, and in green, you’ve got were irrelevant to this choice, walking through roles like CEOs, or developers, or infrastructure managers. In the black box there, what you can see is in essence practitioners, right? Technical practitioners, whether they’re in ops, whether they’re writing code, whatever it happens to be. And you can see that if you add together influencers and decision makers, the red and the blue, they are the biggest out of everybody, with one exception of the CIO who’s making those million-dollar buying decisions. And so this really takes home the point that, you know, developers, from the perspective of the enterprises, are incredibly important in making influencing decisions. We’ve got all kinds of sporadic anecdotes here and there to support that, right?

So one example was, especially in the open source world, I ran into somebody who said, “You know, we lost a million dollar deal because a developer at the company we were trying to sell to was a contributor to a competing open-source project.” And there’s a lot of examples of that kind of thing, so you can find them if you go looking. But I just wanna, you know, really make it clear, like, we got quantitative data now that we can say, “Support that assumption that developers matter. Support the assumption that they are involved in influencing making decisions.” Go back to, you know, your management who says, “Well, you know, if you live in marketing, if you live in product, do we really need this thing?” Yes, you do, because otherwise, you have no influence on those people who are going out there and influencing their internal buying decisions.

And so, there’s a lot of questions like, how do we reach them? What do we do? What are the best ways to go out there? Here’s one survey we did, it’s actually three years old now, asking what are the main ways that developers get information. And I would say, you know, it’s less than ideal from the perspective of an analyst from doing the surveys, because analyst firm reviews were not on the top of the list. But I’m also happy about that because that means we’re not too biased. And so, you know, the top things are pretty much what you might expect, right? It’s inorganic and it’s organic, right? Getting content out there, right? Writing technical articles, technical blog post, all the usual stuff, and then getting out there in their communities. And I think one point that, hopefully, most of you are already thinking about at this point, maybe a few of you aren’t, is guess what? The easiest ways to reach developers it’s to go where they are. Building your own community is really hard and you have to invest a lot of effort over a long term. You have to have a siloed community. There are examples of where it has worked, but if you wanna make your life harder on yourself, right? Like, stand up all your own community infrastructure from scratch instead of going somewhere like Stack Overflow.

And so now I’m gonna talk through a series of examples pointing at different examples of developer journeys, developer experiences. Right? To try and, you know, reiterate that it is much broader than just community management, it’s much broader than developer relations. It’s about thinking through what their journey looks like all the way through. And if you feel like you’ve got a good grasp on that today, one point that I would suggest that you think about is, can you go three steps in either direction from the way you currently think about it? Right? What happens before this? What happens before this, right? Because a lot of times people consider the journey as, let’s say in the broader sense, maybe, “When they show up on my website, that’s when the journey starts. Because that’s when I can quantify it’s starting.” Well, what if you step back? Like why did they show up on your website? How did they get? Okay, so you can do some referral tracking, that’s fine. But it gets harder the farther back you go. At the same time, it gets more important because that’s the top of the funnel, and if you’re missing that top of that funnel, you’ve already lost a huge percentage of your potential developers.

And so the first few examples I’m gonna talk about are from bigger companies, and if you’re from a start-up, these hopefully, will be relevant to you someday. If you’re from a big company, these are probably more directly relevant. And then I’m gonna talk about some ones from smaller companies as well so that nobody feels left out. So Salesforce is to me an interesting example because it is one of those bifurcated communities. You’ve got all of these people who are writing Apex. If you haven’t heard of Apex, it’s this custom weird language that, turns out people like it, some people. Many other people out there are just paid to deal with it, and they have to deal with it. And so they’re trying to understand, “Look, I’m working in this language. I may not like it. It pays the bills. What can you give me? What can you do for me?” And so it’s interesting because Salesforce, they’ve actually got a developer conference coming up in a month here. Because what they found out was they’ve got Dreamforce, right? Like 90,000 people show up and take over Mosconian tower and everything in the middle. And yet, developers were still siloed off, and they still felt a little bit neglected. And so they decided, “Look, we’ve got Moscone West, we devoted that to the developers. All the people who actually sell stuff too we’ll put them in, you know, north and south, but we can’t cater to both of them at once. So we’re gonna split things out, right? We’re gonna make sure that we can give everybody the emphasis they deserve, instead of dividing our efforts and not being able to do great at either of them.” So they’ve got Trailhead, right, Trailhead DX. And Trailhead itself is essentially developer relations as a marketing exercise, right? So you’re doing the marketing, but then you’re also marketing that you’re doing the marketing, which I found very interesting.

And I’m not gonna get super deep on this, but you think, okay, so we’ve got the Apex people over here, we’ve got the JavaScript people up here. All right, they’re writing a bunch of web apps on top of Salesforce, and we’ve got the Heroku folks over here. So it’s all these silos and they’ve been trying to figure out, “How do we connect them?” over a long time. And they’re making a lot of progress there. Right? One example of what they did was they said, “Look, we’re gonna prototype the modern development tool over here on Heroku land.” Right? They’ve got all their CI CD pipelines, they’ve got all kinds of stuff. “And then we’re gonna pull that back into Salesforce itself. Right? And give that modern development experience to Apex developers who may not even know what a modern development experience looks like.”

Right, so there’s a lot of education effort to say, “Hey, this continuous delivery thing, that probably makes you pretty nervous, but we’ve got your back.” I mean it’s always challenging for some of these communities to say to them, how do they catch up, how do they keep up with, you know, the modern trends. Because frankly, I live in Minnesota, I work with a lot of people in Minnesota whose day jobs are developers. They don’t want to write code at night. And there’s a lot of developers in that kind of position, so how do you reach that kind of person who just says, “Look, I read code eight to five, nine to five, ten to six, whatever.” Then I go home and I play basketball, right? Or I go swimming or whatever it is. I mean, it’s a very different journey involved with that kind of audience, very different motivations, very different rationale for, you know, sort of these Apex developers than it is for the people who, you know, many of you are and who many of us interact with every day, in the Bay Area or in sort of what I call the Bay Area bubble, wherever it happens to be. Right? Where people are, you know… Passion is defined as we spend all of our waking hours thinking about software and spending a lot of time reaching out to the community, spending a lot of time independently learning. It’s a very different journey.

So one other example is Red Hat. All right, again, bifurcated community. You’ve got all these people who are super passionate open source Linux developers on one hand, and the other hand, you’ve got Red Hat who’s trying to say, “We’re not just about contributing to the Linux distribution itself, but we’re also trying to get people to build applications on top of it.” How do we cater to that kind of community? Very different worlds. Because you’ve got, so rel customers, right? They say, “Look, we just need a corporate support of Linux distro, we don’t care about the rest.” How do you build apps on top of that? How do you better monetize that in sort of a development environment? And they basically, more or less got no traction until they jumped on the container bandwagon. All right? And if you said like, “What is one thing you could possibly do from a tech standpoint that will get you to developers?” It’s containers. I mean that it’s almost irrelevant what you happen to be doing with them, you say, “All right, we’re good docker, we’re set.”

And that’s exactly what they did and it worked. Right? Because first, they had Openshift, which was initially a sort of weird PaaS. And then they said, “Well, you know, we can’t get traction for weird PaaS, it’s too much work, too much investment, right? We gotta go where the developers are, right? So we’re gonna rebuild on top of communities instead.” And suddenly, they got tons more interest, they’re getting tons of sign ups. I don’t remember the numbers exactly, but we’re talking, let’s say thousands on a monthly basis instead of two to three digits on a monthly basis because they decided, “We’re gonna go where the developers are.” Not directly what we would call developer relations because it’s about changing the product and how do you produce a better developer journey by changing the product itself.

Another example, another bifurcated community, SAP. How many of you are familiar with SAP? Could you name a product that they make? Like… ERP, right? And you’re like, “Oh, okay, I don’t really know what that is still. I file my expenses through it or something.” So SAP’s are really interesting example. You should definitely go check it out because they are one of the ones that has succeeded in building a solid community. And they succeeded because the software itself requires so much customization that this huge consulting ecosystem grew up around it. And so they’ve got all these people, again, writing a weird custom language, ABAP in this case. All these people who are making boatloads of money doing ABAP customization work. And so they’ve got this thing called the SAP community network. One thing they do really, really well is they do a great job at promoting some of their most active developers, all right, tuning developers into their best advocates. Which, you know, you ask “How do you scale developer engagement program?” Well, it’s not by hiring everybody. It’s by hiring enough and focusing on enablement of more advocates in contrast to saying, “We’re gonna just build out a hundred people internally.”

And they’ve done a great job of that. They have this thing called The Mentor Program where they say, “Some of our most active community members I’m gonna promote them.” Like you show up at our conference and they’re like they’re sitting there on posters, they’ve got all kinds of stories and testimonials from them. And it works out great because it’s a consulting ecosystem. And so every time one of these people gets promoted, it makes them money. That one’s very, very tangible. And they’ve got a similar thing where they take a subset of the mentors and they have a blogger program. All right? And they treat them like these huge influencers, right? They get invites and free travel to conferences. Or they’ll bring them into exclusive events, give them an executive access. All kinds of things that you might not think about as normal aspects of a developer engagement program. But they work out fantastically well for SAP to say, “Hey, we’re not just this old-school company. We’ve got all these people doing really cool modern stuff.” All right? And so it’s one way that they both build a developer community, but also turn their developer community into marketing. All right, to say, “We’ve got people doing stuff with HANA, right, which is our cool database that now everything in the company is called HANA.” Different marketing exercise and problems there. But it gives them a way to communicate that they are modernizing their customers and that their customers can do modern things.

And so a smaller company, Basho. All right, how many of you familiar with Basho? About half, about a third. So distributing databases is their focus area. And there’s a couple of things I really like about the way Basho approaches developer engagement, or historically approach developer engagement I should say because there’ve been many evolutions over time. They did a great job of turning developer engagement again into sales because one of the things they did is they would go into customers or prospects and do internal tech talks, right? Just go in and do a brown-bag launch. And that’s one great way to reach those nine to five types because they’re not going out there, they’re not learning, they’re engaging. How do you get to them? Well, again, you go where the developers are. And if they’re not active out there, you have to go inside. And so they did a really nice job of doing that internal tech talk model. You can very clearly relate it to something tangible, which is “We went and talked, that company X. Company X signed up as a customer.” It’s harder to say, “Well, let’s do the control and not talk, and see if we lose the deal.” But you can at least go from at least an anlogue point and say, “The deal has been kind of going slow, we sent people over, we got them engaged, we got them excited. They started, you know, providing internal influence and suddenly we’ve managed to close the deal.”

And another thing that they did really nicely is their guide of this conference called Recon, which is instead of saying, “We’re gonna have the typical company conference, right, we’re Basho, we’re gonna bash your con.” They said, “No we’re gonna build a community around distributed systems as a whole. Let our competitors come in and talk because that’ll create somewhat something that developers want to come to you and give us an opportunity to be involved and get visibility to groups that might not otherwise pay attention to us.” Which works really well if you’re not the leader in a space. How can you build that community? I mean, it’s a classic, you know, competitive strategy is number one is out there, so number two, three, four, five, six they all build a coalition, right? They create a standard, something like that to try and compete effectively with the dominant player, which in this case, yeah, you could already use Oracle or Amazon services, or something along those lines.

One more small example is HashiCorp. Yeah, Vagrant, Terraform, whatever. So HashiCorp is a really interesting company because almost everything they’ve done was conceived in a dorm room like 10 years ago. And they just said, “We’re just gonna go on and build it. We don’t care what else is happening out there, we’re just gonna keep building our ideas and go on and on.” And the cool thing about it is it’s more or less worked out for them. All right? So you know, much to everybody’s surprise, almost… well, I don’t wanna say almost everything there, but a lot of the things they have tried actually worked very effectively. And going sort of off the back of Vagrants and off the back Terraform, you know, one thing that they do a really nice job of is this idea that there’s a blog post by a guy who is a founder of a company called MindTouch, all right? The new documentation. The blog post, obviously, a little bit self-serving was that documentation is a storefront for developers. They consider docs a key part of the developer experience. I’m really excited to hear more talks about docs later today for exactly that reason.

And so HashiCorp has documentation as marketing, right? But not in the bad sense of like, “We’re gonna turn it into a bunch of fluff so that it’s completely useless.” But instead, they are one of very few examples of vendors whose documentation explicitly has competitive comparisons in it. Because developers are sitting there thinking, “All right, how does Vault compare to Keywhiz or whatever other products that are out there? Who’s gonna nail it down for me?” Well, if you’re the vendor and you do it yourself, then you have an opportunity to more clearly position yourself in a good way. Right? Versus if they’re going out there and finding some blog post that somebody wrote, you know, three months ago, who knows what light you’re painting? All right? And so it’s an opportunity for you to get out there and say, “Here’s what I want people thinking about.” One way we would think about this in the analyst world is, you know, you’re setting the buying criteria, right? And so if you get them thinking about things in a certain mindset of saying, these are the three things that are really important, well, coincidentally there are three things that we’re really good at. Whereas, if you let somebody else define that, they’re gonna come up with their own decision points. And so HashiCorp is a really nice job from that documentation perspective.

So IBM, a small little company. Again, one of those companies where, I mean, they’re great here, all right. I really like what they’re doing in Galvanize, but if you go and talk to a random developer on the street, they might not be able to tell you what IBM actually sells. And so, you know, it’s tough with those companies that they kind of do everything and had been around forever. So talking about context, how many of you have seen developerWorks? Not many, right? At some maybe 20%. DeveloperWorks, 15 years ago was the place to go for any kind of technical write-ups or anything, it was the source of like the greatest stuff. Right? You could go in there if you wanted to learn just anything, soup to nuts, right? Basho, sed, awk, take your pick. Right? And getting into the UNIX world or Linux world, fantastic source. Then it fell on the floor. And so, it’s sort of a symbol of like big companies don’t necessarily commit to things over the long term. Right? And developer relations is one of those things you do have to commit to because now if you say, “Hey developerWorks.” Well, 80% of you haven’t even heard of it, right? It was the place to go. And it’s terrifying to think that you can have something like that is dominant in developer mindshare, right? And just let it fall on the floor and go away. I mean, so if you got something that’s doing great, hopefully, you’ve got a little bit of data to support what you’re doing now.

I’m not actually gonna talk about any more examples because I’ve got my five-minute warning here, so I’m gonna try and get through some stuff.

Okay, so now as I promised you, you will get about 15 seconds per slide and you’ll have no idea what’s going on. Okay, what I wanna talk a little bit about is developer segmentation, all right? And I’m not gonna go through all of these in detail. But the challenge is everything today is so fragmented that if you try and segment things down, you’ll eventually get to a point at which you’re talking to nobody, right? And it doesn’t, like even if you pick, let’s say middle-aged white guys, right? You’re gonna end up with none of them. And if you’re saying, “Well, how about we care about inclusion, we care about diversity.” Well, if you segment down to this stuff, you’re gonna have none of that left, right? You have to think much more broadly about trying to target a broader population of developers. One way I like to think about this is, you know, we talk a lot about user stories of different products. Something worth looking at is this idea of job stories instead jobs to be done. Really it’s a mindset shift and thinking, “Look, we don’t care who you are, we don’t care where you came from. What we care about is what you’re trying to do.” Right? So not like, “As an ISV developer, I want to write Apex code so that I can instead of…” As an ISV developer added zero value to that, all right? What I wanna do is get a job done, right? I wanna write an app. I don’t care what background that came from to do it. I just need to write an app.

And so it doesn’t matter, you know, if I wanna write Python, it doesn’t matter whether I came from an ISV, it doesn’t matter whether I work at a big company or a small company. None of that stuff matters, all right? You think about the job to be done and you’ve got to target people off of that, all right? Because if you go anywhere else, you’re gonna end up out of options, out of people pretty quickly, right? You know, we think a lot about trying to do 80/20 rules, but in almost every one of these cases, there is no 80, right? Windows developers, all right? We’ve got half of them, Linux we’ve got 20%. Break down Linux, we’ve got 12% on Ubuntu. All right, so let’s go for Ubuntu developers, we got 12%. That wasn’t super helpful. All right? IDEs, we can’t pick one. Automation tools, we can’t pick one, right? Of course, Docker has answered all problems. But if you say, “Salt, chef.” There’s no obvious winner, you can’t just say, “We’re gonna dedicate effort here.” Yeah, Dockers is clearly a way to the future. If you’re in data science, you might say Spark is the way to the future. Well, oops, but Coughlin’s out of the way the future. Spark was the way the future two years ago, times change.

Now, so this is just more allusion to that idea of jobs to be done, right? If you take out one thing out of this, think about task-driven instead of segmentation driven outreach and you’ll be much better. Right? Because architects are going away, for example, right? All these developer types or technical types are going away, developers are doing all of it, you gotta think about the tasks in action here, all right? Again, which container orchestration framework will you pick? All right, all of them? None of them? You’re just guessing here. So what I want you to take home out of this is complexity is the new normal. Right? We have to work in that world that’s entirely fragmented about every technology, and we have to think about the jobs people are trying to get done, instead of trying to pick techs and tools and build our SDKs from that kind of approach. And so what I wanna leave you with is we’re in a very complicated world now, and all we’ve gotta do is the best we can. Thank you.