5 Tips to Get Your Dev Blog Running

Published on May 6, 2020 (↻ June 14, 2024), filed under Development and Everything Else (RSS feed for all categories).

At sum.cumo, the company I worked for before joining Jimdo, I had in 2018 and 2019 built and grown their technical communication and open source programs. While I barely finished the first stage of a three-stage schedule I was working on, both programs were on track and, in my mind, successful.

How the interconnected programs were successful showed in the metrics (although we didn’t reach the aggressive metrics I had set for traffic growth, requiring them to double or triple Q-Q, these OKR usually landed at roughly 60%) and in an upward trend in applications through our website (which early helped save hiring cost). As I’m veering off to share my entire sum.cumo story, let’s get back to what I learned to be five highly effective ways to get a corporate tech blog going.

Contents

1. Use What You Have
2. Commit to Regularly Posting Content
3. Make It As Easy As Possible to Contribute
4. Keep Spreading the Word
5. Measure, Dial It Up, Trust in the Process

1. Use What You Have

The first and most important point is to take inventory and to be clear of what you have in terms of open and hidden content—and then to use that content.

Open content is content that is already available and lying around somewhere. Technical documentation, presentations, software, interview materials, &c.

Hidden content is content that is only in people’s heads. Ironically, this is what we usually connect with starting a blog of any purpose: How do we get to the content in people’s heads, and use it? If this is the only question considered it quickly causes inertia, both when it comes to starting as well as running a blog.

You want to tap both open and hidden content.

My time at sum.cumo provides great examples for both: Available open content included a sizable amount of small software packages that were suitable of being open-sourced. There was interesting hidden content with developers frequently visiting conferences. The first lended itself to extending sum.cumo’s open source program (which is dormant since I left) and writing about it on the blog. The second led to a series of conference-related interviews.

2. Commit to Regularly Posting Content

What is one of the main rules for blogging is certainly also one for corporate and engineering blogging: Post regularly. As you can say that a thousand times and still not do it, it’s important to commit to it—and to be clear about the content you can use, which is why this is only the second tip to share.

For any blog I’ve set up I’ve also defined a cadence to publish by. When I created sum.cumo’s blog I did so with an “SLA” of at least one post per month, which I soon raised to two per month, and then to one per week. Writing once per month is the absolute minimum in my view; once per week seems ideal, as a compromise between committing to providing value to users and not exercising undue pressure on the team or individuals in charge of running the blog (you can always post more).

3. Make It As Easy As Possible to Contribute

If you want to encourage your staff or your peers to write, you must make it easy for them. Super-easy if you can.

You want that because anything you put in the way of contributors—topics, style, guidelines, deadlines, reviews, &c. pp.—will reduce the likelihood that they will contribute. You’re also, adding this from a manager perspective, increasing the cost the blog has for the organization, which is something you need to be mindful of.

Get out of your way to make contributing easy. Allow people to pick what they like to write about. Allow them just to go for it. Give them the time to produce content when they want to. Be light on requirements. Have the individuals or the team in charge of the blog give cover: Review, edit, plan later, once you have a first draft. How you compensate is by communication: “Please send your draft and we’ll work with you to get it out there.” Communicate, too, to give options: “Let us know how involved you want to be in the process.”

What worked really well at sum.cumo was interviewing after conferences: We kept an eye on what conferences other developers would go, and then prepared three to five questions we’d send them, or would, if that made it easier for them, just meet with them in the cafeteria to ask questions, and maybe check on photos. It didn’t mean much work anymore to contribute, which is why that approach helped us feature more content of more sum.cumo developers.

A note here, because I’ve also seen people trip over this: Interviews, and especially short interviews as just described, are more on the “filler content” than the “killer content” side. Yes. The way to think about this, however, is as one type of content you’d use—not the only type of content—, and one you’d either make more valuable over time (more in-depth questions) or slowly reduce in number.

4. Keep Spreading the Word

The next important step, one to make a routine of, is to spread the word on your corporate blog (or any form of corporate communication that you want to invite for). Remind in meetings. Remind in all-hands. Remind in jours fixes. Remind in the hallway. Remind in conversation. Not every time, and not aggressively—but remind people that there is a blog and that you and the team are open and looking forward to contributions (and that you make contributing easy).

5. Measure, Dial It Up, Trust in the Process

Last but not least, an external communication program must be based on a process, and that process should build on metrics and involve challenges.

From the start, take a few metrics to measure goals and success against. For the beginning it’s fine to use (and I think you really want to use) quantitative metrics, like traffic. Traffic is often a terrible metric, but when you’re just starting out it’s viable. Later on you want to focus on qualitative data, giving a sense for how useful and valuable the produced content is.

In general, over time you’ll want to dial it up: Write more content, write better content, involve more contributors, try other formats,—set more aggressive goals. Make your company’s blog more popular than, what, your country’s largest newspaper’s site, and win a Pulitzer Prize on top of that. (You don’t have to. You get the idea.)

Finally, however, trust in the process. A blog, corporate or not, tech-related or not, takes time to build and to grow. If you know what you can deliver (inventory), if you keep at it (commitment), if you make it easy for your peers, if you talk about the effort (internal communication), and if you measure and improve and employ a process, you’re likely to do well, and get your dev blog running.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)