How To Kickstart Your Company Blog

  1. Create a feeling of safety around blogging.
  2. Set deadlines.
  3. Make the technology barrier low.

“We should have a blog”, they said.

As a growing tech company relatively new to the scene in Melbourne we were looking to connect with local software developers by publishing some of our more interesting experiments in technology, engineering and people. We have some hairy problems with cutting-edge Javascript development, scaling pretty big and data analytics, as well as the usual people and process challenges that come with growing real fast. As avid consumers of blogs it seemed logical to create our own to help us make this connection.

But when the call for volunteer bloggers went out mostly excuses or questions came back. People weren’t sure what to blog about, if they had to be experts, what the process for publishing would be like, if they had to conform to a corporate style, what the company’s goals in publishing a blog were and more. A lot of the questions implied a bit of insecurity at putting thoughts and ideas out there, and representing Zendesk while doing so.

In order to encourage our budding but tentative writers we ran a Blogging Workshop facilitated by Kimberley Lee which covered the following topics:

  • The business value of blogging
  • Writing your blog posts
  • Tips from the team
  • Your blogging questions answered
  • Editorial planning
  • Blog topic brainstorm

Over 30 engineers attended the workshop and we generated more than a year’s worth of blog ideas out of it. We also created a blogging handbook and a FAQ page on our wiki which between them contain enough information on what to do and how to do it to get anyone started.

Blogging brainstorm

We also locked-in a blogging schedule for the next year with a fortnightly assigned topic and author. One of the team set up this Engineering Blog, taking all of five minutes: it’s easy to sign up, and has a simple yet effective Draft > Edit > Publish workflow that allows us to get some eyes on our posts before they are published.

As our first author finished her draft a willing pool of editors organically volunteered to give their feedback. Now we have a Flowdock (think Slack but with threaded conversations) channel that allows us to let the editors know when there’s a new draft for consideration, kicks off the editing process and confirms publication.

Two months in we have (mostly) stuck to the schedule and have a process that seems to work well enough. And if you’ve ever tried to get consensus on process from a rack of engineers, that’s a pretty good achievement.