When I first heard of Manager READMEs, I thought they were a great idea.
After all, the goal was to help developers get to know their manager's style, what their manager values, and how best to work with them.
I believe that most programmers have only the vaguest notion what they manager wants, or how they work. I hoped that READMEs would be a step in the right direction.
After reading many of them, I’ve changed my mind. I hate them.
Let me be clear — I think that the managers who write them are trying to do something good. But… it just doesn’t work. At least, not for me.
Here’s why I hate Manager READMEs:
- They feel arrogant. The premise is that someone with power tells someone less powerful how to treat them, what they expect, and how to best work with (for?) them. I’ve yet to hear anyone ask programmers, designers, PMs, or QA folks to write a README. Evidently, it’s only important to know how managers want to be treated. They seem to say “You read my documentation and adjust yourself to fit it. Not the other way around.”
- They feel lazy. I know, managers are very busy. I get it. I’ve been there. Yet their only real job is to lead their team. Seriously, that’s it. Instead of writing a user manual for themselves, they should build strong, professional, bi-directional trust with their team through 1:1s, ad-hoc discussions, and real personal connections. Manager READMEs appear to try and ‘scale’ relationships, but this doesn't work.
- They make the programmers do all the work. Instead of the manager investing themselves into the programmer through time, honesty, and attention, it requires the programmers to shoulder the responsibility to “learn how my boss works.” Not sure why this is bad? See point #1.
- They put the risks on the programmer. If a programmer misinterprets their Manager’s README, who suffers? The programmer does. It’s the programmer who’s in danger of looking stupid, not getting promoted, or maybe getting fired when they screw up. Managers often miss this because they aren’t in danger, even if their README has mistakes.
- They make managers look bad. After reading through a few dozen READMEs today, I came away glad that I didn’t work for many of these managers. I’m sure they meant well, but stating “I expect you to always come prepared for our status meeting, or we’re going to talk about it.” doesn’t inspire confidence. In fact, it makes me want to run away.
- It creates a false sense of “knowing someone”. If I’d read a manager README from my last boss, I would have thought I knew him. But I wouldn’t, not by a long shot. I wouldn’t even really know “about him”, in the same way as reading Bill Gates biography helped me to know Bill Gates. These READMEs appear useful but actually aren’t.
- They are aspirational, not accurate. I regularly ask managers “how would you describe your leadership style”, and they tell me one of two things: Democratic Leader or Servant Leadership. Then I see these managers interact with their team, and they are nothing like that. The problem is these README’s are what people aspire to be, not what they really are. There’s a big difference between how people want to act, and how they really act. Most READMEs make the author look like a saint, when in fact, they simply don’t know themselves very well.
- They are marketing. Servant leadership, democratic leadership, extreme ownership, blah blah blah. 99% of the managers I know haven’t cracked a book on these topics, but have simply read the back cover. It’s too easy in a Manager README to toss out these ideas as though they mean something, when in fact, they only exist to elevate the manager in the eyes of new employees.
- They go out of date quickly, just like documentation. Have you ever found coding docs that were out of date? How did you feel about that? Now imagine that you read your new Manager’s README, only to find out they no longer do things that way. Code documentation is almost always out of date, and this is no different.
- They feel absolute. Many contain statements about how the manager WILL act, or what they DO believe, or what they ALWAYS value. They feel etched in stone tablets. Worse, they leave little room for how to interpret different behavior. Lastly, they rarely provide a safe mechanism for asking questions when the employee is confused.
What to do instead?
You might have figured out that that the part of “Manager READMEs” I object to is the “Manager” part.
So, burn your Manager README, but don’t stop there…
Instead, ask EVERYONE to write a README about themselves!