On my journey to becoming the CTO at Codelitt, I had the opportunity to experience what I now believe to be the #1 mistake of any new manager. Today I'm going to share one of my biggest failures as a leader and how important the experience was in helping me manage a much larger team today.

The story starts while I was working as a developer on a project with three frontend developers. Since we were such a small team everyone ended up working on all the tasks together, making it pretty simple to get all the work done. Yet, as months went by, we gradually increased the size of the team until one day I woke up and saw that we were suddenly 15 people! Upon realizing that, we started splitting tasks better and were able to build many features at the same time. Unintentionally, we ended up creating a very informal structure where a few people tackled complex tasks and left others with more simple ones. I say unintentionally because that was not the goal, but I dare to say that some engineers, including me, believed that it was a good approach.

This is a story about how a proper system for delegation is not just an option, but a necessity in any project.

In the short term, this approach gave us good results. We'd have the same people maintaining the same features at a good velocity. The small team of engineers with  more experience on the project could pick up difficult tasks and finish them quickly. Our impression was that by leaving the complex tasks to specific developers, we were shielding the new ones from the pressure to deliver. The newcomers could then work on bug fixes and create new (but smaller) features.

Now let's pause here and follow a simple logic flow

  • Complex features take time to review, understand, and solve.
  • A dev with a lot of experience in regularly maintaining complex features will require less time to review, understand, and solve them.
  • Therefore we can safely say that if a dev does not work on complex features, they will require more time and effort to maintain them when compared to those with experience.

Now let's mix this logic with the situation you just saw me describing. Perfect storm right?

As time went by we started moving some of the original developers to lead other projects across the company. Little by little we were setting our own trap and it began to show. One sprint we weren't able to deliver all the features. On another we delivered everything on time but there were a few more bugs than expected. We continued to lean heavily on a few experienced devs to shoulder the challenging problems. As more and more work was bestowed upon them they began to burn out due to the weight of the expectations.

Here relativity plays an interesting role. In the same way that someone inside a boat cannot see themselves moving unless they look outside, suddenly, and conversely, I couldn't see that we weren't moving anymore. We would be putting down fires over and over and trying to keep the application stable while we tried unsuccessfully to add new features.

After a few months, I was the last original developer of the project, and was promoted to be the project leader. Here is where the lesson started taking shape.

We clearly had a knowledge gap. To solve it would require everyone with little to no experience to step up and learn how to maintain a complex architecture. To do that meant that these folks would have to work extra hours to get up to speed.

Instead of stepping back, assessing the situation, and leading my team in addressing this gap, I believed that I couldn't lead and therefore shouldn't do it. I kept repeating to management that we were under a lot of pressure. I tried to shield my team from deadline issues by tackling the tasks myself. I thought to myself, "I have the knowledge to work on any part of the application, therefore I should do it."

During one sprint I found myself with a week's worth of tasks on my plate; it was Thursday evening and I hadn't even started. That day, the reality of my responsibility and the current state of the project all hit me at once. I had full visibility into how the project had been damaged by depriving the team of knowledge and expertise. As the leader, I was tasked with hiring and training new, inexperienced people to handle the complex tasks without decreasing the velocity of the sprint. And despite being experienced in the complex development work myself, I was now acutely aware of the fact that my role meant that I could not help them get the actual programming done.

In that single moment, I realized that, as is true in any leadership position, the quality of my output was graded on the output of my team. I should have had few to no engineering tasks when compared to anyone else on the team: they were the full-time engineers after all. I needed to lead, not code. This may seem like a no-brainer to any experienced leader, however to me, who was not at the time, this was a big deal.

In trying to figure out how to get us out of the position I'd put us in, I found a simple and powerful mantra: empower everyone equally.

Empower everyone equally

The root cause of this entire situation was the lack of empowerment of our team. Allowing specific people to hold all the knowledge created bottlenecks and dependencies. The success of a project should not rely upon the work of a small number of engineers on the team. We shouldn't shield our teammates from complicated work - it weakens them and prevents their growth. When it comes to leading people, we too often accept our reality as "just the way it is". We ignore the fact that human beings are not static ones. Life is about changing - hopefully for the better. It's in our nature to adapt and change.

So, keeping the mantra in mind, we began to empower everyone on our team by teaching them about the complexities of the project. If someone didn't have experience with a piece of the application, then their teammates would spend time explaining (but not doing) the work. Suddenly we started splitting the tasks equally. More and more the team started becoming self-reliant and confident that they could do anything. With this increased confidence came better ways to solve new problems.

I'm not trying to paint the picture that this was an easy change for our team by the way. It was not. This process of keeping everyone informed took time and effort. Almost a year elapsed between the moment we understood the issue and when we fixed it properly. A change like this will cause velocity to be slow initially, but I assure you that it will pay off in the long run. This important lesson is now incorporated into our entire process here at Codelitt. Every new leader that we promote gets to know this story. We empower them with knowledge so that they know the #1 mistake and don't fall victim to it themselves.

If you liked this lesson from our CTO and want to read more from him, check out: