Making sure that what you’re writing is useful, interesting, and timely isn’t easy when you’re juggling a full dev rel programme.
Freelance writer Adam DuVander knows this and wants to share his simple five-step plan for creating and publishing effective content. Adam’s talk was recorded at DevRelCon London 2018.
So I do help companies reach developers with content. I’ve been doing this for a while, starting with my time as the editor of ProgrammableWeb. But I’m going to start today perhaps with, whoops, a story…there we go… about a trip to the Swedish Open.
The site of the Swedish Open, they weren’t playing at that time. I went there for a conference from a Swedish publication. And they wanted me to talk to their employees. And the punchline I give away a bit here before which is, after lunch, I came back to… I’d connected everything, done all the things you do to make sure everything’s going to be fine.
And I came back to this. And you would think, “Okay, so you unplug it, you plug it back in and you’re set.” You reboot, you’re set. You reboot, some…nothing worked. Nothing I could do. And in fact, we were maybe 10 minutes into what was supposed to be my talk and the room is full of people. And there’s someone there trying to fix it for me.
And so I started drawing my slides on an easel. And remember, I’d come like, you know, a long flight for this talk. And they had paid for me to be there and I felt really like, you know, so I’m doing that finally, 10 minutes into it, I’m sweating and they’ve got it fixed and I fast forwarded through my slides. And I think probably raise your hand if you’ve had some experience that feels something like that?
Yeah, there we go. That’s a really common feeling in DevRel, I think. And it was so traumatizing that I took a picture of the adapter thinking that that would mean so much to me later having gone through this traumatizing experience. And the thing is that a talk does not last forever.
Maybe there’s a video taken of it, but content with the same elements of that talk can last forever. And so that’s what we’re here to talk about today, about, as Martyn said earlier, blogging all the things.
Because I think, and it was a great prelude to this talk because I think you need sort of combining those together. Sometimes what you need to be able to get that momentum is to blog all the things. This is, I believe, my first post that I ever wrote for ProgrammableWeb.
I think the new line, there were paragraphs at one point that might have been my actual IP address. So, I ended up writing many, many there. But what a lot of us have happened with, and this has happened to me, too, with either personal blogs or even company blogs, is you end up with something like this, where you haven’t published for an embarrassingly long amount of time.
And so, this talk today is about how to be able to get into that groove to where you don’t end up with that, and you end up with something that will last forever. So we have the five-step plan here to publish developer content and here are the steps.
We’re going to create a content calendar, generate ideas. I have some ways to do that. Martyn had a whole talk about how to do that as well. Then we’re going to write, evangelize, and seek help. So, who’s ready to go on this journey? Yeah? All right. All right, let’s do it then.
So starting with the magic of the content calendar. I get asked this question so often. How many blog posts, and by the way, we’re talking about blog posts, you can think of it as any type of content, written, visual, otherwise. I think you can plug those same things into this same process.
So, my answer to this question is actually the same. The same answer to both of those is two, that’s the answer. I think the answer is actually in the question itself. Maybe every now and then people will ask, “How many blog posts should I write per day?” And I think, well, if you’re going to ask how many per day, if you’re ready to write one a day, you might as well write two a day.
And if you’re asking by the year, then, you know, I don’t think you can make one a quarter. So two a year, let’s start there. So what you need to do is get yourself some sort of tool to put your content calendar into.
I gave this as a workshop on Tuesday, we all got really excited about the tools that we were using. You don’t need to get too excited about it, you can use just about any tool. So Trello is one I like, I’ve used it multiple times. You can walk the content from left to right, from idea to published and promoted. But you could just simply do it in a spreadsheet and put in columns for the things that you care about, about the content.
Asana is great, too. Has this calendar view, which I really do like, has ability to have other people involved, have sub-tasks, you can get all complex if you want to. But again, the point is to not focus on the tool, but focus on the stuff that goes in the tool. And so, for that matter, you could just use a simple text file, and I have before, and that works as long as other people can see it.
A lot of times a text file just sits on your hard drive, and that’s not going to help as you look to expand beyond just you writing those two blog posts a day. So, you want your content calendar to be visible, visible to others in your organization, but also to be specific.
And then creating templates for types of posts. I think this is a way to get around that write all the things problem, where you just start throwing things that aren’t strategic into your calendar. Think about the types of posts that you could have, and structure those posts and have examples of great ones that you can share with other writers.
But let’s be clear, you have to, you’re probably, because you’re the one at this conference, you’re probably the one that will start this. Even if you have a group that’s doing this right now, if you think that you need to get, say, more of a developer voice into that, you’re going to have to be the champion to do that.
So, start with your contributions and put together ideas. Again, Martyn had some ideas of how to do that. I’ll give a few more. But first, this spoon is referencing “The Matrix.” And much as in “The Matrix,” there is no spoon, there is no developer marketing.
And I realize that I’m saying that during a track whose name is developer marketing, and my old title had developer marketing in it. But there is no developer marketing. There’s only helping your developers and sharing knowledge, not features, which was the way I put it when I worked at SendGrid.
A couple of the SendGriders here in the audience, and got so tired of me saying that, that one of them made me stickers with that on there. So that’s from Nick. And I have a few if you want to have one after this. So, what I mean by sharing knowledge is to focus on use cases and problem solving, and not what your product specifically does.
Other ways to get ideas, and I think a lot of ideas come just from making sure you have that developer focus, and I think it’s really easy for us when we’re in front of developers, but for some reason when we get behind the, I was about to say typewriter, but no one here I think uses a typewriter. But when we get behind the typewriter, it gets harder to keep that developer focus.
So try to keep it as much as you can. It can help to look at other frameworks, other technologies to be able to pair with your own to be able to come up with ideas. I spoke with someone last night who basically was creating a matrix of languages and products, and then planning content that fit in all of the overlapping boxes there. So that is a way to be able to come up with X times Y ideas, for sure.
Then, one of the great things about an event like this is there are so many opportunities to partner with other people, and to write things together and co-market them together. And so I encourage you in these last few hours, and in the after-party activities, to have those conversations, and get to know someone so that you can work on content together.
Then listen to internal chat, and whether that’s actual chat or people physically speaking, if you work in an office, and always be looking to put those ideas into your content calendar. And for that matter, external chat is a great place.
So we’re all around developers a lot. So, listen to those and make sure that those ideas get stuffed away and you can turn those into fully baked plans for content. And then Martin mentioned this also, support tickets are gold for this kind of content, being able to know what people are actually asking what people actually care about, and turning those into content.
So, all of those ideas, they go on to your content calendar, which is visible to others in your organization, and as specific as you can get it. And then you write it. Thank you. Oh, okay. So, just a little bit about the writing process.
So, people who read online are skimming your content. I think that makes it easier to create content for them. Because if you come up…you’ve already come up with that great headline. Catchy. It’s focused on sharing knowledge, not features. And so just write a few more sub-heads that do that and then, in my experience, that helps you to be able to write those next sections that you can focus in and really write about a particular area.
That can also help with handing off. If you end up getting some help, you can hand off these outlined posts to others. But again, at first, it’s just you. So set aside the time, and it doesn’t have to be a lot of time, but just make sure that you have something regular, something that fits that cadence of two posts per time frame that you’re going to be working on, and do some sort of time boxing.
Set a Pomodoro timer and work on one subsection of the next posts that you have coming up. And through consistency, much like a turtle, you will eventually get to where you want to be. And then, don’t edit.
I don’t really mean don’t edit at all. You should read it again. But does anyone else here suffer from wanting to make it perfect? Yeah, yeah. Okay. So stop, stop that, you have my permission to not edit, not make it perfect, because the idea here is that you want to publish and you have a date in your content calendar.
So, however good you can make it by that date, that’s when you need to publish. Because then you need to keep doing that because that’s going to build your consistency and show others what’s possible. And that’s when you go and you evangelize to them. And this is probably starting with people within your own company. And when I say evangelize, I guess I mean advocate.
Because I went to the DevRelOMeter and put in the things that have to do with content, and it’s actually not evangelize. But basically, what I’m saying is promote. So, and this is internal, really even before external. Make sure that people inside your company know and can help you to promote it externally.
And when you go and do that externally, I mean, these are potential places, sure. But you know your audiences better than I do. Go to the places where they are to be able to share it. And tell your friends. Don’t get stuck on thinking that you need to blast this out to a bunch of people.
I mean, DevRel is a relationship business. So, send an email to three people and say, “I just wrote this. I would love it if you would read it. And if you think it’s great, share it with someone else.” And internally, as I mentioned, look for whatever ways that your company communicates with each other, make sure that you’re sharing it that way too. Make sure that you can, that people know the stuff that not only is coming up, but that you’ve published because you’re trying to create this momentum here.
So, the first three sections were really about things that you completely have control over. And then evangelizing and the next one we’re about to go into, seeking help, are when you start to have to work with others.
And so, I mentioned evangelizing, this is sort of summing it up here, would be talking about it everywhere. And I bet there’s some people here who sort of had a little twinge, and were like, “Oh, sounds like marketing.” But remember, there is no developer marketing, there’s only sharing knowledge, and that’s what we as DevRel do really well.
So telling everyone about something that you believe in doesn’t sound that much like marketing to me. So, evangelizing to people is one way to seek help. But another is that you don’t want to be writing two posts per time period forever.
You need to get help. You need to have others. And that’s part of why you want to pull people in within your company, within your community, to be able to see the stuff that you’re creating and get them excited about the ideas you have on the editorial calendar. People have asked me how you make people write.
I think the SendGriders in the audience will tell you that this one doesn’t work. Instead, you show them the value. This is from Open Street Map showing all the contributions from the community. But you can have a similar graph of whatever metrics, and we’ve talked about a lot of metrics here, so whatever metrics matter to you, and show that you’re able to have content feed those metrics.
If you want to get other people within your company to write, one of the ways things you can do is to start to write complete or close to complete posts for other people, and make sure that it gets posted with their by-line. And that can start to build that momentum of saying, “Well, if so-and-so is writing.”
And you might talk to them and find out this great idea that they don’t have time to write. So it is their idea, so it’s not like you’re writing something completely different than what they would want to put their name on. But that’s a way to start to get that momentum.
And then certainly look outside your company, because everyone has their own roles that they have to do. So find freelancers or, again, partners, other people that you can make trades with. Put out a shingle that says, “Will pay people from our community.” Pay them in credits if that’s the thing you can do, pay them in money if that’s something you can do, but to get that content flowing.
And then, look at the parts where you’re getting bogged down and find ways that you can clear those up. So, you can get an external editor or someone within your company who’s better at that process or who can produce it, and then look at automation.
I was at Zapier for the last two years, so that’s where the image there comes from. But what ways could you automate it? This was screen capture from a chat at SendGrid after I left, and Brandon automated me. And this basically was what I had to do and it became a bot in chat.
And that is a fine goal for you to automate your way out of having to be the one person in charge. I would say don’t over engineer, especially too early on, because remember this is your one goal. You want to avoid that.
And if you spend too much time making a post perfect, too much time engineering your process, you won’t have the time to follow the steps here to create great content that you share with your community. Thank you.
Tamao Nakahara and Baruch Sadogursky demonstrate some mistakes to avoid when engaging with developers in this session from DevRelCon San Francisco 2019.
Amanda Moran from DataStax talks through the good and bad of transitioning from engineering to dev rel in this session from DevRelCon San Francisco 2019.
Write for us