Developer secrets your customers want to tell you ... if only you’ll listen

For the time that I've been here, one of the things that has struck me is, at least for me, for my company, we are different in how we go about developer relations and the developer experience. Part of that is it's a big boring company, part of that is just our developers are different. And so, this is... One way that I express this is I love to backcountry ski. I usually ski every single morning. I live in Utah. I ski every single morning from 4:30 AM to 6:30 AM with big headlights. This, of course, was taken later in the day and we go straight up the mountain. And I've kind of felt that this is how I felt like listening to some of the things that were said today is that sometimes I feel like we may be going about things the wrong way or at least a different, harder way.

Do we recruit internally or externally?

I know that there are people here from Twilio. I heard an excellent talk by someone at GitHub, and those problems and the issues that they were talking about are not my problems. Even if I weren't married, Beyonce would not want to date me, but other problems. I looked at all of the headlines and stuff about why we need more developer advocates and James at RedMonk talks about like rightly lauding Microsoft for hiring all these amazing developer advocates. Google doing the same. People in this room, everyone's hiring. And I wonder if we are always talking about the kinds of people that we need. For example, so, I tweeted this out and Chris at Linux Foundation or the Cloud Native Computing Foundation, you can see his comment there. I said, "Do we really need developer advocates in the way that we're talking about?" Genuinely had this question. His, as well. Or, "Could we find those people internal at our own companies?" And this sort of came out of this Gartner quote from Svetlana Sicular, who said, "For your data scientists, you can go out and find somebody who knows Hadoop. It's much harder to find somebody who understands your business."

And so, are there people at your organizations that actually know your community and the product that you sell better than somebody that you might hire from the outside? So, I posed this question. He said, "Well, you know, it's hard to find somebody with public speaking expertise," and somebody else, Deepak over at AWS said, "We have all these amazing champions," and he piled on for somebody else at AWS, "I don't wanna help just one company at a time." These may be the exact issues that everybody in this room has. What we found is that these were not the issues. At least these were not the kind of developer advocates that we needed, because the kind of developers that we had were boring system integrators that employed 50 to 50,000 people. And they were just trying to solve, "How do I get this website working for Nike?" "How do I get this commerce engine working for Nordstrom?" Not the super cool things that I've heard at this event, certainly not as cool as GitHub. I thought that was an amazing acquisition. Frankly, we talked internally like. "No, this is not serious. This is not like stock-moving sort of news." But, some friends and I really wanted to buy GitHub at Adobe. But that would've, given some of the response from Microsoft, on the Microsoft thing, I think it'd be much worse if we would've done that.

The different needs of developers

But these are the sorts of things that are valued often in a developer advocate, but it's not what we needed. In part because, again, the kind of developers that we are trying to reach are different. And so, they're roughly 13-ish million developers out there, and not all of them are the same. And the question is, are you looking for that developer? She's working in her garage on the next greatest app? That's not who we were looking for. We're looking for that person works at Deloitte, who works at Accenture, and we're trying to enable her to be really productive with our technology, so different audience. The other thing is the question is, how much you're willing to pay? So, this data comes from SlashData is what they're called now. But we had a gathering of devrel people a year or so ago and they asked these questions, "How much do you spend? And how many people do you have in your organizations?" And you gonna look at this. Actually, I can't...I don't know if you can see the numbers of people, but 10 to 50 people in your developer relations organization. What did I hear from GitHub? What did you say? Something like you have three developer advocates? Yeah, maybe it was an education.

Anyway, it was a number that I was surprised given what an amazing developer brand GitHub is. I don't know, I thought it'd be 100 to 250 or something. I didn't know, and the numbers that you're able to employ, I don't know, were probably skewing down here, but the numbers at Google and Amazon that they're hiring, I think this was kind of a made-up number, but I think that was Google. But spending a lot of money and you may not have that money to spend and you may not need to spend that money, depending on what you're trying to accomplish. When we checked and we went out and asked our developers, we thought what they wanted was more APIs for more services that we would expose to them. That's not really what they wanted. What they wanted was a time to "Hello, World" that wasn't measured in hours or weeks. They wanted it to be in minutes. And for everyone in this room, it's probably like, "Of course." But if you work at a larger company, you know “Of course” is not necessarily that easy to pull off.

Because you've got all these systems that maybe have been built up through acquisitions, in our case, and it was hard. Another thing that we assumed is that our developer advocates should just be building these cool solutions that took all of our tech and then we would go out on dog and pony shows and talk to people about what they could do with our technology. And they're like, "No, what we need is sample docs, sample code, better documentation." And we were like, "Oh, you need boring stuff because we're a boring company. And you're a boring company, and you have boring customers." That's what you need, not something sexy and cool. And then this was like maybe the biggest thing that we learned is we discovered as we started listening that our internal developers were the problem, or rather, I should say, were the solution to the external...to reaching the external development community, third-party developers. And so, we would say, "Hey, you guys, you need to be more API first." And first of all, often they had to be convinced of that, so they were like, "Why? We build products, we don't need those products to talk to anybody else. We just we just want them to fit in a box."

So, we had to convince them of that, but the next thing was, well, we need some standards for these APIs. And so, all these things that like I would guess, again, that we'd often take for granted, at our company, it was hard, we had to figure it out. And the last thing was, we said, "We're gonna put all the docs in one place. We want somebody when they think of an Adobe, 'I wanna work with Adobe, I'm a developer,' we want them to go to one place." And all of the code, all the documentation, and everything was scattered around everywhere. And so, they said, "Well, if you want us to put the docs in one place, you have to make it easy to get it there." And because we have a content management system, we said, "You just use ours." And they're like, "We don't wanna use our own content management system."

Reaching external developers

So, like, any rate, we figured...we quickly realized that we didn't understand who we were trying to sell to, who we were trying to build for. In listening to them, we started changing the sorts of things that we provided. And it sounds really old and boring because, like I said, we're old and boring, in fact, Bear Douglas is here someplace. She was at a company where I think I was in my 30s, which was considered ancient at this company, Strobe, one of the ones not mentioned, where we first met. And I don't know, I was like...I don't know how old I was, 33 or 34 or 35, but they were gonna get me a cane. So, you know, this was...this is us, it's old. One thing that we learn, though, again, coming back to the internal developers, it's hard to reach external developers if your internal culture doesn't really think about those external developers. And I'm saying this as somebody who works at a larger enterprise, but I'm willing to bet that, to some degree, it applies to everybody in here.

There may be companies that just get it because it's from your...built into your DNA from the start. But on the principle of "garbage in, garbage out," if your internal developers don't have a mindset of wanting to work with the outside world...and I'm not just talking about lip service of doing it, but actually building in such a way that they're building for the outside world, constructing the APIs from the start, architecting the APIs from the start, writing documentation from the start, with the expectation that somebody outside the company is gonna have to use it. It's gonna be a struggle. It doesn't matter what the people in this room do in terms of going out and doing... I don't know where Chloe went. I thought the kind of the campfire scenario probably wouldn't work for us, but that idea of having a unique brand for the meetups, I thought was a really good idea, but it's not gonna matter if when you go talk to the people outside the company and you show them what you've got that is either, A, not much or if it's written in such a way that it only applies to people inside the company. And, oh, by the way, one thing that we also learned is that if you don't write from the start, and again, this is 101 for most of you, I'm guessing. But if you don't write those documentation, those docs from the start, and those APIs from the start for external consumption, it turns out that internal users are external users, as well, right?

So, somebody who's sitting in a cubicle down the row, if she can't use those docs, if she can't understand them, guarantee that somebody outside the company can't. And again, this seems like obvious, probably to some of you, but it's not obvious, I found with a lot of developers, they build for those on their immediate team, not for external consumption. One thing that really helped us in this journey was a guy named Bill Staples, when he was at Microsoft... He now runs engineering for a big chunk of our company. When he was at Microsoft, he was one of the key people responsible for open-sourcing .NET. And he is my bull in the china shop when we wanted to make it easier for employees to contribute and participate in open source communities, which we view as a way of a kind of a proxy for having a platform mindset, he said, "What do we need to do?" He said, "Here are the problems, and here's what we would like to do to solve them." And he just smashed everybody that was in our way and made it happen.

Speak a language that resonates

So, finding an internal executive who's willing to stand up and make developer experience a priority is a big deal. You need to have bottom-up adoption, but having that top-down push is also helpful, and Bill was fantastic in that. And then lastly, I would just say learn to speak the developer language your stakeholders understand. So, when I first started talking inside Adobe about the importance of open source because it's all my background. It's what I care about, it's what I'm passionate about. And I just got blank stares from our engineering leadership. And then I would say, "Well, look at what Google's doing. Look what Facebook is doing." And they said, "Well, that's not us." So, I had to learn to couch the language in what would make our platform more permeable to somebody outside. "Well, let's open source our SDKs. Let's open source our libraries. Let's open source our docs, so that other people can work with us on it."

I had to put it in language that they would understand from a strategic perspective, and we might assume that everybody reads the same blogs, that everybody follows the same people on Twitter and they immediately get it. I guarantee they don't. But as we take the time to listen to what they're really saying and try to satisfy their needs both inside the company and our external developers that we're trying to reach, we'll be more successful in our devrel activities. Thank you.