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