Precision and high standards have contributed more to my success than almost any other qualities.
I notice inconsistencies.
I question details that other people may consider acceptable.
When I build a policy, process or operating standard, I want it to be clear, complete and capable of producing the intended result.
These qualities have helped me build stronger work.
They have also made me the bottleneck.
There have been moments when the organisation needed a process implemented quickly, but I struggled to release something that I still considered incomplete.
I could understand the urgency intellectually.
I could see that the team needed the process.
But if the work still appeared subpar to me, releasing it felt like accepting a lower standard.
So I continued refining.
My intention was to protect quality.
The consequence was that a process capable of helping the organisation remained inside a draft.
Strengths become weaknesses when they lose context
A strength does not become dangerous only when it disappears.
It can also become dangerous when it is applied indiscriminately.
Precision is valuable.
Indiscriminate precision is expensive.
My mistake was not that my standards were too high.
It was that I was applying the same completion threshold to every category of work.
A high-risk clinical protocol, an internal reporting format, an administrative workflow and a customer-facing script did not all require the same level of completeness before they could be used.
But I often treated them as though they did.
Everything had to move towards the standard I imagined for its final version before I was comfortable releasing its first version.
That felt like consistency.
In reality, it was a failure to distinguish between different kinds of consequences.
What does the final 40% actually change?
The question that began changing my judgment was simple:
What is the real difference in impact between releasing this at 100% and releasing it at less?
Not the difference in appearance.
Not how unfinished it feels to me.
The difference in actual organisational impact.
Sometimes the final improvements materially reduce risk. They may protect patient safety, ensure legal or regulatory compliance, preserve privacy, prevent financial exposure or clarify an irreversible commitment.
In those cases, the work should not move until the required standard has been met.
But in other cases, the remaining work improves elegance more than outcome.
It might refine the wording, anticipate uncommon exceptions, enhance the reporting layout or add sophistication that would be useful (but not essential) for the process to function.
The difference between the first usable version and the ideal version may be obvious to the person who designed it.
It may be almost irrelevant to the result it currently needs to produce.
Once I began evaluating that difference, I realized that waiting for the final 40% could sometimes create more damage than releasing without it.
The team remained without guidance.
The problem continued operating.
No real-world feedback was generated.
The organization paid for delay while I continued improving something that had not yet encountered reality.
Sixty percent does not mean sixty percent safe
I began categorizing work according to what genuinely had to launch at 100% and what could be released at approximately 60%, then improved deliberately.
That percentage requires an important qualification.
It does not mean releasing something that is unsafe, unlawful, incomprehensible or incapable of doing its basic job.
It means 60% of the eventual sophistication, not 60% of the minimum required standard.
Before any version-one process is released, it should still be:
- Safe
- Lawful and compliant
- Ethical
- Usable
- Clear enough to execute
- Assigned to an identifiable owner
- Supported by a defined method for reporting problems
The remaining 40% may contain refinements, automations, edge cases, formatting improvements or functionality that becomes easier to design once people begin using the process.
A controlled first version is not an excuse for careless work.
It is a deliberate stage in building better work.
Some work must be correct before it moves
Other work becomes correct because it moves.
Clinical safety standards, regulatory responsibilities, privacy controls, employee disciplinary policies, significant financial controls and irreversible commitments require a high threshold before implementation.
The potential cost of getting them wrong is too serious to rely on casual iteration.
But many internal workflows, administrative tools, reporting structures and reversible operating processes improve only after they encounter actual use.
Before release, they are based partly on assumptions.
Once the team begins working with them, leadership can see:
- Where the instructions remain unclear
- Which steps create unnecessary friction
- What information is missing
- Which exceptions occur in reality
- Where ownership becomes uncertain
- Which parts employees interpret differently
Keeping the process inside a draft does not reveal these things.
Movement does.
A first version still needs discipline
There is a difference between iteration and neglect.
A temporary version should not quietly become permanent simply because everyone became accustomed to it.
When I release work before it reaches its final intended form, it should have:
- A defined minimum standard
- Visible remaining gaps
- A named owner
- A review date
- A feedback loop
Without those controls, releasing early becomes an excuse.
With them, it becomes a development method.
The four questions I now ask
When deciding whether work is ready to move, I evaluate four things.
1. What is the cost of imperfection?
Could the incomplete element create material harm, non-compliance, confusion or an irreversible consequence?
2. What is the cost of waiting?
What problem will continue while the work remains unreleased?
3. How reversible is the decision?
Can the process be corrected quickly without creating significant damage?
4. Does improvement require real use?
Will further desk-based refinement meaningfully improve the work, or do we now need operational feedback?
These questions help determine whether the work requires further completion or controlled exposure to reality.
High standards need classification
I have not abandoned precision.
I have become more selective about where precision produces meaningful value.
Some work deserves every available layer of scrutiny before anyone touches it.
Some work needs a credible, controlled first version so the organization can begin learning.
Treating both categories identically does not protect excellence.
It directs time and attention away from the places where excellence matters most.
The leadership question is not whether quality matters.
It is where incompleteness creates genuine risk, and where waiting creates more risk than releasing.
High standards remain a strength only when they are accompanied by judgment.
Which part of your work must be excellent before release, and which part can only become excellent after people begin using it?