Directionally correct and not precisely wrong

I was reflecting recently on what makes a software development effort successful. Effective planning? A capable team? Supportive stakeholders? There's probably a robust answer here alone, but what caught my attention in hindsight is when small initiatives towards a larger goal don't materially contribute to success. You wouldn't know that at the time; work is undertaken on a basis of its perceived value, but it's often in hindsight, without the "fog of war" that reveals false starts.

False starts are often an effect of decisions being made prematurely.

Think about the role of an executive. Removed from operational responsibilities, they think in generalities, and produce a vision for the future that often has rough edges. If you, as an executive or individual contributor, were scoping a large undertaking, you're treading the line between sitting in the "scoping" phase for too long before executing. Conversely jumping right into execution, particularly when it requires the mobilization of capital and resources, might quickly reveal shortcomings in feasibility and require a pivot, restructure, re-plan, and the related - a false start.

Avoid making specific decisions until absolutely necessary

If you make specific decisions prematurely, you risk focusing on work that may not ultimately contribute to the final goal. This isn't to say you should operate in generalities forever, you just have to be strategic about decisions you make that drive work. And operating precisely too early may more often contribute to backtracking or lost time, rather than being directionally correct and making decisions as the path forward becomes more clear.

As a final note, you don't know what you don't know. You can never make every decision "up front" even for the most repeatable engagements. Remaining flexible, with a focus on progress rather than velocity more often leads to successful outcomes.

Show Comments