> ## Content Index > Fetch the complete content index at: https://mikegarcia.io/llms.txt > Use this file to discover other available public pages before exploring further. # A question you answer twice was never settled - URL: https://mikegarcia.io/a-question-you-answer-twice-was-never-settled/ - Published: 2026-09-26T19:00:00.000Z - Updated: 2026-09-26T23:06:29.000Z - Description: A clearer guideline and a wider mandate both aim at the person stuck with the call. The mandate does worse: it silences the clearest signal the stall gives off. - Author: Miguel Garcia - Tags: Technical Leadership, Decision Making, Operational Excellence, Governance, Engineering Culture An unsettled question is answered again at every point of action that meets it. All of those answers can be correct, and none of them persists. The usual fixes, written guidance or the authority to decide, leave the question as open as they found it, and the second one also makes it harder to see. ## The bill arrives while nothing is going wrong An engineer starting a small tool works out what language to write it in. The next engineer starts one and works out the same thing from scratch, because nothing says whether the first choice was a standard or an accident. The third does it again. An audit of the tools finds nothing wrong, because nothing is. Everyone in the sequence is doing the job carefully. Per question, the cost is a pause, small enough that nobody counts it. Multiply it by every question a team keeps meeting, and it stops being small, and no one owns the total. ## A mandate closes the honorable exit A written guideline hands over information, and information is rarely the gap. Someone stopped at an unclear call can usually name both candidates. A document explaining how to weigh them adds one more thing to weigh while the clock runs. A wider mandate does something worse. Under a mandate wide enough, checking with someone reads as declining to use it, so the checking stops. From above, the quiet looks like the mandate working. Each person still works the question out alone. Where everyone lands on the same answer, the ask is the only sign of the pause anyone can see. ## Settling is a different act from answering Answering serves the case in front of you. Settling serves every case after it. Whoever meets the question can answer it, but settling it takes authority over every case to come. That is why it rarely happens while any single case is waiting. The question reaches whoever holds that authority through the ask, which is the channel a wider mandate shuts. An engineer working out the language for the third time is doing the job in front of them. No amount of decisiveness settles it, because the next person still arrives at an open question. What settles it is deciding once, with the authority to make it binding, and carrying that answer into the moment. A settled answer binds the people who accepted the authority that settled it, and only as far as that authority reaches. An engineer accepts it on taking a role that states who decides what, and every decision made inside those decision rights binds them without needing their approval. A customer who accepts a product has not accepted its maker's authority over every choice inside it. ## A question that turns on the moment can still be settled Even when the answer changes from case to case, what it turns on stays put. Name it X, and what each value of X means gets settled once. Each new case comes down to reading X. So the test for a settleable question is whether the same reasoning answers it every time. Which language a new tool is written in doesn't change the reasoning: wherever the question comes up, it lands on the same answer, so the answer itself gets settled. Whether to take a deal runs on stable reasoning too. Its answer still turns on facts that don't exist until the deal arrives, like what the buyer insists on. There the reasoning gets settled, and the facts get read at the point of action. The person reading them still makes the call, on reasoning done once for everyone. ## Judgment at the point of action repeats its errors too The usual objection to settling a question in advance is that a settled answer will be wrong in some cases, while judgment at the point of action adapts to each one. The first half is true. A settled answer is wrong in some fraction of its cases, and one entry decides all of them, so nothing averages out. The errors are common-mode. Judgment at the point of action adapts less than it looks. Engineers start from the same templates and check with the same few people everybody asks. So their errors correlate too, which is how identical wrong choices end up in places no policy ever set them. A settled answer can be corrected in one place. Its consequences still have to be repaired wherever it was applied. Judgment's errors share a cause nobody owns. That advantage holds only while the cost of being wrong stays bounded. Add up the damage across every case a wrong answer binds, for as long as it could stay uncorrected. The total has to be something you can absorb, like a rewrite or a lost deal. Where the total has no ceiling, the question stays a judgment call. If correction is what bounds the damage, somebody has to be able to discover the error. ## An answer stays settled only while somebody maintains it A settled answer has to be findable where the action happens. It can take some looking and still save all of the reasoning. The strongest form is built into the work, so nothing proceeds without it: a merge stays blocked until the change carries tests, a contract term is already on the page when the negotiation opens. A document counts too, when it records the decision itself. The case it does not fit will arrive, and a settled answer needs a sanctioned way to be wrong when it does. If the only routes through are a quiet workaround or reopening the question under pressure, the first is what happens, and nothing records it. An override that leaves a trace turns the exception into the signal that the answer needs revising. An answer also rests on the premise it was settled against, and it holds steady while that premise shifts beneath it. It rots unnoticed, because a stale answer is indistinguishable from a live one. Record what it turned on, and the rot becomes detectable. The cases nobody anticipated need an answer too, and the answer is to wait. On its own, that is the same unrecorded pause with a citation attached. It counts as a settled answer once someone files the case against a name and a deadline. Somebody still has to own the answer and read what comes back. An answer whose owner has gone, or has stopped reading, is advice in a firm voice from that day on, and the first person to find out is whoever relied on it. ## Read the repetition, not the volume Don't audit your guidelines for this. A guideline can be accurate, current, and findable while the question it covers still gets worked out from scratch every time. Nothing records the pause, which is why it survives. Read what it leaves behind. Escalation volume is the wrong number. Count how often the same question arrives from different people. Then read the artifacts, which keep speaking after a mandate has silenced the ask. A dependency swapped and swapped back. A clause that gets reopened every time it is used. Either can have a good reason, because conditions move. Look for the ones where nothing the answer turns on has moved. Each of those is a question being answered again right now, carefully, by somebody who will not be the last.