Perfectionism at Work: Why 'Not Yet' Is a Rational Answer

There was a stretch where my inbox was full of emails I had already answered in my head.

Not ignored. Answered, mentally, and then not sent. Because the answer I had was partial, and sending a partial answer felt like admitting I had not done the work. So the message sat there while I went looking for the rest of it. Some of those sat for days. A few of them, the person had stopped needing an answer by the time I sent one.

What I eventually understood is that almost nobody was asking me to boil the ocean. They wanted one piece of insight so they could keep moving. I was applying a standard nobody had asked for, to work nobody had specified, and calling it diligence.

That is worth naming, because the first explanation anyone reaches for is a personality one. What was missing from that stretch was a definition of a finished answer, and nobody had written one, me included.

Last week, Pace Loop was about the map: a number only aligns people once they can see how it feeds the next one. This week is the same rail one turn further. A number is only useful if it also tells you when to stop building and release. Which is where I said we would go: let the loop be imperfect on purpose, because that is the only way it ever actually turns.

That is this week's pairing. SMART Goals and Wabi-Sabi, Frameworks 12 and 13 in The Resilience Engine. Two of the three foundational frameworks in chapter four, and the two that most operations run one of and not the other.

The mechanism

Three parts, and the third one is the part almost everybody skips.

The first is the release criterion. SMART Goals, formulated by George T. Doran in 1981, turn an aspiration into something specific, measurable, achievable, relevant, and time bound. Every one of the five earns its place when you point the framework at shipping. Specific and measurable tell you what you are looking at. Achievable decides whether the bar can actually be cleared with the people and the time you have, and that is where most standards quietly break. Relevant stops you perfecting the part nobody touches. Time bound is what forces the question to get answered at all rather than deferred one more week.

Put together, that is a release criterion: a defined standard of good enough, written down before the work starts.

The book is blunt about why this half is not optional. Without it, the whole thing degrades: "good enough" must be explicitly defined, or Wabi-Sabi becomes excuse for sloppiness.

The second is permission. Wabi-Sabi is the Japanese aesthetic of finding beauty in imperfection, impermanence, and incompleteness, expressed most vividly in Kintsugi, the practice of repairing broken pottery with gold so the repair is the most visible part of the object. In an operation it is a permission structure, and it changes the question you ask before release: not is this perfect, but is this better than what we have now, and will it generate the learning we need.

Dr. Nadya Zhexembayeva put it better than I did when this came up between us recently. She called it "the psychological safety that makes honest iteration possible."

The third part is the version label, and it is the connector that turns the first two into a loop instead of a one-time decision. Number the thing. Attach a date to what it currently is, an honest list of where it falls short, and a commitment to the next pass. The linguistic shift the book asks for is small and it changes the object: you stop calling it the process and start calling it the process as it stands today.

Without that label, a released item is a verdict. With it, a released item is a data collector, and what it collects is the input for the next measurable target. That is the return leg. You ship at the standard, real usage tells you which of your assumptions were wrong, and the next target gets set against behavior instead of against your best guess.

Why each rail fails alone

Run the release criterion without the permission and you get paralysis that looks exactly like rigor. The book is careful here and I want to be equally careful: for creative and learning-intensive work, a hard target can create a psychological rigidity that shuts down exploration. A team with a measurable bar and no permission to release at that bar has a bar that only ever moves up. Every review adds one more item. Nobody involved is being difficult, and that is what leaders miss. Not yet is a rational answer when the standard is unwritten. The person who waits can always defend the wait. The person who released cannot defend against a bar that gets set afterward.

Run the permission without the release criterion and you get drift. This is the failure mode people expect and it is real. Permission with no baseline is carelessness with better vocabulary. The team ships, but nobody can say what the thing was supposed to clear, so quality becomes a matter of who happened to look at it that week.

Run both without a version label and you get the trap I find most often in operations that consider themselves fast. Work goes out. Everyone knows it is a first pass. Nobody writes that down, and within a month the known limitations have quietly become defects, the team that shipped is defending the gaps instead of closing them, and v1.1 never gets scheduled because nobody ever said there would be one. The book names this as the third critical failure: iteration has to actually happen, or you have just shipped incomplete work. Teams notice the gap between the stated intent and the behavior, and they stop believing the next time you say ship it, we will iterate.

The evidence

McKinsey ran a global survey on decision making in 2019 with more than 1,200 managers and executives responding. Two findings.

The first is the baseline. Only 20 percent of respondents said their organization excels at decision making. One in five. Everyone else, describing their own house, declined to make that claim.

The second is the one that matters here. Respondents who described their organization as fast at decision making were about twice as likely to also describe it as high quality. The same organizations reported both.

Two caveats, because the number is only useful if you hold it correctly. This is self-reported perception, not audited outcomes. And it is correlation, so it does not tell you that speed produced the quality. What it tells you is that the assumption underneath most delay, that taking longer is what buys you a better answer, is not what executives observe in their own organizations. The book makes the same argument from the other direction: the leader who decides on 70 percent of the information and adjusts as results come in tends to outperform the one waiting on a certainty that never arrives.

Installing the loop

One move this week.

Take the next thing your team is about to build for you. Before they start, answer three questions in writing and send the answers with the assignment.

What has to be true for this to be usable. What is allowed to be rough. What we are deliberately not solving in this pass.

Three sentences. It will take you four minutes and it will save somebody two weeks, because you have just given them a bar they can prove they cleared. Until you do that, nobody can ever demonstrate they are done. They can now be finished. That is the whole gift.

The personal version of this is the one I use on my inbox now, and it is smaller than it sounds. When I do not have the complete answer, I send the part I have and say so plainly. Here is what I know, here is what I do not, tell me if that is enough and I will keep digging if it is not. It is nearly always enough. The email I would have spent an hour perfecting gets answered in four minutes, and the person on the other end got what they actually needed, which was rarely the thing I was about to over-build.

Where Act II goes next

Act II keeps making one claim: structure beats charisma. Three weeks ago the structure was a stack. Then a link. Last week a loop, cadence aimed at a destination and mapped so people could see the connections. This week the loop learns to close, because a target that never tells you when to release is just a place to keep working.

Those emails I sat on were not a discipline problem and they were not a diligence problem. I had never decided what a good enough answer was, so I could not tell when I had one. The bar was not high. It was missing, and a missing bar behaves exactly like an infinite one.

Next week, the return leg. What a team does with the distance between what it shipped and what it meant to ship.

Oscar

Want to see where your team is waiting on a bar nobody wrote down? The Resilience Engine Systems Audit maps it: myresilienceengine.com/systems-audit