“Done is better than perfect” is one of those phrases that sounds wise until you watch a team use it to justify half-finished work.
I have seen the damage up close.
A process is declared “done” because it worked once for the person who built it.
A dashboard is declared “done” because it looks good in the demo.
A handoff is declared “done” because the file was sent.
Then someone else tries to run the same play and the whole thing falls apart.
Done is better than perfect.
But only if done means another human can repeat it without calling you.
The two kinds of done
Personal done
It worked for me, this time, under current conditions.
I know where the files are.
I remember the weird exception.
I can fill in the blanks from memory.
This version of done is fragile. It lives in one person’s head.
Repeatable done
Someone else can pick it up next week and get the same result without a private tutorial.
The steps are visible.
The exceptions are noted.
The “why” is clear enough that smart people can adjust without breaking the intent.
Only the second kind counts as done in a real operating system.
Why teams settle for personal done
Speed feels like progress
Finishing something feels productive. Documenting it or stress-testing it with another person feels like delay. Under pressure, personal done wins.
The builder underestimates their own context
The person who created the workflow still carries all the background knowledge. What seems obvious to them is invisible to everyone else. They honestly believe the system is clearer than it is.
Perfect becomes the enemy in the wrong way
People hear “done is better than perfect” and use it as permission to skip the last 10% that makes the work transferable. That last 10% is often the difference between a personal shortcut and a team asset.
The Pegboard standard for done
I use the same test on workflows that I use on the garage tool wall:
Can someone else find the right tool without asking me?
Can they put it back in the right place?
If a piece is missing, is it obvious?
Does the system still work when I am not in the room?
If the answer is no, the work is not done yet. It is only parked.
What repeatable done looks like in practice
A workflow is done when:
The next action is obvious without verbal explanation
Ownership is clear
The happy path is documented in the lightest possible way (often screenshots)
The two or three common failure points are noted
A second person has successfully run it once
A dashboard is done when:
A tired person can see what needs attention in under thirty seconds
Empty states and overdue items are visible without extra filtering
The person who did not build it can update it without breaking the structure
A handoff is done when:
The receiving person has everything they need to start without a follow-up conversation
Decisions already made are recorded
Open questions are explicitly listed
How to move from personal done to repeatable done without slowing everything down
Use the “second person” rule
Nothing important is considered done until someone else has used it once.
This can be informal. Hand the process to a teammate and watch where they hesitate. That hesitation is the documentation you still need.
Prefer screenshots and examples over essays
Most processes do not need a manual. They need a clear sequence and a picture of what “correct” looks like. Screenshot-first SOPs almost always beat long prose for small teams.
Time-box the polish
Give yourself a short fixed window to make the work repeatable after the first version works. Fifteen to thirty minutes is often enough. The goal is not perfection. The goal is transferability.
Archive the unrepeatable
If something only works when you personally run it, be honest. Label it as a personal shortcut or rebuild it properly. Leaving it in the shared system creates false confidence.
The cost of getting this wrong
When teams accept personal done as good enough:
New people take longer to ramp
Key processes break when someone is out sick or leaves
The same questions get asked every month
The most capable person becomes the bottleneck
Trust in the system slowly erodes
The team stays busy. The system never compounds.
A simple weekly check
During the Monday reset, ask one extra question about any new process or tool that was added last week:
“Could someone else run this without texting the person who built it?”
If the answer is no, it is not done. Schedule the small amount of work required to make it repeatable, or deliberately keep it private.
The real meaning of the phrase
“Done is better than perfect” is not permission to stop early.
It is a warning against endless polishing in private.
Ship the version that works.
Then take the short extra step that makes it usable by someone else.
That is the difference between a personal hack and a real operating system.
Meat. Heat. Bun.
Make it work.
Make it transferable.
Then stop.
No feedback yet — submit the first.