I don't think there's a silver bullet for you; you probably aren't incapable, but you may need to suffer through sub-optimal organization to hone this skill. What I will say is that, if you haven't worked on an existing project with highly complex organization (ideally one that has problems), doing so might help you. While I envision working directly on the project when I say this, there are cases where working with complex dependencies you need to get custom results out of can also be useful.
The point is that you want to be working with complex software (not simple interfaces) that requires a strong understanding of its internals to accomplish what you need. You'll know you're working on something on roughly the right magnitude of complexity when you regularly realize that your understanding of how the project or dependencies work is wrong, and your solution doesn't account for some hitch in how they work. The meta-point is that you're working with sub-optimal decisions other people made, and you either just have to deal with them and simmer to yourself about how _you_ would reorganize this mess if it was within scope, or you have to start refactoring their code (or building your own interface with it) that solves the problems with their design. The meta-meta point is that we're better at seeing problems in work other people have done than our own, but with effort we can train our eye on other people's work and (eventually) learn to focus it on our own.
At it's core, I think this is really about the cognitive overhead associated with working on and understanding a given implementation, so working on things that are cognitively overwhelming provides you an opportunity to learn about how to manage cognitive overhead. The result is hopefully that you learn to wrangle that complexity into an understanding that helps you do what you need without doing surgery, you build an interface that reduces the cognitive overhead enough that you can do what you need, or you refactor to accomplish the same.