Blogging is a great way for teams to work in the open • But it doesn't always come naturally to all organisations. As a tool for corporate communication, it can feel different, even a bit weird. Teams don't feel confident doing it; bosses don't feel comfortable allowing it.
This website is an attempt to make it all a bit easier. It's just a series of tips you can apply to make blogging work for your team. Just scroll down 👇️, or hit the space bar.
It might help to call it something else • The word "blog" can put people off - including your teammates, your boss, or your stakeholders. If people like that pull uncomfortable faces when you suggest using a blog, just call it something else. A notebook. A journal. An archive. It doesn't matter what it's called. The act matters more than the name.
Keep each post about one thing • That makes it easier to link different ideas and thoughts together. It also gives you the superpower of answering people's questions with URLs. If you have more than one thing to say, write more blog posts. No one will complain if you have lots to say.
Get the whole team involved • Writing blog posts should be a team task, something that everyone gets a chance to do. Some people will feel very confident about it, others will perhaps need some support and encouragement. So spread the burden around: make sure everyone has an opportunity to write and publish something.
Write lots of short posts about small things • Blog posts don't have to be about big ideas and big projects. The grander and more important the subject matter, the more likely management will want to get involved, which will slow things down. It's better if your posts are mostly about small things that your team has actually done: "We tried this new technique, or this cloud tool, or we learned this thing from user research and responded to it like this."
The bigger story will tell itself • Lots of short posts about small things build up into an archive of thoughts over time. The bigger that archive gets, the better job it does of telling the wider story of your product, team or organisation. You can’t predict what that wider story will be, not from the start. Letting it unfold is part of the adventure.
Make sure every post has a clear purpose • Before you start writing, ask yourself: "What's the point of this blog post? What do I want people to understand, know or do after reading it?" Make sure you've got that purpose pinned down early on. You should be able to sum up the purpose in a sentence or two. If you struggle to write it, that's a sign that you need to re-think the idea.
Blogging is best for musing, not marketing • Your organisation might already have a blog, or use blog posts, to sell its products or services. But when a team is blogging to work in the open, the blog meets different needs; it's not really about selling. Use a blog to demonstrate that your team can think out loud on the internet, and is empowered and encouraged to do so. Don't use hits or page views to measure success: your goal is to build an archive, not an audience.
Even the most secretive organisation can open up about something • It's normal for most organisations to want to keep some things secret. But there are probably many things you can still open up about, particularly with regard to how you work. What neat tricks has your team discovered? What code snippets have you shared on GitHub? What top tips would you share with peers at a conference? I think even the most security conscious team can find some things to talk about in public.
Illustrate your posts with pictures of actual work • The problem with stock photos - even the good, free ones from websites like Unsplash - is that they're everywhere, and they look like stock photos. They don't look real. When you're trying to work in the open, they break the spell. So as much as possible, try to illustrate your blog posts with images that show the actual work. Screenshots? Animated gifs of code being written? Photos from team get-togethers? All of these are good ideas.
Word counts don't matter • Your posts can be as long or as short as necessary to tell the story or explain the problem. Most blog posts are pretty short (remember: most readers are busy people) - but you don't have to cut all posts to the same length. When there's more to say, let it be said. Give every post the length it needs.
Constantly experiment • Mess about with formats, styles, visual presentation, content and attitude. Try different things, and see which ones work. Could this post just be a list of bullet points? Could that one just be screenshots and captions? How about video? What about a transcribed conversation, or a diary, or a blog post written like it’s an email? Try things. The more varied your blog posts, the more likely readers will keep coming back. Readers love to be pleasantly surprised.
Use the “Would I want to read it?” test • After you've written a draft blog post, leave it for a few hours or days, then come back to it and read it with fresh eyes. Be self-critical: would you want to read this if someone else sent it to you? If the answer's "No", or even just "Meh", re-write it.
Write how people speak • This is how you get to text that you’d be happy to read. Write like one human talking to another, not in corporate-speak. Some people - especially senior management - don't always like this, because they see simple human language as a sign of unprofessionalism. I disagree: the clearer your language, the more you demonstrate that you’re actually thinking about the needs of readers in the first place. That’s professionalism.
Blogging is an investment in institutional memory • This is the outcome you're aiming for: blogging is an act of deliberate record-keeping. The time your team spends blogging now is time saved for future members of the team, who will have access to a fabulous archive of product or corporate history. What better way to understand context, and avoid repeating mistakes?
Some teams who are doing it right:
Get inspired • If you want inspiration for writing your first blog posts, look at Blog post formats
Buy the book • There's loads more about team communication in The agile comms handbook
Made by Giles Turnbull, © Copyright 2022 Use the human voice. Thanks to Gregory Cadars for the John Doe HTML template. Last updated: 23 October 2023. Send your questions and suggestions to: firstname.lastname@example.org