Done

How do you know when your work is actually “done”?

Ask an architect, an engineer, or a creative, and you’ll notice something surprising:

“Done” is rarely a property of the work itself.
It is a judgment produced by the system around the work.

Humans don’t possess a built-in detector for completion. Instead, we rely on a patchwork of external signals:

• Specifications & Criteria: Did we meet the explicit requirements?
• Testing & Validation: Did it pass the automated or manual checks?
• Deadlines & Risk: Does the schedule force a stopping point?
• Diminishing Returns: Is further refinement worth the added effort?

In almost every field, completion doesn’t emerge from the output itself—it comes from the external boundary conditions we set.

If your team struggles with endless iteration or scope creep, the issue usually isn’t the quality of the craft. It’s that the system surrounding the work hasn’t defined what “done” looks like.

How does your team decide when a project is truly finished?