You may be familiar with the concept of a Manager README, but for those not: a manager's README explains the manager's philosophy, working style, and personal quirks to their team. I believe Roy Rapoport started the practice at Netflix in 2016, and since then it's become quite common. This document, my manager README, endeavors to explain those things with respect to me.
My view of our team's relationship with the company is that the company turns our work into money (and resources), and we turn the company's money (and resources) into more work: an efficient machine. My philosophy on engineering managers is that they're the interface between the company and the team. The company goes through the manager to get the work it needs from the team, and you can use your manager to get what you need from the company.
I hope to do a lot for this team, but three main categories stand out:
- Help you use the company to grow and sustain your career
- Get resources for your projects
- Keep the backlog manageable
For the first, I plan to ask all of you regularly what you want in your career so I can try to get that for you. This may be promotion (on which I elaborate below), but it may also be specific types of projects, learning opportunities, working arrangements, etc. If you don't know what you want, I plan to lay out some options and ask for your consideration. I view this as one of the most important parts of 1:1s, and I want everyone to feel like they're growing by working here.
The second and the third are closely related. The second refers to internal resources like information, meetings, and cross-org decisions, as well as external resources like software licenses and subscriptions, books and courses, conference tickets, connections with outside experts, etc. If the company, or anyone at the company, has access to any of these and they would help, I can try and go get them. The third category refers specifically to time; engineers need to finish projects both to advance and to achieve a sense of purpose1. I want to create time for us to finish projects without working long hours by keeping the list of projects short and consistent, and by cancelling projects that shouldn't be on it.
The rest of the company does depend on us to turn its money into work. The more of this we can do for the company, the more the company can do for us. To this end, my responsibility is basically "given a goal, get a good plan for achieving the goal and defend the plan from distractions until the engineers have had time to finish it". Whole sections of bookstores are dedicated to what characterizes "a good plan", and determining one will often be part of our engineering purview, but just so you know what to expect, I'll be looking specifically to:
- Maintain good teamwork, and specifically, establish unambiguous, transparent ownership2.
- This is perhaps the most important single responsibility of a manager, and it's the one that I'm most excited about. Everybody on the team should know what the goal is, the plan for accomplishing it, everybody's position on the field, and how each position contributes.
- Reduce risk, get feedback:
- We'll plan to finish projects way ahead of when they're needed. Some risks can't be anticipated: we possess bounded cognition and finite information. This way, when our plan breaks down for reasons we didn't see coming, we might still finish on time.
- We'll build lots of prototypes early and use them to validate our strategy. I want to apply an enlightened understanding of technical risk (will this design work?) and product risk (will people like this?), and I want us to build MVPs, demos, and spikes, even if the only deliverable is more confidence. I plan to continue the Integrations team's experimental, confirmation-driven style, and I expect us to always seek empirical validation as early as possible. This way, when our experiments don't work, we can switch plans after building only 20% of the wrong thing instead of 95% of the wrong thing.
- Keep the backlog manageable
- This one shows up twice because it goes both ways. The company needs to reasonably limit what we're expected to do, and we need to give those problems due attention, even if we see other exciting opportunities.
This works the same way as everything else, but it's often the main thing people associate with their manager, so it gets its own section.
At any functional organization, managers don't promote based on how much they like you. They do it based on how well you're doing the kinds of things that the company wants to promote. In fact, at both of my past companies (Google and Pachyderm), managers didn't directly promote reports on their teams at all: promotion was an org-wide decision made by committee. The most managers could do was help their reports understand what the committee was looking for and assist their reports in trying to do those things. At both companies, getting your reports promoted is considered an accomplishment for the manager as well as the report.
All this is a microcosm of the manager's general role: when a report is promoted, it means that the company is getting more of what it needs from the person, and that the person is getting more of what they need from the company (more money, usually). If your goal is to get promoted, I will do my best to explain what the company is looking for from you and help you find a way to deliver that.
Finally, in the opposite direction: I spent the beginning of my career very worried about whether I was doing an adequate job. I want to reassure everyone that I would seek total transparency if any performance issues arose, and I'm always happy to reassure anyone who's worried about where they stand. Good feedback requires psychological safety, so I want to arm everyone with confidence.
I put "good teamwork" in the Company bucket because we can't deliver if the team is disorganized, but really, good teamwork serves us too, and connects the two sides of my job. When things are going well, here's what can happen: because we all have the same goal, everybody will understand each other's work (unlike, say, most grad students). But because everybody is in a different position and has a different perspective on our team's goals, each person can give unique feedback on how to improve as a team. Great teamwork is hard to precipitate, but I've experienced it, and when you do, it's transcendent. On a great team, everybody improves more, and faster, as an engineer than they ever could on their own.
As you work to improve as an engineer and advance your career, don't only seek feedback from me: I can explain the company's engineering ladder and try to get you new or bigger responsibilities from the company, but figuring out how to do the best work possible is everyone's purview. I will certainly seek and welcome personal and team-wide feedback from everyone else.
Footnotes
-
I had a very formative experience with this early in my career. I inherited a deprecated but widely-used service, and its users' ad-hoc demands quickly consumed all of my time. I worked totally unsustainable hours trying to finish anything at all before the next emergency, and I mostly failed, and users were always mad about stuff not getting done. I thought I was just a bad engineer, but eventually I got a new TL who figured out what was happening and started pushing back on those users, and my quality-of-life and self-confidence both improved dramatically. Avery Pennarun (eng. manager and founder of Tailscale) gave a great talk with an accompanying (long) blog post about this, and there's a less serious but still compelling reddit story to this end too. ↩
-
Code ownership and, more generally, decision ownership is central to how I think about management. I've written a doc on it as well ↩