Don’t be in the critical path

When an individual contributor becomes a team lead or manager one of the hardest challenges to overcome is removing yourself from the critical path. I’ve failed at this multiple times but I’ve found that there is a pattern to my failures. They’ve all come from a slow burn rather than trying to take on something large from the get-go.

My biggest failure was becoming the de-facto data analyst after our original data analyst left the company. Don’t get me wrong, I’ve enjoyed learning about the data stack and being part of the data community (shoutout dbt!) for a while now. The failure is that it came at the expense of the time I should have been dedicating to people management.

The seeds

It starts slowly. In my case our data analyst was on vacation and I decided to help out with a few tasks. Slowly those tasks turned into an on-going project because I knew the code the best. I found myself enjoying the work so I didn’t mind when there were additional small tasks added to the project. I didn’t feel like I was in the critical path at first. I would get some of it done in the early mornings or late afternoon and no one ever felt blocked.

For you this might start as a small internal tool or an IT issue. Maybe you’re helping a team that is under-staffed. At this point it might feel nice to contribute code again and you tell yourself it won’t escalate any further.

The turning point

Our data analyst had a few vacations and life events in a row and I found myself as the part-time data analyst. At this point I should have brought other folks into the fold so that they could also do the data work. My responsibility was to be a people manager first and not an IC. If I had trained a few engineers on the data work then I could have taken a step back. That’s what I should have done. What actually happened was that I just took over more and more until it was taking up several days a week.

After a few months our data analyst decided she was going to leave for a different adventure (very excited for her!) and her end date was coming up. At this point I also could have decided to bring more engineers into the process. Instead I decided I would be the data analyst until we could hire a replacement. I felt at the time that if I could do all of the work for a while then I could spare engineering from the extra workload. I also felt guilty to offload this work that I was perfectly capable of doing. Several people warned me against doing this. Their point was that I would burn out and do both jobs badly. They were right. I didn’t listen though.

Crash and burn

So I found myself with no data analyst and all the data work. On top of that I had to hire a new data analyst and be the people manager for the team. I’m honestly shocked I didn’t burn out sooner. I ended up doing a mediocre job at all three tasks. I introduced several avoidable bugs into data that could have been prevented if I had been more focused on just data work. I also neglected part of my people management responsibilities and didn’t prepare as much as I normally would have for 1:1s and other meetings. I’m pretty good at winging it so most of the time I got away with it but there were definitely moments I wish I could do over. There were many opportunities for me to bring in another engineer (or several) to help me out but I stubbornly thought I could handle it.

A really bad side-effect was that I was very lax about how work was prioritized because it was just my work. Normally I do everything I possibly can to protect engineers through a very healthy sprint process. But if it’s just me.. “Sure I can do that this week”!

I distinctly remember the moment I finally realized how bad I had let it get. I was working on a report for some financial work and for the first time in my career I just didn’t test anything. I just shipped it and moved onto the next thing on my list because I was so stressed. I didn’t have an engineering manager to catch me the way I would help my engineers. Well you can guess what happened, right? It obviously broke and I had to fix it a week later when someone discovered my really embarrassing mistake (luckily he was cool about and it didn’t impact too much).

On some level I also enjoyed being the only person working in this repository. It felt like a freedom I had lost when our team had grown. I didn't have code reviews or standards for myself. I occasionally pushed directly to our master branch. I did everything I always preach not to do because I just needed to get the work done as quickly as possible.

A better way

I ultimately started bringing the data work into the regular sprint and having other engineers do the work while I paired with them for training. It was easy for me to give up the systems I knew best and loved working on when I became a manager. It was much harder for me to recognize that I was slowly taking over a critical path as it was happening much farther into my management role. If you are a blocker or resource that is counted on for coding and you put that work ahead of your people then you’re failing.

If I could do it over I would have considered data work the same as product feature work. As often as possible the engineer responsible for the production change would also implement the data change. For projects that didn't have an obvious owner, we would prioritize an engineer's time against the other priorities in the sprint. Ideally this would continue until we hired a full-time data analyst. I believe had I gone this route the team would have understood how their changes to the data model impact our metrics and proposed more robust plans when making data model changes. In a way, I robbed the team of additional training by trying to "spare them". In fact, I wonder how often managers end up keeping engineers from gaining additional skills in a misguided attempt to spare them work.

As I’ve talked to a lot of different companies I see that there are many philosophies for how much code a manager should contribute. I don’t yet have an opinion on volume but I do feel strongly about content. Stick to bugs and small features or projects that don’t have firm deadlines. Try and make sure that at least one other engineer has context on what you’re working on in case you need to hand it off without warning due to your main responsibilities. As a people manager you owe it to your team to always put them first.