The Hardest, Shortest, Lesson Becoming a Manager

There’s something we all talk about in becoming a manager – and that’s the process of writing less code. We bemoan it because it’s hard to let go of that part of our identity. But also because it’s so quantifiable. Today I wrote X lines of code. Today I deleted Y lines of code. Today I implemented feature Z. Concrete achievements are reassuring. Today I left the codebase better than I found it. Good job.

I too found this a really really difficult thing to let go of. I looked at tempting tasks. A nice feature. A refactoring. And I did not do them. The thing that I have found that helps is framing it as now coding is not the most important thing that I do. But then I get to the end of a day where I did not code, and I ask, how do I know I achieved anything today?

Get Real About Your Schedule

This week is a short one, but still – there was a point in it where I was triple booked. I honestly have no idea how I would cope right now if I didn’t have admin help. Ariel rules my schedule. I just look at it and panic.

Even when I have open time, it’s like 2/3 of a day, half a day. If I have 2/3 as much time of the week that isn’t spoken for by meetings as I did when I was an IC, that doesn’t mean I can write 2/3 as much code. For starters when you code in bits and pieces you spend a lot more time rebasing. Secondly, transition between strategic (what are we doing), coaching (how can I help you) and details (what does this bit of code do) are difficult context switches. And switching in and out of details is the hardest of all.

When a 1:1 starts with someone sharing technical details with me for ~10 minutes it’s my job to help lift them out of those details so we can work on strategy or coaching. That transition is hard. In both directions. I see it being hard on them, and of course it is also hard for me.

I had a manager once who decided he would take on an important component in the app I was tech lead of. He did a half-assed job of it, and it took him ages. In the end, it was a really challenging piece, it ended up being rewritten 3x (2x by me) before we got it to a point where it performed well. How do you tell your manager that they are your #1 risk factor for missing your deadline? How do you tell them they did a bad job and the thing they made doesn’t work?

I forget how I dealt with that – I think I procrastinated on dealing with it and eventually just picked it up and started improving it. I don’t in general believe we learn that much from what not to do, but I won’t inflict that on my team. If I’m trying to write code now, it’s something that me being slow to complete shouldn’t be blocking anyone. Cleanup tasks are a good place to start.

What Makes the Team Better

The truth that all managers must accept is that your job is now to make a group of people more effective, over a longer period than you usually consider as an IC. Even if you are genuinely the best and most effective person to take something on, does this make your team more effective 3 months from now? Unlikely. Instead of investing in someone else having context now, you’re postponing that moment to later, or indefinitely.

And then they will have a fun time untangling your code and it would be great if you were there to talk to, but you’re in a meeting, again.

The sooner you invest the time in coaching people on what you know that they should know the better it will be.

One of my first weeks on the job there was a component that is pretty complex, that I have now built twice. Last time it took me ~1.5 days. I really just wanted to write this code, show everyone that I’m a good engineer, and have that win. But after sleeping on it, I took a deep breath, looked at my schedule, and encouraged someone else to do it instead. Would I have done it faster? Honestly considering my schedule, probably not. And now the person who did write the code is in a good position to own that component going forward.

Does Your Team Need A Manager… or Another Engineer?

As a manager I have this mental list of things about what does my team need. Things that I’m monitoring, things that I’m trying to fix, things that I’m trying to find for them. It’s my job to understand what is going on and what the team as a whole needs to be effective.

Maybe you can look at the state of things and say, we have a deadline right now, and what we need is another engineer for the next month. That engineer is me.

But more likely you look at the state of things and realize that what your team needs is a manager. Because you need to hire X more people. Because Y has a lot of potential but needs some coaching. Because product or design or some other team haven’t given you what you need so you need to go and get it. Because process is important, and the process you have is insufficient or just plain wrong.

If you team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide if you’re going to suck at one which one that will be.

I feel bad when I suck at being an engineer, but sucking at being a manager would be a choice I inflicted on other people. That’s not fair.

So at the end of another day when I feel like I didn’t write enough code and I have no way to quantify what I’ve achieved, I tell myself I was being as good a manager as I know how to be. And that has to be enough for today.