I feel like this is one of the easier issues to identify as soon as you get good at paying attention to the signs. My teammates have always been eager to explain the difficulties they are facing. Still, it never hurts to deploy the direct question in discussions: Why is this hard?

When you do ask, try to avoid letting anyone dismiss ideas too quickly. A key element to reaching new insights is traveling through the intermediate impossibles. This is the idea that we would like to just do X, but obviously we can't because X is impossible. Therefore we dismiss it. However, is X always impossible? Or is it just impossible in certain circumstances? Could we work around those circumstances? If we did, could we then do X? Even if this doesn't turn out to be the direct solution, having the discussion and working through the possibilities is often how we find our way to better ideas.

Speaking of better ideas, it's surprisingly helpful to analyze more than one possible approach to a build. John Ousterhout sometimes has to threaten his programming students to get them to try his idea to design features twice, but he finds that it always leads to better outcomes. I'm not even convinced that it wastes much time. The amount of understanding you gain for the problem you are solving provides more leverage when you are building the implementation, no matter which path you end up choosing.

Remember, what we've loaded into our collective understanding is far more important than any code that we produce.