shielding my team from getting better

I’m 24, CTO of a startup serving government clients across 9 countries. Built the product from 0 to 1, hired the engineering team, established the dev culture. Recently realized I’d been doing my team a disservice by protecting them too much.

Looked at our PR history, sprint retros, incident reports. Pattern was clear: I was the bottleneck, the safety net, and the cleanup crew all at once.

Developer submits a 4000-line PR. I review it myself instead of rejecting it and asking them to break it down. Someone spends days debugging a Hugging Face token expiration that should’ve been caught in logs immediately. I jump in to help instead of asking why they didn’t check logs first. Team says “we don’t have time for testing.” I accept it instead of making testing non-negotiable.

Told myself I was being a good leader. Supportive. Available. What I was actually doing was incentivizing learned helplessness.

Most uncomfortable feedback I got: “zero attrition” isn’t necessarily great culture. Might be a sign nobody’s being pushed hard enough. My team was comfortable. Comfortable and stagnating.

Accepting “smelly” code as acknowledged debt. Team member says “my code will smell” before a PR, I respond with “that’s great that you acknowledge it.” Code still shipped smelly. Acknowledging technical debt isn’t the same as preventing it.

Solving problems instead of teaching problem-solving. Whenever something weird came up, my default was “just send me a text.” Translation: I’ll rescue you instead of letting you struggle and learn. Over months, the team didn’t develop debugging discipline.

Confusing crisis management with leadership. We shipped 45 PRs in May during a transcription infrastructure crisis. Wore that as a badge of honor. But I was celebrating firefighting in a building I partially set on fire through insufficient planning.

The transition that helped most: we appointed a product manager. Suddenly I had to figure out communication channels. When the CEO asked me to make an urgent change, my instinct was to just do it. But now there’s a PM managing the sprint. I had to learn to ask: “Should I coordinate with the PM first, or tackle this directly?”

That question forced me to stop being the single point of coordination and start trusting the structure we’d built.

Now: rejecting PRs that don’t meet standards instead of fixing them myself. Takes longer short term. Builds capability long term.

Asking “what did you try?” before jumping into debugging sessions. Not as a gotcha. As a genuine question that teaches the diagnostic process.

Setting explicit quality standards the team is accountable to. 30% test coverage isn’t impressive. It’s a gap, and the team needs to own it.

Support doesn’t mean shielding people from the standards they need to meet.