I've seen many folks in management just always assume incompetence or rabbit holing on the part of engineers. It's good to ask clarifying questions. But as a manager you should be aware that adopting a style of second guessing and interrogating everything your reports do comes off as insulting - after all, you likely hired them, so why don't you trust them?
That being said there are no hard and fast rules here, and being aware of the different histories of different folks is important, but defaulting to a critical attitude is likely to lead to all types of efforts to hide things from you just to avoid questioning, feeling insulted, having their time wasted, etc.
Note to self: Remember this, whenever you feel stuck and look at the problem in perspective.
My experience, tells me this is one of the biggest guidance a technical/engineering manager must be able to provide to his team. I am not sure how hard or easy or for that matter even makes sense from the manager/lead's perspective, it is to provide this, but have found that whenever my manager is asking me to speed-up i run into these problems and lose the ability to judge whether i'm running against a wall or not.
In your race condition example, it would be the difference between an engineer debugging a race condition in mission critical code, and debugging one that is incidental complexity in a unit test or ancillary tool that could be refactored to be single threaded, or just omitted altogether. Heck, even in the mission critical code case, it's worth considering how many users it effects, how it effects them, and at every moment considering if the time spent so far on the problem (and its associated opportunity cost) is still justified. (Taking into account the fixed costs of switching context into the problem again.) It's very easy to get wrapped up in an interesting problem and forget about the eject button.