If you are reading this, you were probably given a link by me. This is my “Manager README.” The concept of such a thing was borne out of Software Lead Weekly, a great newsletter about leadership in software. The first thing I guess you should know about me is that I’m the type of person that writes a README.
How to Use This
This document is designed to reduce some of the ambiguity of our working relationship. As our team grows and changes, we may have more or less time to spend together. This document is meant to fill in the gaps and accelerate our working relationship.
At the time of writing, I’m a People Empowerer of an engineering team on the Payroll mission at Gusto. If you’re trying to map this to nomenclature found in the wild: a line engineering manager within the payroll engineering department. The team I empower is Running Payroll. We are a critical piece to Gusto’s continued operation and its future.
As a manager, it’s my responsibility to give you everything you need to succeed: space, security, faciliating trust of your teammates, tools. From there, I get out of the way.
- Generally I follow the advice of High Output Management. It’s a great book by Andy Grove, a former CEO of Intel. The rough sketch of the book is as follows: in creative organizations (like those that build software), the most knowledge of what is actually going on will be held by those closest to the work. Thus, rather than a command-and-control method of organization, your managers are listeners and editors. It is their job to listen and guide the organization, based primarily on the input of those doing the real work.
- I prefer iterative improvement over big rewrites, in almost all professional scenarios. I try to capture some of this in my blog post, The Teeth. I will push you to break down work and answer the question, “Can we deliver something of smaller value sooner?”
- Feel free to interrupt me at any time via Slack or email. I’ll try to respond immediately or will let you know of a time to expect a response. I am here for you.
- When it comes to mistakes, what’s the best way for employees to come forward? How do you define “Done”? When should people be available and how? (e.g. work hours, availability via chat/phone etc.)
- Expect to do a weekly or bi-weekly 1x1 (“one on one”). We’ll try to keep the times consistent so that we have a regular cadence. We’ll use a joint Google Doc to keep track of discussion items, action items, and more. It’s also pretty neat to have a digital representation of our relationship over time.
- I view 1x1s as one of the most important parts of our working relationship. It’s a safe space to catch up and have conversations outside of the work product itself.
- 1x1s are your time. We can spend it however you want, but we will spend it together.
- I will sometimes speak having made a few logical leaps, which can be confusing. Feel free to ask me to slow down and explain my reasoning.
- I can be a purist, which can be difficult to work with. Usually this will surface in a discussion around an acceptable level of quality in software. These things are not something I cannot compromise on, but rather just an opening bid. Please push back.