Thirty Questions Before Any Code Is the Decision That Stalls the Project.

Watch the video version:

It feels like a million questions. Usually it is about thirty. A piece of work lands with a team, one I work with or one run by a leader I talk with, and before anyone writes a line of code, the list comes back: every question someone could ask about it, each one needing an answer before the work can start. It happens literally every day. The reasons sound the same. "That will throw our estimates off." "It will cause us to miss the deadline." What sits underneath the list is an aversion to the unknown, and specifically to working from a partial answer and watching a better result emerge.

What I feel when the list arrives is worry and frustration. The frustration is the wait. The worry is about what the people asking are missing, because I know what is on the other side. The engineers who can handle the unknown, who can build with ambiguity and let the story tell itself, are where the magic is. Fiction writers have known this a long time. Stephen King wrote in On Writing that he believes "plotting and the spontaneity of real creation aren't compatible." He starts with a situation and lets the story develop as he writes it.

Most engineering teams were trained the other way. Get the requirements right up front, because ambiguity is the enemy and every change costs more the later it arrives. AI has given that instinct a new argument: agents work best from a complete spec, so write everything down before anything gets built. The spec does matter; in September I argued it needs real governance, and governing it starts with deciding when each blank gets filled. Both arguments end in the same place: answer all thirty first.

At Open@Epic last week, a speaker who works on both sides of health system integrations said the difference between an integration that goes smoothly and one that stalls "is almost always a decision that is made before any code is written." She is right, and the one I see every day, across the teams I work with and the leaders I talk with, is the decision to answer everything first. The thirty questions become a single gate, so nothing starts until every one is answered. A question that could safely wait becomes a blocker like the rest. Many wait on someone outside the team, so the slowest answer sets the start date. The clock runs the whole time nobody builds. Then the build starts and several of the answers change, because real work shows what the question actually was. The project pays for the wait and for the rework.

Nobody decided which questions had to be answered first. Everything defaulted to "before," and a default is a policy nobody wrote down. That is a gap in Decision Clarity, the condition I describe as every decision having a clear owner, defined inputs, and an explicit point of resolution. Some of the thirty questions have owners. None has a point of resolution, so every one of them gets the earliest point available.

The AI argument makes this worse. AI does not wait for the full spec. It fills in the blanks based on probability, which means the most likely answer, and the most likely answer can lead to mediocrity and suppress innovation. A team that will not build without every answer has two outcomes: it stalls, or it hands the blanks to a tool that fills them with the average. Either way, the better result that only emerges from building through the unknown never shows up. That ability is what puts people a major leap ahead of AI, and the thirty-question habit leaves it unused.

Not deciding is not the answer either. You do have to decide things. The leaders who get this right decide when each question gets answered, on purpose, instead of letting all of them default to now. I have run on what lean practitioners call the last responsible moment for decades, the principle Mary and Tom Poppendieck brought into software: decide at the point where failing to decide would eliminate an important option, and not before.

Sort the list with three questions. Can we move forward without the answer? What is it actually holding up? What does it cost if the answer does not hold? The few that fail go first, with an owner and a date. The rest get answered by the build.

Take your team's current list of open questions, the one holding up a start. Run each one through those three tests and count how many actually fail. That number is your real gate. Every other question on the list is waiting time you chose.

LeadershipOS™ lays out the full Decision Clarity practice: every open decision gets an owner, defined inputs, and an explicit point of resolution, so your next list of thirty questions shrinks to the few that actually gate the work: https://TheLeadershipOSBook.com

Your team keeps bringing you decisions they could make themselves, and they are right to. Why telling them to decide on their own cannot change it, and what does.