One of the most consequential daily decisions a leader makes is whether to step in or let someone work through a problem themselves. Done right, it builds resilient, capable engineers. Done wrong, it creates either dependency or abandonment. Here's the distinction that changed how I develop people.
2–4 min read
Key Takeaways
One of the most important decisions a leader makes each day isn't strategic. It happens in a Slack message or a quick conversation: Do I step in, or do I let them figure it out?
Get this wrong in one direction and you're micromanaging — solving things that weren't yours to solve, eroding the confidence and capability of the people you're developing. Get it wrong in the other direction and you're abandoning capable people to unnecessary failure.
The distinction I hold onto: there's a difference between letting someone struggle through a problem and letting them struggle alone. One builds capability. The other just creates pain.
Capable people need to experience the struggle. That's not philosophy — it's how learning actually works.
When someone hits a wall and pushes through it, they develop something that can't be given to them: a real understanding of the problem, confidence from having figured it out, and resilience for the next hard thing. Those are earned, not taught.
Every time a leader steps in before someone has had a chance to work through the difficulty, they steal that opportunity. The rescue feels helpful in the moment. Over time, it creates dependency. Engineers who are rescued from every hard problem stop trusting their own judgment. They wait for direction instead of making a decision.
The goal isn't to make the job easy. The goal is to make the team capable.
There's a difference between letting someone struggle through a problem and letting them struggle alone. One builds capability. The other just creates unnecessary pain. The leader's job is to hold that distinction clearly — and act on it.
Stepping in doesn't mean solving the problem. It means showing up as a thinking partner.
When I step in, I'm not there to provide the answer. I'm there to help someone think more clearly about what they're already working through — asking the right questions, pointing to the right resources, reframing the problem so a different path becomes visible.
The test I use: when I walk away from that conversation, who owns the problem? If the answer is still them, I've coached. If I've taken on the work or made the decision for them, I've rescued. The first builds capability. The second defers it.
The solution still needs to be theirs. The confidence from arriving at it needs to be theirs too. That confidence is the point.
There's an important line between capability struggles and performance struggles. They look similar but require different responses.
A capable person struggling through something new — learning expanded scope, navigating new complexity — needs coaching and patience. Give them space, step in to coach, trust the process.
Someone consistently not delivering on expectations they've had time to understand is a different situation. That's not a coaching opportunity to wait out. That's a performance issue to address directly. I don't conflate the two. Letting a capable person struggle through a hard problem is an investment. Letting an underperformer continue unchecked is a leadership failure.
Series
People-First Leadership · Part 2
Previous · Part 1
Why I Don't Do Technical Interviews for Senior Engineers
Next · Part 3
People Are Your Most Valuable Asset — And Most Leaders Don't Actually Believe That
Next · Part 4
The Documentation Discipline Every Engineering Leader Needs
Next · Part 5
Accountable Autonomy: The Leadership Philosophy That Actually Works
This philosophy sits at the core of how I develop leads — and why I don't protect them from the hard parts of the job.
A lead who has never had to figure something out under real pressure isn't ready to manage a team. The years in a lead role — owning delivery, developing ICs, balancing contribution with responsibility for others — builds a foundation no training program replicates. It's earned through doing.
I give leads real problems. I coach them through difficulty the same way I'd coach one of their ICs. When they hit something genuinely outside their authority, I step in and clear it. But the work of leading — the hard, important work of holding a team together under pressure — that's theirs.
By the time a lead steps into full management, they've been practicing the job at smaller scale for months or years. The transition becomes an expansion, not a leap.
Give people problems worth solving, the support to work through them, and genuine recognition when they do. That's how you build engineers who are capable and confident — not because someone rescued them, but because they earned it.