Default to action

In software engineering, there’s always a choice between waiting to be perfect and being wrong at speed. Remote.com speaks of the concept of ‘defaulting to action’ in such a situation. Sure, interrupting someone can help get your work close to perfection; but you can’t overlook the impact it has on the person who is unblocking you. Instead, you choose to be wrong at speed. It’s ok, if you have to backtrack at a later point, but it’s better than waiting to be unblocked. 

Defaulting to action optimises for speed and throughput, but it also encourages thoughtful communication. For example, a well written user story may preempt the need for a story kick-off, where a developer, product owner and tester discuss its implementation and testing approach. When in doubt, teams that adopt asynchronous communication just execute.  

Remote.com

“There are many times when work isn’t ready for us to tackle, tasks aren’t planned, decision makers aren’t online, etc. In these times, successful teams execute, even if they later have to refactor and adapt, they don’t waste time ‘waiting’.”