How to scale developer relations through content

Transcript

Adam DuVander: One of the key aspects of scaling is content generation. That's how we scale. Much as we would some of us would love to travel, and I've traveled pretty extensively around the world. As much as we would love to travel and give talks in person, the really scalable way, balanced way, work friendly and a family friendly way is to create content generation. So let's hear from a man who went in his teenage on a road trip with a man and his donkeys on how we can write scalable content.

Speaker 2: Alright. Thank you. Oh, yeah. Yeah. Alright.

Donkey man conversation is something that can happen over over beers at the end. Happy to tell you about that. Donkey man would not drink beer himself, but I'm I'm happy to and and chat about that. Alright. So before I get into talking about scaling DevRel with content, I wanna share a concern that I have, and that is that we've got many beautiful developer evangelists, developer advocates, community managers in the room today.

That's terrific, but my concern is who is helping the developers right now? Is it There's someone with a with a four zero one unauthorized right now, and and they might have to actually Google it. That's but hopefully, your excellent documentation is what they'll find, and that's certainly a type of content that we can all agree is is important. And yet, when we talk about scaling DevRel, often we think of adding more events and not more content. So you probably all know this view here or maybe maybe this one's more more likely for this group.

And I'm trying to find the perfect spot in the room. Alright. So but of course events is not the only part of DevRel. There's a lot of pieces to it, we've talked about a lot of them today. A lot of these maybe are event related.

If you haven't seen Phil Leggett's DevReloMeter, you should go check it out. It's pretty cool. But a lot of these are also content. And then many of them also overlap with what would be traditionally marketing. But of course, we all know there is no developer marketing, only teaching and enabling.

And in other words, share knowledge not features, which is a lot easier to do one on one when you're talking to the developer, when you're in person. And when that goes to content, a lot of times that ideal gets lost. And so that's why I've been saying, share knowledge not features. Anyone that's worked with me in the last three years has heard it already. But that's where I start from when when talking about content oriented toward developers.

And I'll tell you where that came from. So when I was at Programmable Web, it was my job to read every single API blog that existed. And I saw many posts like this that that I came to dread that were, Sumco is proud to announce a major update, yada yada. I would fall asleep, and then I would remember, oh, right. It's my job to try to figure out what the news is in this.

Like, what's important? What what does someone actually care about? Right? And then when I went to the provider side, I realized that's really it's our job. It's our job to be able to find that story, the story that the developer cares about and share that.

So an alternate title for this talk is you should blog more. And if I said that to you, who's just go ahead and nod. Who who who agrees they should blog more? I I should blog more too. So that's that's the bulk of the of the content that I'm gonna talk about.

We'll we'll touch on a few others as well, but I'll share how I helped scale content mainly through blogging across a few different organizations. So I should first say about about the term. I so I'm not an English major. I don't care what prepositions you end sentences with. But this one I do care about and and that is so the thing that you write as a blog post and it goes on a blog.

You don't write a blog. And this may be a lost lost cause, but I think if all of us in this room could just take that back to our organizations, And I know there are some people here who can evangelize the things. So just take that back and maybe maybe we can win that fight. Okay. So when it when it comes to blogging, you need someone in your organization to own it.

And the this is the the technical side of blogging even. If you have someone else who's doing it, but bringing that technical side, bringing the shared knowledge not features. And when I say own, I mean the way that you own a dog, which is not like a thing that you collect, but rather that you say I have responsibility for this. Right? So someone needs to own the blogging like a dog.

Someone needs to champion it and champion that share knowledge not features approach. And then of course, someone has to power it, which means writing. And like the talk before, it doesn't just have to be you. It doesn't just have to be one person. It shouldn't be if it's done well.

So how who is who is owning champion empowering depend depends on the size of your company. So if you're large, I'm at CenturyLink. We have an entire team to curate and to reach out to others in the organization to write. Hopefully, if you're of of size, you have at least one person full time who is focused on this. And of course, if you're small or tiny, you already know that it's you that's doing it.

It doesn't mean you have to be the only one who writes, but it's you that is that is the champion of it. And if you don't do this already, I'll talk about the thing that you need to do already in a moment, but this this question I get all the time. How do you how do you make people right? And I've by the way tried this approach and it doesn't it doesn't work that well. So you have to show the value.

You have to be able to say it hits the the metrics that we wanna hit. It reaches the audience. The same audience that I would talk to one on one at a conference, I can reach many times with this with this content. And this by the way is the graph of OpenStreetMap registered users. So that's definitely a very community oriented group.

And so one of the options that you could have is to find outside help. At Orchestrate, which was a small database as a service startup, we would hire CodeSchool grads to write some code and write about it, and we would pay them to do it. So it doesn't don't you don't have to look within the confines of your own organization. You can reach out to the community and beyond. So this is the this is the piece that you should be doing if you aren't already.

If you're the one that's going to to to power this, you should create an editorial calendar. So planting the stakes so that you can you can hit your goals. So I get this question all the time too. You know, how how many so I'm I'm gonna I'm gonna do an editorial calendar. Alright.

So how many how many posts per month should I do? How many posts per week? How many posts per day? Right? And I always I answer the same way, which is this.

Two. Two. Also rock on. But yeah. Two.

Two is the answer. No matter no matter by asking the question with that blank, you've already defined what time frame you can handle. Right? If you're if you're asking how many per day, alright. I you can do it.

Two. Do it. How many per year? If you're asking if you're asking per year, still the same. Yes.

Two. And I think you'll make them really good. Alright. So for the calendar, doesn't matter what you use, it matters that you do it. And I have used all of these before.

This is Trello in calendar view, Google Spreadsheets, a Google Calendar, Asana in calendar view. That's a a Word doc, not my favorite, but and then a a, you know, just a plain text file. So it doesn't matter doesn't matter what you use, but that you are planning what you're going to write. And by planning, I mean two things. So it needs to be visible.

So hopefully organization wide because you wanna push this out in your whole organization saying, hey, let's all share our knowledge. But then also it has to be specific. So not that Victor's gonna write a blog post on Tuesday. That's what he's doing That's what he's doing now? Okay.

So so hopefully what Victor has is a very specific blog post that he's going to write all the way with the with the title. So no headline goes here. So being very specific about what it is because that's you're much more likely to actually get results if you've laid it out directly that way. So another thing that helps if you're trying to spread this message within your group to create more content is to be able to outline the types of posts that you might create. To be able to create templates of them, be able to to at least describe a post of this type looks like this.

So you might have an interview post where you reach out to someone with a point of view in the community. Email interview, and that could directly turn into a blog post. You might have someone in your organization who has very strong opinions that you wanna get out there and maybe you have to interview them to get it out there or maybe they decide to write it up and you help to turn that into something that go goes out there. Sharing how you work. If developers are your audience, they wanna know how your engineers build the thing that that you're talking about.

So share that. Absolutely, customer examples are fair game. It doesn't have to be a full blown case study. Don't overthink it. Work with your your customer to to show up an example.

They may even write it for you. And you can have these roundups of useful tools whether they're technical tools or whether they're the things that go in your evangelist travel kit. And of course, the meat and potatoes of technical blog posts, developer focused content is definitely the tutorial. And that can then filter into many other areas. You can reuse that same content in other ways.

If it's a if it's some code, turn it into a sample app that can easily be copied and downloaded. Have a demo running of that of that so you can see what it is before you actually go and build it. Make it so easy that it's just a click of a button to deploy it and see the app, and then you can go and make your changes. Right? And of course, you're getting started type of content.

Tutorials could end up in there as well. And if you don't have any getting started, forget everything I've said about focusing on the blog and work on your getting started content first. If you already have it, you can return to it and work on that time to first hello world. See if you can decrease that. Make it even easier to get started.

And then lastly, sharing use cases I think is really important. So and these may come out of tutorials for particular use cases too. At Programmable Web, a lot of new API providers would say, well, I don't want to hold back the imagination of the developer. I so I'm not gonna tell them any ways that they could use our API. And, you know, you need to seed the creativity.

You need to give them some idea of how they might use it. And then I know once they've played around with it, they'll then they'll be creative, but you need to seed it with those use cases. I mentioned documentation briefly. It's very important. It I'm not gonna talk much more about it other than to share an ancient text related to documentation, which is a tweet from 2012.

That was a year, many years ago. Yeah. And I shared this mainly to bug John Sheehan because my most retweeted tweet that year was something he said. And I put it up there so that so that you can go and fave and retweet it and give him notifications and that's it. The doobly link slash thanks John Sheehan.

Alright. So talking beyond the blog. These are some things you may may want to do and may not. It depends on on your audience. White papers being being one of them, certainly one that maybe developers don't always like.

Ebooks wait. Did the is that this yeah. I don't know which I don't know the difference between them. I think I think it's if you want to sound smart, you publish a white paper and if you want someone to actually read it, you call it an e book. I think that that's think that's how it is.

So But understand the audience that would use it. And so if if your entire audience is developers, they might not wanna read a white paper or an e book. You have to know what your what your customers drink. And in the API world, this was mentioned briefly earlier, it comes kind of in in two flavors. You have the API as the table upon which your service, which is the beer sits, or the entire company is the API.

The API is the beer. The beer is, of course, the thing your customer wants. So you're working with developers. No matter what, they're interested in the API. If you have an API, they're interested in the technology.

But if your API supports a service, then you're definitely going to have to talk to the audience that also is interested in the beer, in the service. Right? So that's where you especially should reconsider the types of content and make sure that you're talking to the audience. And that's that goes for webinars as well. And I've seen developer webinars go well.

So it's not necessary that developers always hate webinars. I think it can work, depends on your audience. And videos, I think everyone loves videos whether it's a screen cast or whether it's your beautiful face talking to developers. Or a movie. So Or a movie.

So obviously, many types of content. I'm gonna go English major one more time here and that's to say, even though I have said content 50 times this talk, I really don't like the term. I don't like it's fine for us to call it content, but when you're talking to the person who will actually consume it, don't call it content. Call it what it is, a tutorial, a getting started guide because, again, you're sharing knowledge and the content calling it content is kind of the features within that. And so to no surprise to anyone, I have a blog version of this talk at shareknowledgenotfeatures.com, And we can talk about it here the rest of the day, and you can find me on Twitter.

Thanks.