I'm not as much of an overhead strategist, but I do have a rule that I follow that matches this article: if I hesitate to start working on a problem because it seems too difficult, it's because that problem has not yet been broken into small enough parts.
I tend to hesitate because I know exactly that it will be a lot of long and difficult work to break everything down into small enough parts, of which there will be a whole lot, and work through them and integrate them all.
I agree, I follow the same principle. Also i would like to extend it to - "if you slow down when working on a problem, you might have stumbled upon something unexpected, identify it, and break it down.
I have a similar rule when writing documentation. As soon as I find myself writing something in the passive voice, I know I’ve hit part of the system I don’t really understand. “This event happens” instead of “subsystem A triggers this event”.
Nitpick: “This event happens” is not in the passive voice. “This event is triggered” is in the passive voice — and so is “this event is triggered by subsystem A”. (What you probably mean is “writing something vague or lacking agency”.)
