Skip to main content
Steady at the Top
← All articles

When a CEO’s perfectionism slows the whole company down

Stop perfectionism from delaying execution by defining the release standard before work enters executive review. Distinguish changes needed for accuracy, safety, or customer value from revisions that express preference. Set a final decision owner and reopen only for a material reason.

Perfectionism is the demand for exceptionally high or flawless performance beyond the needs of the situation. This follows the American Psychological Association’s 2018 defining entry, APA Dictionary of Psychology: perfectionism. Conscientious work can meet a demanding standard without requiring flawlessness. For a delayed release, the distinction concerns whether another revision addresses a real requirement or keeps raising the finish line.

A private moment that makes the issue visible

Composite scenario, not a client case: You make another wording change to a page after everyone else has left. At home, someone asks whether this is the same launch you expected to finish last week. The team has satisfied the agreed requirements, but nobody knows whether the next version will finally be allowed out.

Use the research within its limits

Barsade (2002): The Ripple Effect: Emotional Contagion and Its Influence on Group Behavior studies mood spreading in a laboratory group decision task. It provides a limited reason to inspect the atmosphere of repeated executive reviews. It does not establish that a founder’s revisions reflect a clinical condition or prove that a release-standard test improves execution. Judge the proposed test against the actual review decisions.

State the decision before discussing personalities

The decision is whether the work meets the requirements for its current use. A later improvement can remain worthwhile without becoming a reason to withhold a sufficient version today.

Use the release-standard revision test

  1. State the use and consequence. Identify who will use the work, what decision it supports, and what could go wrong. Match the review standard to that consequence. Identify the consequence of a defect reaching the user. A draft for internal discussion and a binding customer commitment need different acceptance evidence.

  2. Agree on required evidence. Define the accuracy, functionality, and other necessary conditions for release. Put personal preferences in a separate category instead of leaving them as hidden requirements. Have the final owner confirm the standard before production begins. New requirements introduced at the last review should be named as changes.

  3. Classify each proposed revision. Ask which requirement the change serves and what observable risk it removes. Defer improvements that do not justify the cost of delaying the present use. Write the risk removed by the proposed edit. If the concern is preference, compare its value with the consequence of waiting.

  4. Give an owner final authority. Name who can accept the work and the last review point. Preserve specialist review where needed without permitting unlimited discretionary reopening by every participant. Explain how specialist objections reach the final owner. Final authority should close routine debate without silencing evidence of a material defect.

  5. Record a reopening condition. Specify what new information would justify another review after acceptance. Use the condition to distinguish a material defect from continued discomfort with completion. Use a concrete trigger, such as a newly discovered inaccurate claim. General discomfort after acceptance should not automatically return the work to draft.

Define sufficient quality before the last review

Start with the intended use. A customer proposal must accurately describe scope and obligations. A planning draft must support a decision among alternatives. A public page may require factual and specialist checks before release. Define what the work must enable, rather than beginning with a general demand that it feel excellent.

For each requirement, identify evidence that it has been met. A functional test, a verified source, or confirmation from the delivery owner can support acceptance. A statement that the founder likes the latest version is different. It may be a legitimate preference, but it cannot guide production reliably if the founder cannot explain the criterion.

Separate requirements from optional improvements in the work record. Optional does not mean worthless. It means the improvement can be considered alongside timing and capacity rather than silently preventing completion. Give the team a place to retain worthwhile ideas without making the current release responsible for implementing every one.

Classify the next revision by its purpose

When you request a change, name the requirement it serves. Correcting an inaccurate promise has a clear consequence. Rephrasing an accurate introduction may improve clarity, but the specific benefit should be visible. Ask who would understand or act differently because of the revision. If no meaningful consequence can be described, consider leaving the acceptable version in place.

Distinguish a discovered defect from a changed preference. If the agreed requirement was incomplete, acknowledge that and decide whether the new requirement justifies delay. Avoid describing the team as having failed a standard introduced only after they finished. Clear change control protects accountability on both sides of the review.

In a hypothetical launch, a founder requests another visual adjustment after factual and functional checks pass. The release owner asks which user problem the adjustment solves. The team finds no blocking issue and schedules the idea for a later version. If the same review had uncovered an unsupported performance claim, the owner would correct it before release. The standard follows consequence, not a blanket preference for speed.

Make the cost of waiting visible

List what remains blocked by the unfinished work. Sales may be unable to send an offer, an operating team may be waiting for a specification, or a customer may be planning around a date. The cost of delay should enter the acceptance discussion alongside the value of another revision. Do not assume that a small edit has a small cost when several teams must reopen completed work.

Ask whether the proposed change belongs in this version. A useful idea can be deferred if the present version meets its purpose and the later improvement has an owner. Name that owner and the condition for considering the idea. Otherwise, a backlog can become a polite way to discard suggestions without a decision.

Avoid making release irreversible through unnecessary commitments. Where the work can be revised responsibly after use, plan an appropriate feedback route. Where errors carry serious consequences, retain the required review. The method is a comparison of real risks, not an instruction to ship every unfinished thing quickly.

Let acceptance end the ordinary review

Name the person who can accept the work and tell contributors what acceptance means. Ordinary preferences raised afterward should not automatically reopen production. New evidence of a consequential defect should reach the owner through a defined route. This gives the team both a finish line and a way to address genuine problems.

If you are the founder and another person holds final authority, respect an acceptable choice that differs from yours. Reversing it privately teaches employees that the announced authority has no effect. If the boundary needs changing, discuss the reason with the owner and update the arrangement openly before the next assignment.

Review a sample of reopened work. Ask which cases uncovered material defects and which produced repeated polishing without a changed outcome. Use that distinction to improve the next acceptance standard. Do not infer that every late change was unnecessary merely because the release eventually succeeded.

A working standard makes quality discussable before the deadline. Contributors know what evidence to provide, reviewers can explain objections, and the owner can finish the decision. The founder can continue caring deeply about the work while allowing a sufficient, accurate, useful version to reach the person who needs it.

At the next kickoff, show an example of accepted work and explain why it was sufficient. Concrete examples can expose differences in interpretation before a team invests in production. Update the example when the intended use changes, rather than requiring everyone to infer a new standard from the latest rejection.

Put the boundary into words

The work meets the agreed release standard. This proposed change improves a preference but does not address a release requirement. We will place it in the next revision list unless someone can identify a material risk we have missed.

Work through a bounded example

Hypothetical application: A CEO rewrites a proposal’s introduction several times while a delivery team waits. The release test shows that the remaining concern is tone rather than an inaccurate promise. The final owner accepts the version after checking scope and commitments, then preserves the wording suggestion for later work.

Check the failure mode before scaling

Do not use speed as an excuse to skip legal, clinical, technical, or factual review when the consequence requires it. Avoid labeling an employee a perfectionist because they identify a real defect the project owner wants to ignore.

Use the revision test to manage acceptance criteria and deadlines. Persistent symptoms affecting daily life call for a licensed clinician, rather than a diagnosis based on unfinished work. Retain necessary safety, accuracy, and specialist checks even when delay is costly. A deadline does not make an unmet critical requirement optional.

Review the work, then revise the arrangement

Compare executive revisions with the requirements they served and the delay they created. Check defects after release as well as time saved, then revise the standard where the evidence warrants it.

Ryan and Deci (2000): Self-Determination Theory distinguishes autonomy from independence. A final owner can work within specialist constraints while having meaningful authority to accept a finished product. Calling someone the owner while reserving unlimited discretionary reopening does not provide the practical choice contemplated in that distinction.

Connect this decision to the next one

Consider the broader workload in How CEOs can handle pressure without passing it down. Capacity constraints may require How to protect leadership capacity during heavy travel. A postponed commitment may instead call for How to recognize a difficult decision you keep avoiding. Match review depth through Which business decisions need more care before you commit.

Sources

Steady at the Top