It's easy to think you should understand a problem entirely before taking any action.
The goal is to fix the problem. So why wouldn't we want to keep digging until we know what it is? We can't start coding until we know what to code, right?
Sometimes we don't know enough to fix it.
It can be better to find out what would help us understand the problem.
If you're looking for your keys in the dark, it is better to go and get a flashlight.
Everyone has examples of times they thought they could push through to finish a task, rather than step back to a more effective starting point. You shouldn't always pause to improve it, but it's useful to consider whether you should. Think of it as a tool in your toolbox, and pull it out when it is helpful.
By waiting to understand before fixing, you can waste a lot of time.
Instead, change the system to give you more information.
Think about what information would help you make the decision, and what would give you that information. Some examples:
If you're ending up in an unusual system state, you can add logging on state changes to track down when you got there. That way, the next time it happens, you'll be able to know what happened.
If a team is not working well together, you can watch as they go through planning. You'll see how they interact, to see what the issues are, and then can give better advice than if you didn't know what was going on.
If you are stuck on a problem, go to someone and see how they solve similar things. Listening to them doesn't solve your problem directly, but it gives you the tools to do so.
Understanding is good, but if you don't understand, change the system to give you more information.
Then you'll understand quicker and better.