README for Humans

(if you don't know what a Manager README is, start here)

Many people find these READMEs useful enough to have taken the time and mental energy to pen them down (checkout the examples here and here). Heck, there's an entire website dedicated to creating and sharing manager READMEs!

On the other hand, many people are not so into it.

First off, I think it's unfortunate that the term "Manager README" has stuck. There's nothing "manager"-specific about them. Like most documents, it's a tool that might work for anyone in a collaborative situation, depending on the context. And README makes it sound like a user manual or entry point for a project's documentation.

For instance, Erica Joy right suggests it is the reports who should be giving their managers a README:

I'll walk through some of the common criticisms and share some tips on how you might go about writing such a doc, should you choose to.

• They're not authentic: as with management books, it's all too easy to end up writing things that sound derivative or "common sense". Just like interviewing managers, it's important to tease out "saying the right thing" from "doing the right thing". Authenticity is easy to demand, and hard to provide: try not to read too many of these before you write your own (just like your college essay!), focus on specifics, give examples. Also consider your audience: if you are a first-time line manager with junior reports, it might actually be useful to let people know what to expect from their manager; on the other hand, if you are a senior leader managing managers, you might expect they know the fundamentals and instead leverage such a doc to focus on your management style / expectations.
• They're a shortcut to build trust: This just seems a misalignment of expectations. Building relationships and trust takes time; you need to show up, consistently, invest the time and mental / emotional energy. Humans are messy and complicated; our brains are great at pattern matching though and always looking for a "narrative" that helps explains the world around us. To the extent these docs can provide that narrative, they can be useful.
• They're primarily self-serving: You can deploy anything in a self-serving, narcissistic manner; that doesn't make it objectively bad. As Camille notes in her criticism, introspecting and reflecting on your leadership skills, articulating your expectations / needs can be a very useful exercise in a therapy / coaching session. IMO the key tension here is when such a doc is made public or shared. After all, why bother writing it if you're not going to share it? Well, just the act of writing the doc might help you better articulate yourself; alternatively, you can pull on specific parts of the doc as needed (like when you take on a new mentee or a new report).
• They're outdated: IMO that's a good problem to have! Unlike documenting software, I think it's easier to identify aspects about human traits (values / personality / preferences) that are relatively stable. And if things do change (as they should, over time!), it hopefully reflects positive growth.

Ultimately, if you have clarity on what you want to get out of a doc like this (whether it's setting expectations for your reports / peers or perhaps just better understanding yourself) and you communicate those goals clearly with the intended audience, write one and see how it works out! I've yet to experience first-hand any situation where someone writing a README for themselves has backfired (not doubting that it can / has happened to others), and generally managers seem to have learned something about themselves in the process.