The 7 most important aspects of my Manager README

A little while ago, I began managing a new team with a bunch of new team members reporting in to me. In order to help get them to know me better and understand the way I work, I decided to write a manager README. Inspired by some great engineering leadership READMEs I found online, I noted down my own values, priorities, and way of doing things so that my new team could quickly get a better understanding of me. Reviewing it with several folks in person, the feedback I received on it was phenomenal.

You can find it here

I took inspiration from several great manager READMEs I found from this post and decided to write my own to help my new team get to know me. I decided to put mine up on Github where it would not only be public, but others could even make pull requests if they had feedback. Other managers who liked the format could also fork it for their own. Plus, it felt just nerdy and cool enough to represent my own style. I felt like having it on Github would both force me to be honest and transparent as well as demonstrate my proclivity for transparency and openness.

There were a few common themes and topics I noted as I reviewed some of the stronger ones. These tended to break down into the following areas.

Make it personal

This document can become very dull and dry without some personality. I chose to express who I am, what I value, and how I like to operate throughout the document. Others also let their personality shine through either implicitly through the tone and focus, or explicitly by discussing personal values and even their personal life. This matters a lot to me and I like to get a sense of understanding my own team members’ personal values too, so I felt purposefully including this was a necessity. I even added a section toward the bottom on what I do when not at work hoping that this would demonstrate my personal belief in having a strong personal life outside of work.

Explain what and why

This document isn’t a normal practice across the industry yet, and most people haven’t seen something like it from their leaders before. It’s a bit odd to out this all down in writing, but is something I think is extremely valuable in setting expectations for a team, especially a new one. It’s absolutely critical to start off with why this document was created and what readers should get out of it to explain why they should bother reading on. It’s also a great idea to review this and the context for the document in initial one-on-ones with team members.

Goals

While I didn’t see it in every README, I liked the ones that explicitly outlined measurable and actionable goals the manager places on themselves for how they measure their success with the team. I included goals for increasing the technical knowledge and productivity of the team while ensuring I provide resources for growth and development. Above all else, I measure success by ensuring that team members are actually happy. If I fail this, nothing else matters. This document explicitly states this and makes sure my team members know what they should also evaluate me on.

How I view my role and responsibilities

Forming the bulk of the document is an overview of how the manager views their own role and responsibilities. Many note that while they spend much of their time in meetings and managing projects, their own personal top priority is their people and so supporting this will always come first. As a manager, it can be hard to find this balance so it’s important to outline both the manager’s role in this as well as their expectations for how individuals will help ensure this is happening. I explain in mine that while I’m often not at my desk due to meetings, I will always bump things for urgent and important issues that arise on the team or for team members individually. But, I also expect team members to be proactive in letting me know what they need and if they are receiving what they expect as the proper level of support.

Running One-on-Ones

Essentially every README I read took the time to discuss One-on-Ones as one of the most important activities they participate in. I outlined why I have One-on-Ones, that they should focus on development and growth, not just project status as there are other forums for that, and most importantly, that the individual owns this meeting and the agenda. If they don’t bring anything to the meeting, I will set it, but it’s their time to cover the things that matter to them, not the other way around. I also gave some resources for good posts about how to get the most out of One-on-Ones and make them productive since this is a skill many individuals want to improve.

Receiving and delivering feedback

Another important aspect of the document is to outline how the manager prefers to give feedback. Some use graded scales while others use a color coded system. To me, the system was less important that the expectation that feedback will be given, that it should never be heard for the first time in a formal review, and that I prefer to give it in realtime when possible. Equally if not more important is that feedback needs to go two ways and the doc should outline how the manager wishes to receive feedback as well. For me, I expect the same level of honesty as I promise to provide, and also want it in realtime so I can adjust rather than hearing it later. It’s also important to focus on the amount of feedback as well and ensure individuals feel empowered to discuss whether they need more or less feedback.

Why my calendar is a nightmare but you shouldn’t worry

Nearly every README I read discussed how terrible every manager’s calendar is and not to be intimidated by it. I guess I’m not the only one in this state. My own doc clarifies that while my calendar always looks impossible to find time on, it’s often possible to either move things around or otherwise make time for people. To me and from what I can tell of these other managers, making sure their people have the right level of support is the highest priority, so bumping other meetings is always a possibility. Unfortunately this isn’t possible 100% of the time, so the doc also sets this expectation and how to handle it. It also defines how to escalate when there’s an issue and how to get a quick response. It also sets my expectation that while I might sometimes send a message at night or on weekends, that’s my own choice to use my non-work time that way, and I don’t usually expect an immediate reply unless I explicitly say so.

After discovering that many effective leaders have created these READMEs for themselves, I fell in love with the idea. I feel like this document is a perfect mechanism to set expectations with a new team, or even clarify things with an existing one and also to build stronger relationships with team members. For me especially with several new team members at once, it was a perfect opportunity to clarify my own priorities and expectations. The act of writing the document even helped me clarify some of these to myself. I think it’s a phenomenal idea and one all leaders should take. So feel free to fork mine or send me a pull request so that we can improve the engineering leadership community together!