[tunesmith]

None of these are bulletproof, but try a couple of the following.

Try thinking in terms of strategies and tactics. The overall problem can be described in one high-level sentence of "what" to do. That's the strategy. That strategy can be described in one high-level sentence of "how" to do it. That's the tactic. Then that tactic can be broken down into 2-5 slightly lower-level sentences of "what" to do, which are strategies that are sufficient to meet that tactic. You may continue this for a few strategy/tactic levels. Eventually you have some medium-level strategies you can pass on to junior/midlevel people. But trust them to determine the tactic. If you give someone else a strategy and then tell them what their tactic is, you're micro-managing.

This is also roughly what a lot of refactoring and clean code is about. In a method, you don't want to mix levels of abstraction. Instead, a parent method should call inner methods that are named by what they do, while those inner methods in turn have the logic that is how to do what the method is named. And this can also continue on down to lower levels. When developing this way, you might even mock/facade some of these higher level methods/classes/functions/whatever so you can finish implementing and testing the higher level method/function/class/whatever that calls it.

A full-stack developer that hasn't quite made the jump to "architectural" thinking will often immediately and intuitively identify the lowest-level tasks that need to be done for a project, but like you've noticed, focusing on that implementation style doesn't really scale.