♪ [music] ♪ 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
gave 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 Martin 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 steps. We're going to create a
content calendar, generate ideas. I have some ways to do that.
Martin 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 what I mean by that is, it's not, "Brandon is going to write a post on
JavaScript sometime in November." It's, "On this date, Brandon will write
a post with this headline," and try to get as specific as you can.
Don't let placeholder text make it into your content calendar because who
knows how far that could end up going. 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, Martin
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...I was about to
say typewriter, but no one here I think uses a typewriter. 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 outlines
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 external, 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 finds 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. ♪ [music] ♪
