When Letting It Go Is a Matter of Identity

Problem

I have always nominally been a CTO but the organization evolved through different stages. Initially, it was only three of us in Engineering and now we are 50+ people dispersed across different departments. At one moment, I realized that I was not able to devote enough time to hiring and building processes because I was continuously going back to coding. Coding was the safe space that I would go back to any time I would face a challenge.

I knew I had to let it go and the time I was spending on coding would be better spent if I focus on scaling the team, growing our leaders, or building up the strategy. This became increasingly burdensome because when I was coding switching context and delving into other activities was taxing. I would be attending a meeting discussing the strategy with the business, but I would be coding in my mind --- I would be thinking about the codebase instead of our product strategy.

Actions taken

I realized that I should focus my energy on higher-impact activities and that it would unconditionally entail letting go of technical hands-on work. But it was easier said than done.

I trusted all the great engineers we hired, but it was more than that for me. Coding was my identity! For almost my entire life coding defined who I was --, I was a developer, and moreover, I was the best developer on the team, and being the best developer made me a CTO. I had to give up something that so strongly shaped my understanding of who I was. Also, I had to let go of my best skills to work on something new, where I felt like a novice.

It was a painful transition. I suddenly felt like I was not able to contribute much. Thankfully, things looked entirely different from the organization’s perspective as compared to how I felt. I was also concerned that my management responsibilities won’t allow me to stay technical. This was also closely tied to my understanding of identity and the legitimacy I gained from my fellow engineers.

I thought that by losing my technical edge the team won’t respect me anymore. But what the team needed at that point was not my technical skill but my guidance. Perhaps, they understood much better than I did that they needed someone who could support them and who they could hold responsible for their technical decisions. Realizing that I made a peace with it. I reframed my situation from “how do you keep an edge” to “how you remain relevant to your team”.

Letting it go was tightly connected with how we hired new people. As a small startup, we would hire people that were similar to us. They would approach problems the same way we would do it. As the team grew, we were joined by people of different backgrounds and personalities and their approach to problems would be immensely different from how I would to it. One of the problems of letting go is acknowledging that almost any problem could be solved in different ways. At first, I was very uncomfortable but I was trying my best to stay away from micromanaging. For a while, I practiced my “angry coding sessions” where I would go through the codebase, find and change things that I thought could be implemented differently. I was not fixing things because there was nothing to be fixed, I was just changing the codebase to my own liking.

Lessons learned

• When we start letting go of things we move into the state where we feel that we don’t know what we were doing. You have to overcome that feeling of uselessness that may get to you once you start taking things off your plate. In fact, now when you are unburdened, you will have more possibilities and responsibilities before you.
• Learn to trust people. If you let go, you let go. If you trust someone and they commit to deliver, you shouldn’t be second-guessing or checking behind their back if they are capable of delivering. If you claim that you trust someone, live up to your words.
• Most first-time managers would experience imposter syndrome. That is usually connected with the feeling of being redundant that often accompanies the delegation. While in fact, delegation happens when you have outgrown your existing responsibilities and are ready to move forward.
• Different people will approach the same problems differently. Don’t project yourself into how other people should deal with it. Especially, restrain from projecting yourself when hiring. Different is not bad, different is different and often good or even better.