Becoming a manager

I've been working as a manager for software engineers since March 2020. Before that I had been a software engineer. As a software engineer, it's pretty clear what your supposed to be doing. At my company, like many others, I would get a set of tasks (tickets) every two weeks and I just did whatever the ticket said to do, and tried to get them all done within those two weeks. As an engineer, if you're getting your tickets done on time, writing good code, helping your teammates, going to meetings on time, and responding to email/Slack, you're probably doing a pretty good job.

But when I became a manager, I no longer had any tickets that I needed to complete and I stopped writing code. I was still going to meetings (except more meetings now) and responding to email/Slack, but I wasn't sure what I was supposed to be doing between my meetings. I felt guilty about these lulls because I wasn't used to sitting around doing nothing, waiting for something to happen.

I also wasn't sure how I was supposed to know if I was doing a good job as a manager. Someone told me that if my team is performing well, then that meant I was doing a good job. But when I joined my team they didn't have a manager and they seemed to be doing a pretty good job on their own before I got there. So even if the team is performing well, how much credit can I really take for that?

Building a car

Now that I've been a manager for a year, I feel like I have a better handle on what I'm supposed to be doing and what makes a good manager.

I came up with an analogy: the job of a manager is to build the best possible self-driving car. The car is your team and the destination is whatever your team's goal is (e.g., completing tickets). And like driving, getting there faster is usually better.

To explain, I'll apply this to my own job. I manage a team of eleven engineers. We get a continuous stream of tickets that we need to complete. The tickets are created by customer-facing employees at my company, and often have a deadline associated with them. The goal of my team is to complete all of the tickets we get before their deadline. I also impose the additional restriction that no one on the team is allowed to work more than 8 hours a day, Monday - Friday.

So phrasing this in terms of my analogy, the destination of the car is getting all of the tickets done on time and if we can get tickets done faster (drive faster), that's even better because it means we can start working on the next thing sooner and increase customer satisfaction.

Making it self-driving

So that explains the "car" part of the analogy, but what about the "self-driving" part? Well, the driver is whatever is steering the car, and steering in my analogy is making any kind of decision.

Here's an example of a common decision we need to make on my team: we have two tickets both due tomorrow, which one should we do or do first? Doing Ticket A first is like steering to the left and doing Ticket B first is like steering to the right.

If you think your job as a manager is to drive the car, every time one of these decision points comes up, the team will ask you what to do and you'll have to make that decision. But if you view your job as building as self-driving car, you'll understand that your job is not to make these decisions yourself, but to provide a framework that your team can use to make these decisions themselves.

If you're making lots of decisions for your team all the time, you're going to burn out, get decision fatigue and eventually start making decisions arbitrarily. Also, if you're making decisions yourself you open yourself up to questions of why you decided that way in a certain situation. If you can't give a good reason for why you made that decision, that's a bad look.

It's much better to create a decision framework that your team can use to make these decisions for themselves. Write your framework down and make every new member of the team read it when they start. If anyone outside the team asks why your team took a certain path, just send them that document. And if a situation comes up that your framework doesn't cover (you hit a pothole), make a decision to unblock your team member and then update the written framework so everyone knows how to deal with that situation if it comes up again.

In the current reality of self-driving cars there's always a human driver behind the wheel. The car does 99% of the driving, but if the car does the wrong thing or the driver can tell that the car is about to do the wrong thing, the driver will grab the wheel and course-correct. Self-driving car companies call these events "interventions" and their success metric is minimizing the number of these interventions.

As a manager, you have the same goal. Every time you need to answer a question or tell one of your team members to do a specific thing, that's an intervention. If you can fall asleep in the back of your car (go on vacation for 2 weeks) and get to your destination safely and on time, you're doing a great job as a manager. So if your team is doing well without any input from you and you find yourself sitting around between meetings without anything to do, great job! That just means you built a really good self-driving car that can handle the curves in the road without your constant attention.

The last part of this analogy is that you need to make sure your team is working sustainably and no one is burning out. You wouldn't want to overrev your car and burn your engine out (Note: I have no idea how cars work). To do that, you need to set clear limits on the maximum you expect your team to work and make it clear that they are never to exceed those limits unless there's an exceptional situation and you specifically ask them to work extra hours (and no one is allowed to ask them to do that besides you). Connecting it back to my analogy, this is like setting a max RPM on the car that can only be exceeded via a manual override.

If you're a new manager, good luck! Thanks for reading.