Skip to main content

Manager README πŸ“–

You can create your own here

I am writing this to help clarify my philosophy and expectations as a manager. Transitioning from an individual contributor (IC) to a manager has been challenging. One thing I’ve learned is that clear expectations provide a strong foundation for a working relationship. Enter the Manager README.

I am writing this with three people in mind. For my direct reports, this document outlines my role, responsibilities, and my expectations. For my peers, this document sheds light on my philosophy of management. For myself, this is an exercise in building clarity. To all three, this is a living document and work in progress. Feedback is encouraged and appreciated!

From here, “you” refers to somebody reporting to me. That said, my personal commitments are not made just to my direct reports.

My role #

My core responsibility as an engineering manager is to grow teama team of software engineers. I use the word β€œgrow” intentionally as it describes both growth in numbers, but also growth in scope and impact.

There are other two other org-wide core priorities: operating a world class service and building a strong business. You and I should always keep these in mind because impact is measured against these priorities.

Microsoft teaches a management framework called “Model, Coach, Care”. This is how I will help you improve as an engineer.

I will model the Microsoft leadership principles and core values. You can expect me to generate energy and build clarity whenever possible. You can also expect a healthy work environment and culture of continuous improvement.

I will coach you through challenges. Concretely this will look like pair programming, design discussions, or my help in facilitating technical discussions with a larger audience. As much as possible, I will work to involve you in the areas you find most rewarding.

I will care about you as an individual, supporting you both personally and professionally. You should expect a weekly 1:1 meeting where no topic is off-limits. In return, I’ll expect your honest feedback.

What do I value most? #

Two phrases I say a lot are “think about X from first principles” and “we must be able to reason about Y”. As an engineer, I demand from myself a deep understanding of a problem and its possible solutions. As a manager, I value those with a similar commitment to understanding.

Extending from this, I value the ability to work independently. While you may not yet feel equipped to tackle ambiguity and drive for results, I’ll help you build the capacity (and network) to do so. You will develop a sense of ownership with respect to the codebase, the product, and our team culture that will continually inform your decision making.

Working independently is not the same as working in isolation. You will develop strong collaboration skills and the intuition to know what it takes to push your work forward. In other words, you will learn when to ask for input from me, input from others, and when to tackle something on your own.

Conflicts will happen and the values outlined above will help resolve them. Decisions are considered from first principles; patterns and conventions are tools, not goals. You can expect me to facilitate diverse and respectful conversations. In return, I’ll expect you to share your ideas and consider the ideas of others.

Personally, I have a few habits that I think reduce my impact as a manager and thus the collective impact of the team. Faced with uncertainty, I sometimes revert to my old IC role, focusing on individual contributions and failing to help move the team forward. I also tend to shield the team from uncertainty. While this if often useful, I’ve had a hard time striking a balance. If you notice any of these things, please don’t hesitate to mention them!

My Expectations #

My expectations are derived, at least in part, from the values described above. In other words, I expect you to be trending towards independent execution, first principles thinking, and a mindset of ownership. Progress may not always be linear. You can expect me to provide feedback and support wherever I’m able to. Please be open and transparent so I can do this effectively!

I am a firm believer in 1) keeping my calendar updated and 2) accepting invites for pair programming, debugging and/or design sessions. This is my favorite way to build rapport with new team members. Please feel free to reserve time on my calendar!

Mistakes will happen and are best resolved sooner rather than later. I am committed to a culture of blameless postmortems and open, transparent communication.

1:1s #

You and I will have a recurring 1:1 meeting each week. I like to schedule these for 25 minutes, though it’s not mandatory that we use all 25 minutes. In fact, you will drive the agenda. You can expect me to be as transparent, honest, and open as I can be. If I am unable to answer a question you have, I’ll write it down and find the answer. Sometimes I may have something to cover, but we will discuss your agenda items first.

Personality quirks #

I tend to crack jokes, and I’ve been accused of being sarcastic at times. I think I have a good read on when (attempted) humor is unproductive. If you feel I’m not being direct, please let me know.

Where to focus on your first 90 days? #

Onboarding can be challenging, and my team is no different. That said, this should help frame your expectations and (hopefully) calm your nerves.

Effective onboarding, for me, encompasses two areas:

  1. The (technical) learning process
  2. Building relationships with your colleagues.

Microsoft aims to measure impact from your individual contributions, your ability to leverage the work of others, and your contributions to others. In other words, success requires technical excellence and working with others.

Here is a rough outline of how to focus your learning efforts in the first few weeks.

  1. If you haven’t worked with some combination of Typescript, React and/or Redux, spend time learning about them
  2. Clone the codebase and get it running on your local machine
  3. Resolve a handful of small(ish) tickets by merging code in the first week or two
  4. Understand the key services/areas and what they are responsible for
  5. Learn the rough system architecture, understanding how user requests are routed through the system
  6. Learn how to query our data warehouse and understand what is logged (and what is explicitly not logged!)

You’ll be assigned an onboarding buddy that can answer questions and help with any technical issues. I will expect you to be proactive in seeking support from me and from your colleagues. I would also encourage you to schedule quick 1:1s with everyone on the team so you can meet people “face-to-face” (whatever form is appropriate given our hybrid workplace arrangement).