A few months ago, a CTO at a conference asked me, “how do you encourage a blogging culture at your company?” I’m a reasonable fellow to ask. Not only have I written a huge amount for AppFolio’s engineering blog and encouraged other AppFolio engineers to do so, I also did something similar at OnLive with even more success. By “more success” I don’t mean the blog was more popular (it wasn’t,) but that about half the posts were written by engineers other than me, which is the hard part. Writing a lot is all well and good. Getting other people to write a lot is an accomplishment.

The hard part isn’t getting a few posts started. The hard part is blogging with any regularity. And it is hard. But there are some things you can do to make it easier.

What Techniques?

I’ll start with a trick anybody can use: if you add a new feature, ask the person who just wrote it for an explanation, by email. When they answer, you have the start of a blog post. They may want to write it, or you may, or it may be easiest to co-write. But that answer is the seed of something interesting and worth writing down.

Here’s a trick that managers can use: lead by example. If you ask an engineer about the feature, and they respond, and they don’t want to write the article then you should. You’re telling them it’s important. That’s great! Now show them. If it’s important, then it’s worth your time too, not only their time.

You might say, “ah, well, you know it’s hard to find time…” And it is! It truly is. And so the next tip is harder: figure out why you want a blogging culture at your company.

The fellow talking to me had a competitor who blogged relentlessly which got them lots of business. It meant that his competitor was setting terms, customers were asking if his engineers could do as well as these other engineers who were out writing in public about engineering… And that was great news as far as starting to blog. He knew exactly why he needed to, and it was important to the business. Which means that when it comes time to write up that email into a blog post, it’s also easy to justify why that is an important business activity, worth the time of expensive engineers and expensive managers alike.

Good. No matter what you’re doing, knowing why you’re doing it is the most powerful technique that exists. If you have a good enough “why,” you’ll find a “how.” But if you have no reason, it doesn’t matter how skilled you are.

What Topics?

“Yes,” you might say, “but other than new features, what do I write?”

Write up bugs. If you had a problem, somebody else has had a similar problem. Write it up. The “ask for an email explanation” trick works for this, too, if somebody on your team has been debugging.

Write up “what did we learn?” posts — have you just started with a new agile technique like pairing? What did you learn from it. Or a new technology like GraphQL? What were the hard parts? What did you consider and reject? Or if you just went through a design exercise and considered five different libraries before choosing one, write it up! How did you choose? What was specific to your task that made up your mind? Which libraries were just unfit for use?

Engineers want to know these things. There’s also a built-in way to have them stumble across your article when they’re trying to make the same decisions.

If you’re proud of something you did, like a new open-source library, write it up.

If you have a book club or watch conference talks together, write up your favourites into book reviews and conference talk reviews. Do you do any kind of periodic research or whitepaper reading? That’s a “what did you learn” as well.

And of course, if you have a reason to be blogging, do whatever supports your reason. I’m giving answers that are great for building engineering credibility, which can be good. But if you’re blogging to let people know how cool your product is (hey, Honeycomb!) then that changes what you write, too.

As an advanced technique: if you have a book club or similar, or if your company gives meetups, consider recording them. You may have a hard time getting permission (or you may not) and you should absolutely tell people that you’re doing it. But a video of a book club discussion or a recruiting meetup could be an awesome blog post that takes barely any writing. You may need to do a little video editing, but don’t be picky — the discussion is often valuable even if you don’t turn it into a glamourous thing with transitions and jump-cuts. It had value to the team at the time, and a viewer may also get something out of it.

As you go along it will get easier to tell what to write. What gets comments? What do customers notice? What accomplishes your goals? Move in the directions that work.

But Technique Isn’t Enough

When I say to lead by example, I mean that it has to be shown (not just told) that managers and executives at your company think blogging is important. They could call out especially good posts, or write posts themselves. But one way or another, it’s hard to shake the feeling that writing blog posts isn’t “real” work. And only managers can make it clear that, yes, it is real work and the company appreciates it as much as the other work you could be doing.

Employees have a keen nose for bullshit.

If you don’t actually mean that blogging is real work and it’s okay to spend time on it, they’ll figure that out. If blogging is treated like goofing off instead of work, they’ll know.

So: managers should write blog posts too. Very senior engineers should, if possible. Blog posts should get mentioned in stand-ups or other meetings, just like other projects. It’s work, and you should treat it as work.

Sustainability

A few words about keeping this going:

Publish on a schedule. Weekly is probably too often, especially at first. Consider every two weeks, or even monthly. It seems long, but remember that finding time to polish and edit a piece of writing is hard. Also, don’t be too picky about polish and editing, especially at first. It comes with time.

If you think you have enough people willing to write, wait a bit before you first publish. Build up a month or two of backlog that are ready to publish before you hit “go.” That also lets you collect some pieces of writing from people before you decide, “oh, I won’t have any problem finding a post a week.” It can take awhile for the writing to actually materialise. That’s fine, but you need to plan on it.

Have people you’re bothering about writing, often. Team members, managers. Keep in mind that they don’t have to be engineers, even for technical writing. QA probably has a fascinating perspective on the code you see every day. Customer service may have really good insights, and may also have some very good writers on the team. Sales won’t want to write, as a rule, but it can still be worth asking — those are folks who can teach you something, especially about the customer. So: ask everybody, not just engineers.

A Guest Expert

Recently, Dan Luu wrote a post which surveys various companies with good and bad blogs, and what they do differently.

He points out some of the same things I do, such as high-level support, especially from people who blog. He also points out that process and approval must remain quick and lightweight — very true! But if you’re trying to turn my recommendations into a specific process for a larger company, his article is absolutely worth your time.

But How Do I Start?

I’ve given you some ideas, but not all of them can be done by everybody.

If you’re an individual contributor, you can write. You can also bring up writing during meetings, as work.

If you’re a manager, you can write. You can bring up writing during meetings. You can communicate to the executives that writing helps the company, and why. You can mention to your direct reports how useful writing is, and praise good writing to the rest of your team.

If you’re an executive, you can write. You’re probably good at it. You can mention writing during meetings, both your own work and the strategic importance of writing. You can tell your line managers and the senior engineers that get the most respect. You can talk about pieces of writing that have helped the company, and how — for instance, if a customer asks about something your company wrote, that’s good news for the team and should be shared.

Step one is to have a reason. Step two is to write. Anybody can write. And everything gets easier once you’ve started.