Back in 2017, I was a year into my second management job and didn’t feel like my onboarding practices were at their best. I’d introduce myself, have a little bit of time with the new person, and then I’d start them on their journey learning about the company, their team, and specific projects. They’d have lots of questions, but they might wait to ask me until our next regularly scheduled meeting. We could go weeks before I even heard some of their low-priority but high-impact questions — the things that are often observed over time, but benefit from explicit discussion. That category of question includes:
- How soon can I take time off?
- When should I start or end my workday?
- How would you like me to communicate status about my projects?
I heard about this “Manager README” thing on the Rands Leadership Slack and thought it could be THE solution to this problem, but in hindsight I don’t think it ever was.
What I’ve actually done in practice since 2017
Whenever a new hire starts, I send them an onboarding document. That used to include a section at the bottom which was the ‘Manager README’ but it also included other important sections:
- A reiteration of the team and role the person was hired into, and how that team fits into the company hierarchy,
- Important people they should get to know, including their onboarding buddy and teammates,
- Links to team documentation and other valuable company information,
- Explicit instructions on how they should focus their time for their first two weeks,
- Explicit expectations of what I will expect them to do as their onboarding progresses (typically at 3 month, 6 month, one year milestones),
- Notes about equipment (especially when working from home), meeting cadence, and any particular e-mails to keep an eye out for.*
*This has become especially crucial when onboarding folks into fully distributed remote teams.
As of 2021, the only “about me” information is pretty sparse
I plan on meeting with you at least weekly, but you should please feel free to reach out with any questions in-between those meetings. Your buddy [redacted] and teammates may be able to help, too. I have two small children and tend to work between 8am and 4pm Pacific Time. I’ll try not to ping you after-hours (I use Slack’s schedule send a lot), but you should feel free to message me whenever is convenient to you and I’ll respond as soon as I’m able (which will probably be around 8am the following morning, if it is after hours for me). If something cannot wait that long, please feel free to call or text me at [redacted].
That’s it!
All of the philosophical stuff in my original Manager README is still true, but I haven’t found that it needs to be said on day one, and it mostly comes through in those first 4 or 5 hours of conversations anyway. My original hypothesis around onboarding was that the two most important things were to share expectations and build trust, and I think my onboarding document did all of that far more completely than the “about me / manager readme” section ever did.
Why I no longer recommend Manager READMEs
There are two pretty good reasons to not use a Manager README, so far as I can tell:
They are unnecessary and irrelevant to solving the original problem.
As someone who often uses more words than they need, deleting sections from documents brings me joy. My onboarding document for a new engineer is around 7 pages; for a new manager, it’s around 11 pages. There’s no room for 2 or 3 pages of Manager README!
They require more self-awareness and iterative editing than most folks will maintain.
Every effective document should serve its purpose and communicate the author’s intent; here’s a brief non-exhaustive checklist of ways a Manager README could fail to be effective.
- Does your README make you appear like someone who is always right and whose reports need to come around to your way of thinking?
- Does your README fail to account for power dynamics and that you haven’t actually built up trust with this person yet?
- Does your README encourage behaviors from your report that won’t be rewarded (by you or your company)?
- Is your README necessary, or will you have an opportunity to communicate its content as your report begins their work?
If you answered yes to any of those questions, you should probably delete your Manager README document (or section in an onboarding document).
Instead, go back to the original value proposition of sharing expectations and building trust, try again, and be sure to test your solution.
You can’t just ask someone if they liked your Manager README because of the power differential between you two. You can ask them what aspects of their onboarding were helpful to their acclimation and focus in on aspects of the documentation you’ve provided them, the meetings you set up for them, etc.
In my case, I found that there was far more value by setting clear expectations about their role, how they should spend their time, and how they would be assessed (at various checkpoints, in relation to their role and level). How did I know? I talk about the onboarding document for each new hire with the rest of the team, and check in with my new hire on the document after they’ve acclimated. Bringing other people into your writing process is the only way to test your communication before it lands, and there’s always room to make improvements for the next person.
I have a Manager README, what should I do now?
You should revisit your onboarding practices and confirm that it’s an essential part of helping your new hire feel welcome and ready to succeed. You’ll need to ask the folks you’ve previously shared it with to know. If it isn’t actually essential, given the numerous ways in which it can distract from your message, delete it! Every word in a document that isn’t helping you could be hurting you, so stay lean!
Matt Newkirk's NotSoSoftware 