Having managed teams before, my feeling is that this advice is good in some cases, and bad in others. For example, if your team is filled with a bunch of newbi

Having managed teams before, my feeling is that this advice is good in some cases, and bad in others. For example, if your team is filled with a bunch of newbies who don't really know what they're capable of yet, their default reaction alot of times is to come to you with their issue. If it happens too frequently it can become counter-productive. On the other hand, some problems can take a long time just to figure out what's going on, and even more it can be difficult to articulate the issue precisely. As long as the problem is well formulated and precise, progress can usually be achieved by bringing the problem (without solution). Generally speaking, though, it's good to keep in mind that a manager usually has a ton on his plate already and needs to deal with all his team's problems, whereas the developer is only responsible for working on the one problem. Final point would be that, especially with younger devs, they can get into a "paralysis by analysis" state. I encourage younger devs to not work on a problem for too long so they're not spinning their wheels. So in these cases I want my younger devs to come to me after they've spent maybe 10-15 minutes on a problem, even if at the end they still don't know what the problem is.