Pragmatic Process

I'm a Senior Engineer. I am getting feedback that I need to improve the pragmatism in my process.

This isn't the typical "choosing the overbuilt implementation instead of a good enough one" that's usually ascribed to an unpragmatic programmer. I refer to that as pragmatic design.

At a Senior level, when working out incomplete problems in a software design space, I'm trying to understand a pricess of more carefully choosing which parts of the problem to investigate, validate against code, and spend more time building out detail, and which parts to leave abstract and hand-waive over.

The utility of that skill is getting the important problems solved, and leaving the unimportant ones for implementation details later. Doing it well doesn't mean avoiding bugs or design flaws, but the ones that do occur are largely inconsequential to development or output.

I'm looking for resources to help train that particular skill. Right now, I have to expensively sit down, map out the problem space, indicate the level of unknownness and risk for parts of the problem, make a plan on how to investigate, rationalize why that's the right approach, and then go fact finding. Later I post-mortem against my initial guesses.

This is very different from the way I prefer to work, which is more or less reading the entire system until I understand it, and then building the plan of action. It's complete, it produces robust outputs, but it's very slow and time wasting. That bottom-up approach doesn't scale for larger problems because there's too much to read and understand.

I'm being challenged to learn more quickly by learning less, abstracting more, and build an intuition for what is and is not worth getting more detail; a pragmatic development process.

Got any tips? Resources? Things you did or read that helped build that capacity?