The tech blog problem
barriers to showcasing skills in writing and in public 2026-06-09 #writing
Software development teams should have a tech blog, especially when your organisation has several teams. Tech blogs give technical staff somewhere public to show their expertise, with lower stakes than conference presentations. And although not everyone would enjoy improving their writing skills, it becomes a super power for people who discover that they like it.
New tech blogs can burn lots of effort, and deliver disappointing results before eventually failing. Even if you know how to write a blog, translating that experience into a team blog faces new barriers. If you don’t solve the tech blog problem, you end up with an embarrassing abandoned blog that only has two lonely posts. And one of them describes the CMS set-up.
The CMS trap
Development team members naturally seek out their usual kind of work. A new tech blog becomes a web site design project, with a content management system (CMS) development project for good measure. You don’t need either of these things.
To avoid the CMS trap, frame the tech blog as a writing project, and don’t let design and coding tasks distract you. Use your existing web site design for the first year, and don’t even think about blog navigation until you have published twenty posts. Instead, use a fixed reverse chronological list of posts without any navigation controls. No pagination, no categories, no tags.
Ideally, you can use your marketing web site’s CMS.
However, depending on the organisation, you might launch sooner if you use a
static site generator
on a separate blog subdomain, and forgo a joint project with your marketing team.
Meanwhile, unlike the marketing team, the developers will using Markdown files in a Git repository for review and publication.
The false start
Tech blogs that the CMS trap still fail, because the stream of articles dries up before it even gets started. Even if you have several development teams, you might only have one or two editors who want to start a tech blog enough to write articles unprompted. In fact, you probably should defer all other tasks until you’ve solved the writing problem.
To set a baseline for initial success, write and schedule twelve monthly blog posts before you launch the blog. Do this before any design or publishing system implementation work, to make sure you can. You don’t necessarily need twelve finished posts, as long as you have sufficiently viable drafts that an editor can get into shape, on behalf of an author who has lost interest.
The volunteer problem
Blog posts have the same problem as other kinds of software documentation: most people hate writing as much as they hate reading bad writing. As with other unpopular chores, the framing matters. It helps to acknowledge that nobody wants to do this, and that you’ll all share the work. Agree a fair and transparent policy, and support anyone who struggles.
For example, adopt a policy that each member of the technical staff writes one blog post. If you hire regularly, and new joiners write a blog post in their first year, no-one has to write a second blog post. At this point, it doesn’t matter if one or two enthusiastic writers write half of all blog posts, because you’ll have enough variety, and you’ll have solved the tech blog problem.
