The Hidden Cost of Being Everyone's Go-To Person

Why being indispensable was impacting the whole team

Managing multiple teams for different projects in parallel taught me that my biggest strength was slowly becoming my team's biggest weakness.

When I first stepped into the Lead Engineer role, I genuinely thought I was doing everything right. Weekly one-to-ones with each engineer across different projects, Teams/Slack availability around the clock, staying involved in every code review and architectural decision. Being the person everyone came to for answers felt rewarding - whether it was debugging tricky issues or walking junior devs through complex features.

Then as I started juggling more projects simultaneously, things started feeling off.

Most developers were holding off on technical decisions until our daily sync. My calendar turned into back-to-back meetings where I'd repeat the same tech advices to different developers working on related problems across different initiatives. Worse yet, I noticed people had stopped growing technically. They were just waiting for me to tell them what to do.

The damage was clear: I had become a single point of failure not just for technical decisions, but for basic operations. My desire to stay involved in everything had made the entire organization more fragile.

Why I Had to Stop

Changing this meant facing some hard truths about myself. Yeah, it felt good to be needed at the beginning, but my need to stay involved in everything wasn't actually helping my team grow. The toughest part? Accepting that engineers would make different choices than I would, and that was exactly what needed to happen.

I had to completely flip my approach. Instead of solving every problem, I focused on making sure the team could solve them without me. Individual code reviews became team standards. Private techincal chats turned into collaborative sessions or mob reviews. Everything was documented so that everyone could follow the "runbook". I stopped being the main reference and started empowering people.

It wasn't smooth journey. Some people struggled with the extra autonomy, and yes, decisions got made that I wouldn't have made. But something cool happened over time: the team got stronger, more creative, and way more resilient than when everything ran through me. Developers started bouncing ideas off each other more, bringing different perspectives, finding solutions I never would have thought of.

Looking back, my attachment to those individual relationships was actually holding everyone back. The weird thing is, by stepping away from being everyone's go-to person, I gave my team room to become the engineers I always knew they could be.

This shift isn't just about communication at scale - it's about training plus scaling trust, ownership, and your team's ability to solve hard problems without you being the bottleneck.