Where I failed running the first team

While I was responsible and perceived as a team lead by many, that was never formalized. I stepped into the role after the previous lead who was also the most senior person in the team went into higher leadership. This made it very hard to delegate. There are tasks that are easy to delegate, someone (or even many) volunteers to do it, either because they find it interesting or they find it as something in their area of expertise. But there are tasks that are hard to delegate, often not so interesting, usually something that interrupts planned deliverables. Instead of assigning a task as I do now, I was asking out loud who has the bandwidth to do this and way too often assigning the task to myself. My authority came only from my knowledge of the product. I tend to overanalyze different scenarios in my head, and the obvious one here was what if someone says no when I tell them to do something. It took a while before I made progress on this problem, I don’t think I was prioritizing it correctly, and in the meantime, I was doing way too many things.

If you are unable to delegate, that needs to be the first problem you focus on.

Around the time I started, the whole product was focused on stability and we were introducing many metrics, monitoring, and processes to improve stability. My team owned older products and architecture was (and still is) more complex so we were struggling to use infrastructure that other parts of the product got out of the box. As the acceptable bar for stability kept increasing, we were failing to catch up. The bar for what is considered an incident kept getting lower and we started having more and more incidents. I became a regular guest at incident reviews and I saw it as my failure. I felt like I was being under attack frequently and this was draining my energy. But it was all in my head…

If people are pointing out issues in your product, it’s because they care and you should learn to leverage that. Everyone is almost always trying to help.

Once people learn you are a go-to person for a given product, you are exposed to a lot of requests (think problems, features, improvements). You start realizing there are way more problems than you saw before. I thought that everyone deserves a response and in order to give it, I had to understand the request in-depth. This was extremely expensive and I started struggling to catch up. And what do you do in that case? I just started working more.

You don’t have to and you should not attempt to solve all problems because you will fail. You have to understand the request only enough to understand its priority.

When I was offered to take over a new team, I’ve said yes on the spot. There were other reasons, of course, I really liked the products that the team was owning and I was supposed to rebuild the team from scratch in London, but it would be a lie to say that the main reason was not to escape. I tried to help the new lead take over the role quickly, but I failed. I don’t think it was possible, I started to invest in someone to replace me too late.

You need to think about how you are going to make yourself redundant. You usually have to make a bet on someone.