Learning to Let Go of What Made Me Valuable

Early in my career, my value felt pretty straightforward. I needed to be the person who solves things fast. If something looked complicated, I’d take it. If a ticket was stuck, I’d jump in. If a PR needed “a small fix,” I’d usually just make the change instead of going back and forth. It worked. Things moved. Seniors trusted me. I became the person who could be counted on when it mattered. And somewhere along the way, I started needing that to be true.

The Bottleneck I Didn’t Notice

Overtime, something changed. The tougher pieces somehow kept landing with me. PRs would sit until I reviewed them. Design decisions waited for my opinion before moving ahead. No one formally decided this. It just became the pattern. If something felt risky or unclear, it found its way to me.

At first, I didn’t question it. It even felt like growth. Being needed is flattering. Being trusted feels earned. My day would start with quick syncs, then reviews, then helping someone think through an approach, then fixing a “small thing” so we didn’t lose time. Hours would go by in the name of unblocking. By the time I returned to my own tickets, most of my energy was already spent. I was moving the team forward, but I was also slowly stretching myself thin.

It took me a while to see what was happening. I thought I was scaling my impact because more things were moving through me. In reality, I was becoming the bottleneck. If I was in back-to-back meetings, decisions waited. If I planned to take leave, I would prepare detailed lists for each team member covering what to pick up, what to watch out for, what could go wrong, and how to prioritize. I told myself I was being responsible. But underneath that, the team wasn’t truly independent. They were capable, but not self-sufficient without me in the loop. What felt like leadership was quietly turning into control.

Letting Go of the Identity

The harder part to admit was why I kept doing it. I told myself it was about quality and timelines, and partly it was. I cared about both. But there was something else underneath. I liked being the go-to person. I liked that things moved when I stepped in. It reinforced an identity I had built over years, the one who delivers and does not let things slip. Stepping back did not just feel risky for the project. It felt like stepping away from the one thing I knew I was good at. It felt like becoming less relevant. Almost like I was slowly making myself optional.

The turning point was not a single event. It was the realization that I could not keep operating this way and still grow. I was deeply involved in everything, but I was not building anything that could run without me. I could not step away without progress becoming fragile. I had built reliability, but I had not built resilience in the team.

There is a line from the movie Yeh Jawaani Hai Deewani: “Kahin pe pahunchne ke liye kahin se nikalna bahut zaroori hota hai.” (To reach somewhere you need to leave something behind.) For me, that meant letting go of the version of myself that solved everything first.

Changing the System, Not Just Myself

I started changing small things. When a team member came to me with a problem, I tried not to answer immediately. Instead of suggesting a solution upfront, I would ask what options they had considered. Instead of fixing a PR myself, I would leave comments and let them rework it. When decisions felt ambiguous, I would ask someone else to draft the proposal and walk the team through their thinking before I added mine.

One of the more visible structural changes was how we approached reviews. I mentored a few engineers to start reviewing PRs for junior members in the team, while I continued reviewing their PRs. For critical features, I made it explicit that they would do the first review and I would step in for the final pass after their feedback and fixes. Those critical features and their PRs became mentoring opportunities. We would discuss trade-offs, edge cases, and design choices before merging.

It slowed things down initially, but it raised the bar across the team.

It was uncomfortable. There were moments when it felt like I was holding back rather than helping, and I wondered if I was actually adding value. But I was trying to create space between the problem and my instinct to solve it.

Gradually, things changed. Conversations became less about “what should we do?” and more about “here’s what I’m thinking.” PRs came in with better context. A few engineers who initially hesitated started reviewing confidently on their own. Decisions were not waiting for me in the same way. Things were not perfect. There were many mistakes and a few visible drops along the way. Still, the team was thinking more independently.

Scaling Beyond Myself

The real shift became visible when I noticed what I could take on. As fewer PRs required my direct review and teams began owning daily delivery, my time opened up in ways I hadn’t experienced before. I was no longer spending most of my energy unblocking execution. Instead, I could focus more on customer satisfaction and overall outcomes.

That space allowed me to step into additional tracks within the same project and eventually handle multiple projects in parallel. But more importantly, my scope changed. I began driving quality practices across teams, introducing clearer quality gates, and initiating process improvements that reduced recurring issues. Instead of asking, “How do we fix this?” I started asking, “Why does this category of issue exist in the first place?”

Over time, my focus shifted from reviewing outputs to designing guardrails. The goal was no longer to catch mistakes at the end, but to prevent them earlier through better systems and shared standards. The capacity I had earlier spent on unblocking was now available for broader ownership. I had finally stepped out of the trap I built for myself and reached somewhere new.

I still value speed. That has not changed. But I no longer see it as the highest form of contribution. Earlier, I measured my impact by how quickly I could solve something. Now I pay more attention to whether the team can think, decide, and move without waiting for me. The goal is not to be the fastest problem-solver in the room. It is to build a room where problems do not wait for you. The shift has been uncomfortable at times, but it has allowed me to grow in ways speed alone never could.