Why Managers Shouldn't Solve Every Problem for Their Teams

One of the hardest parts of being an engineering manager is watching your team struggle - especially when you know there's a faster or easier way to solve a problem. It's tempting to jump in, to offer advice, or even to lay down a process or rule that would “solve” it for them.

But here's the thing: struggle is where the real growth happens.

When teams face a challenge, wrestle with a problem, or navigate complexity together, they build muscles - technical, collaborative, and organizational. They learn things that can't be taught in a meeting or a slide deck. They gain context, intuition, and experience. And most importantly, they start to understand why certain practices or processes exist.

Because let's be honest - many “best practices” only make sense after you've felt the pain they're designed to avoid. Code reviews feel like overhead until you've merged a bug that a second pair of eyes would have caught. Sprint boundaries feel rigid until your last “just one more thing” derailed the whole release. Without that struggle, these rules can feel arbitrary or bureaucratic.

That's why I try not to shortcut my team's learning by enforcing too much too early. Of course, there's a balance - my job is to make sure the team struggles safely. I'll nudge, I'll coach, I'll ask questions. But I won't rob them of the opportunity to figure things out for themselves.

And here's what I've noticed: when a team arrives at a solution on their own - when they feel the pain, reflect on it, and decide to change - the buy-in is night and day compared to when a rule is handed down from above. Suddenly, that “process” is their process. It means something. It sticks.

So yeah, the struggle is uncomfortable. But it's also incredibly valuable. As managers, we need to protect the space for it, not rush to eliminate it.