If we are looking at this from a business perspective (which might map), the actual wizardry is in knowing
exactly when to push and when to sleep on something.
I think we can all agree that there are things you should think very deeply about before you even touch your computer or join the conference call. Things like what sorts of vendors and business partners you want to get married to for the next half-decade. If you want to be a Microsoft shop or some OSS champion (both valid in my view!). These kinds of things often times require starting a new company to fix after you commit.
In our domain - the thing you don't want to spend a lot of time worrying about is the entire scope of the actual code/development work. Assuming you are using source control, you have a superpower that allows instant teleportation to any moment in time. The consequences of making a bad choice and acting quickly are negligible, assuming you aren't trying to lose the game on purpose (e.g. master builds straight to prod on unprotected pushes). It only gets to be adverse if you are unable to separate the bad from good ideas afterwards. Not reflecting on your prior works. I believe we'd refer to this as the "technical debt".
I think it was Amazon that does the one-way/two-way door decision test. This is a fair criteria for deciding when to sleep on a proposal or when to shoot and then aim.