To README or Not to README? (Ed Batista)

A few years ago the idea of a "Manager README" surged in popularity before provoking a backlash. The term was adopted from a type of software documentation that attracts attention because the all-caps title stands out in a list of lower-case file names, and I think that's part of the problem--it sounds like a command, when it should really be viewed as an invitation to a conversation.

When clients ask me if they should write one, I note that as with any form of documentation, the value isn't in the document itself, but in the process of creating it and, subsequently, the behavior it motivates. Trevor de Vroome attributes the first Manager README to Luc Levesque, and both of these technology executives make important points about how--and how not--to use such a tool effectively. De Vroome highlights the necessity of reflection and dialogue, dismissing entirely the notion that a manager should simply tell an employee, "Read this, and you'll understand everything you need to know about me":

The Manager README was never a bad idea, it was always just misused. Somewhere along our path, we forgot that introspection is a tool is for you, and not for your team. Sitting down with a Manager README is a great thing to do as a leader to introspect--really reflecting on deep questions like:

Who am I?

What do I value?

What are my commitments to my team and the business?

How do I want others to engage with me?

What are my strengths/weaknesses?

What does my team expect of me?

What do I expect of my team?

However, this needs to be used as a tool to think about expectations. If you need to write this down, then so be it--but we should aim to never provide this information to our team via a document. Instead, for aligning with your team on values and norms, you need a conversation to drive shared understanding. [1]

Levesque didn't even call his document a README--it was "The Blueprint to Luc and His Quirks"--and here, too, I think there's a problem with the nomenclature. It sounds like a manager telling their employees, "I may be difficult to work for, but you're just going to have to get used to me and my unusual ways." But this isn't Levesque's intention--he's sincerely interested in having a candid conversation with each employee about how to work together most effectively:

A few people have asked if I just email the blueprint to the team. No, I don’t. I sit down with everyone on my team, one-on-one, and we talk through the blueprint together. There’s a subtle difference but it’s hugely important. By talking through the blueprint, face-to-face, it gives me the chance to answer questions, add context and refine the message specifically for that individual. I find it’s the discussion that the blueprint facilitates that’s most valuable. In fact, simply emailing the blueprint to your team might actually cause more harm than good because it’s possible that the intent is misinterpreted. [2, emphasis mine]

But even with these caveats, the concept of a Manager README can be highly problematic, and in a thorough critique senior engineering leader Camille Fournier declared that she "hates them." Two unavoidable issues that Fournier highlights are our overall lack of self-awareness and the power differential between a manager and an employee:

There's this idea that you can build trust with this exercise, and you do that by being brutally honest about your own flaws, your values, and the behaviors they should expect from you. That is where I really take issue with this process. First of all, be real: you probably do not know yourself as well as you think you know yourself... If you’ve gone through any deep coaching, self-awareness practice, or therapy, what you learn over time is how hard it is to be 100% honest about yourself and your motivations. If you’ve gone through very little of that, well, you are almost certainly in deep denial about your behaviors and how well they actually reflect your conscious beliefs...

I believe many people who are doing this are really trying to do the right thing. I see your good intentions. But good intentions don't just magically make bad ideas turn good. Everyone writing one of these is trying to make it easier for their teams to work for them. But the unintended consequences of these docs given the power differential between you and the people on your team are real and serious. [3]

So, to README or not to README? One thing is clear: If you're envisioning an employee sitting deep in thought absorbing your Manager README, like the person at left above, emerging ready to work with you in perfect harmony, you're delusional. Instead, look to the conversation on the right--if you can be mindful of the caveats discussed here, there may be value in creating such a document for the purposes of introspection and an ongoing dialogue with your employees. Here are some further points to bear in mind:

A Manager README is no substitute for a feedback-rich culture--and in the absence of such a culture it may even be counter-productive, signaling to employees that their input on your inevitable blind spots as well as your performance as a manager is unwelcome.
The use of a README without carefully attending to the power differential between you and your employees can inhibit psychological safety. The mere existence of such a document doesn't necessarily create a less-safe environment--the impact stems from how it is employed.
The purpose of any such document is a clearer understanding of work style differences, and that needs to be a two-way street. Expecting employees to conform to your preferences without making an effort to understand and adapt to theirs isn't management, it's coercion.