I was first introduced to the concept of a Communications Readme by this blog post from Simon Prior. In essence, in the same way as we create readme files for our software projects, explaining how they work and any idiosyncrasies that you need to know, what if we each had a readme that explains how we function, for the benefit of our colleagues?

When Simon shared his post, I’d been looking for something like this for a while; at the very least, when working in a fully-remote role, or an organisation with office locations around the world, I was planning to put something together which explained my available working hours. But a Communications Readme is much more than that.

Why create a Readme?

Remote communication can make it very easy for misunderstandings to occur, and a lack of understanding can sometimes be perceived as a micro-aggression, which can be difficult to correct if you’re not even aware that it’s happened. And as our teams change and grow, it can be difficult to hold everyone’s preferred ways of working in our heads, or even to broach the conversation in the first place.

You might only want to include a handful of points in your readme. Or you might want to codify your way of working more formally, especially if you have many people reporting into you, such as Oren Ellenbogen’s excellent resource Manager Readme. Whatever your preference, surely having this written-down and accessible can only be a benefit?

Well, to an extent. In the interests of balance, here’s an article from James Stanier on his challenges and concerns when it came to penning a readme for his direction reports. Specifically, as a servant-leader, the responsibility should be on him as a manager to adapt to his reports’ working styles, rather than asking all of them to bend to his whim. In the end, James’s readme is literally a single line:

I’m here to help you succeed. Let’s talk about anything on your mind at any time.

What should go in a Readme?

If you’re wanting do codify some of your working preferences, here are the headings that Simon recommended:

• How best to communicate with me: Preferred methods, particularly what’s the best way to grab attention if something is urgent.
• How to book a meeting with me: Preferred days/times, preferred notice periods, etc.
• Icebreaker topics: Things which interest you which can get the conversation going.
• What makes me tick: How you do your best work.
• What quirks do I have which you should be aware of?: Things which people might find unusual, or might not have encountered when working with others. (Note from Hiba Amin’s “The pros and cons of manager READMEs”, that “quirks” shouldn’t be an excuse to always behave this way - you should be actively working to improve them.)
• Things that frustrate me: What should people avoid when communicating with you.

For transparency, you can click here to view my Readme for inspiration. It’s a living document, as I may discover new things that I want to highlight (or learn about things which are so ingrained in company culture that they don’t require calling-out). I’d be delighted if you bookmarked it, or if you took inspiration and created your own.

Key takeaways 📝

• It’s easy to accidentally commit perceived micro-aggressions when communicating.
• Removing ambiguity can help to improve relationships.
• Try to keep your readme brief, for readability and maintainability.