When Letting It Go Is a Matter of Identity
17 December, 2020
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Vadim Antonov, Engineering Manager at Meta, details his process of implementing an organized execution system for his cross-functional team.
Engineering Manager at Facebook
Andrew Tsui, a Product Leader, works to build great teams that are independent, demonstrate mastery of their domain, and fully commit to their purpose.
Director of Product at Startup
Neelima Annam, Sr Director Information Technology at Outmatch, shares her insight into her growth path of evolving her management style to build trust.
Sr. Director Information Technology at Outmatch HCM
Luis Villegas, Chief Technology Officer at Bungie, speaks on his experience working through the career ladder into an executive position.
Chief Technology Officer at Bungie
Joey Lei, Principal Product Manager at Kasten, contributes his experience transitioning from an engineer to a Product Manager and gaining direct experience.
Principal Product Manager at Kasten
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.