Writing my Manager README

I’ve always liked Oren Ellenbogen’s idea of having a Manager README or a document similar to what Michael Lopp displays on his site. After some time, I finally wrote something and shared it internally, and I’ve now decided to make it public.

If you’re wondering what this is all about, why I think it’s useful and how I wrote mine, keep reading. If you just want to read the document itself, you can click here and check it out now.

What Is a Manager README?

A manager README is a document that a manager can give to their direct reports to help kickstart the working relationship. This is by no means a replacement for actually learning about the other person, or a way of avoiding discussions. It’s just a solution for speeding things up and making them more intentional.

The content itself is free-form, but often showcases what the manager values, what their expectations are going to be or how they prefer to communicate. Personally, I don’t consider the format to be of great importance. I’ve seen everything ranging from slides to Google Docs, and even dedicated websites.

Finally, I think that any good manager README needs to be a living document. I’m sure that mine won’t look the same in a few years, so it’s important to keep it up to date and to make sure your readers keep challenging the content.

Why Write One?

This document is supposed to help with a few things, including faster onboarding and public visibility over your management style. Personally, I decided to actually sit down and write one for a few reasons.

Firstly, I greatly prefer explicit communication over implicit communication. If I’m your manager, I know that I will have a significant impact on your life at work and your ability to succeed professionally. Because of this, I don’t want my personality quirks to get in your way. If we are going to work together for a while, I’d much rather show you right away how I usually do things. You’ll quickly know where I stand, and we can debate what we disagree on. Being more explicit will also save you the effort of guessing what I’m thinking or what I’m expecting from you.

Secondly,  the exercise of writing a README document is really engaging in itself. Spending a few hours on this document forces you to really think about how you work. It is a great opportunity to challenge whether your behaviour really does match your values. It’s easy to say: “I value work/life balance”, but do you really? Do you have examples where you’ve showcased this?

On top of this, once the document is shared, it makes you accountable to what you wrote. The README is the way I intend to operate but, being human and all, I will most likely deviate and make various mistakes. This is why mine starts by:

If you see a discrepancy between this document and my behaviour, please tell me.

Finally, I think that publicising this document should help future people working in my team, or future employers, know what kind of a manager I am. This way, if there is any disagreement on some fundamental matter, all parties involved can avoid painful months that usually conclude by someone terminating the working relationship.

Limitations

Personally I consider my Manager README as an additional tool I can use to lead my team. It’s just like one on ones, performance reviews, staff meetings and so on. Like any tool, it can’t do everything, has its limitations and can produce more harm than good when used poorly. For instance 1:1s are often considered a must have, but if you only use them to get a status report, you are not really building relationships.

First, writting this document is not an alternative to actually talking and listening to your people. It can speed up some things, but it shouldn’t replace being there for each individual in your team and act in an reliable manner day after day. Writing “I am available for the team” is a good start, but actually being available is what you need to do.

Another issue is that being vocal your issues is not an excuse to avoid working on self improvement, and does not absolve you of any bad behavior. Just because you let people know you would misbehave doesn’t make it ok. It’s also worth noting that as a manager, you must assume that the power dynamic will make it that people will have trouble calling you out when you do it.

On the content side, I think it’s a given no one really know themselves perfectly, me included. Because of this fact, the README will have flaws and points that are just not true. While this is acurrate, the document has to only one piece of the working relationship between the manager and their reports. As trust builds during the years spent working together, the people in the team should be able to challenge the manager more and bring the document closer and closer to reality. This, of course, requires the manager to be open to criticism and have a willingness to improve themselves.

How I Wrote Mine

To start, I decided to make something that is greatly applicable to my current job, but which can still be read and and make sense to someone outside of my company. Some parts, including the work-from-home policy and certain tools, are specific to my company, but I think the README still gives the general intent.

Then I tried to strike a balance between theoretical ideas, like the qualities I value, and really practical things such as the best way to reach me.

Once I was done with the first draft, I sent it to a few people who had worked with me for a while to get their opinion, and changed a couple of things based on their feedback.

Finally, I shared it with my direct reports and some other managers who were curious. Now, I only update the content every couple of months, depending on what I’ve learned, the feedback I get and how my view on the points in question evolves.