Eight Things We Learned From Reading 49 Manager READMEs
I first heard about READMEs through SoapBox customer Heather Foeh, PathFactory’s VP of Customer Experience.
We were talking about her management style, and she mentioned how she gives each new employee a “How to work with me” document.
I was fascinated by the idea and went down a serious rabbit hole of manager READMEs, especially ones from the tech industry. The more I read, the more I found. In this case, READMEs are almost like “how-to guides” for working with a new boss.
We ended up publishing a round-up of 49 manager READMEs that got a lot of love.
Here’s what we learned about READMEs along the way.
1. READMEs are a godsend for remote teams.
With so many companies going entirely remote (or embracing WFH days), it can be a challenge to building relationships.
A lot of READMEs spell out specific strategies to combat this, providing detailed info about where and when they work, what their availability is like and how to get in touch.
A great example of this is Katie Womersley, Director of Engineering at Buffer (an all-remote team). In her README, she encourages her team to over-communicate: “Don’t worry about sending me too many messages or overwhelming me, it’s really valuable, and in our remote context, I’d love to be here for you for what comes up because I can’t see how you’re doing by walking around an office.”
2. Trust is crucial.
Most of the READMEs we looked at said, in some shape or form, “I won’t blindside you.”
Things can change super quickly – especially at the agile tech companies on our list. And along with that comes a fear at the employee level that they’ll be blindsided by major changes, layoffs or something else.
To avoid that fear from fostering, managers need to build trust with their employees from the very start. Hence, why so many READMEs something like this:
“You can ask me anything. The vast majority of the time I’ll answer. Very infrequently, I won’t be able to. But I’m committed to never lie to you.”
That one is from Shopify Senior Developer Lead Ben Morris’s README, but the sentiment came up again and again: I won’t lie to you. I won’t be able to tell you absolutely everything, but I won’t lie.
3. Communication is a unique and personal thing.
This was a fascinating one. Each manager had a very different approach to communication – hence the reason why it pops up in every README in the first place.
Some managers pledge to never email after work hours. Some only email after work hours to avoid interrupting their employees during the workday. Some share their calendars as their bible. Others say to ignore their calendar altogether. It’s so intensely personal, and including details here save new hires hours of struggle trying to figure it out on their own.
Mike Hostetler, Director of Software Engineering at Cars.com, went so far as to include a “response tree” in his README outlining what mode of communication to use with him depending on the level of urgency and required response time. I mean, how amazing is that? How much would you have loved that as a newbie employee starting out at a new company?
4. Direct feedback reigns king.
These managers want to give feedback, and they want to give it right away. Radical Candor gets mentioned so many times, it might as well be the official sponsor of manager READMEs.
The same goes for employees having concerns or questions. The message is always the same: Don’t wait until your performance review! Don’t even wait until your next one-on-one! I. Will. Make. Time. For. You.
Tom Sommer, Director of Engineering at Redbubble is a great example of this. In his README, he explains when to expect feedback: “I will pull you aside after a meeting or any other interaction which warrants either positive or constructive feedback. 1:1’s are not a time I use for giving feedback, as it is often old news by then.”
5. …and one-on-ones are queen.
It’s no secret that we love one-on-ones at SoapBox, so we were thrilled to see that pretty much every manager we read included details on their one-on-ones: how often they have them, what they’re used for, how to document talking points, and so on.
Nailing down these details is crucial because one-on-ones mean many things to many people.
For example, Michael Lopp, VP Engineering at Slack (and pretty much the father of READMEs) specifically notes in his README that one-on-ones are to be used for “topics of substance,” not status updates.
6. Managers are unique human beings.
Ok, this is a little obvious, but so many READMEs included such wonderful idiosyncrasies about their authors that we had to mention it.
Some are fun little icebreakers (like Austin Kelmore’s favourite baked good), and some are extremely personal (like Molly White’s anxiety disorder). And almost all include the quirks that will impact day-to-day work.
A huge number of managers identified as introverts that need time to process new ideas before they’d be ready to discuss in detail. Several mentioned gossip as a trigger. Ben Broeck mentioned never booking meetings on Fridays. These are all extremely valuable pieces of information that would otherwise take weeks or even months for new hires to learn.
7. The best READMEs are incredibly simple.
In reading through so many of these documents, the ones that remain top-of-mind are the ones that kept things extremely simple.
A perfect example of this is Daniel Richnak, Software Dev Manager at Woot. His README is a series of bullets that at times read like a kid’s book (in a good way), with simple, plain language: “Don’t be a jerk. Jerks aren’t fun,” or “Don’t be cute. Value clarity.”
8. Writing a README is more important than sharing it.
Going through all 49 manager READMEs, it struck us again and again how incredibly reflective you need to be in order to write one.
Yes, you need to know your management style and communication preferences. Yes, you need to know what your job is, what you expect from your team and what they should expect from you.
But you also need to know what things you do that tend to irk other people; what communication gaffes you’re prone to make; what sets you off (what Roy Rapoport, director at Slack, calls “known failure modes”). This stuff is hard to spell out. But the results are win-win – you become more self-aware, and your team has the intel it needs to connect with you on a deeper level.
If nothing else, maybe it’s this last lesson that will get you to sit down and start writing your own README.
It certainly was the case for me. Stay tuned for the finished product.
Brennan McEachran is the co-founder and CEO of SoapBox.
