Annotate each output type with its half-life (hours/weeks/months/years) — calibrate investment in durability and polish to actual lifespan
Annotate each output type in your taxonomy with its approximate half-life (hours, weeks, months, years) to calibrate appropriate investment in durability, structure, and polish.
Why This Is a Rule
Different outputs have dramatically different lifespans, and the appropriate investment in quality, structure, and polish should match the lifespan. A Slack message has a half-life of hours — it's read once and forgotten. A project plan has a half-life of weeks — it guides work for a sprint then is superseded. A policy document has a half-life of months to years — it's referenced repeatedly by many people. A published article has a half-life of years — it represents you to strangers indefinitely.
Investing equal effort in all four is a misallocation: over-polishing a Slack message wastes time on something ephemeral, while under-investing in a policy document produces repeated reference failures. The half-life annotation makes this calibration explicit: when you see "Slack message: hours" next to "Published article: years," the appropriate effort differential becomes obvious.
The four broad categories — hours (messages, comments, quick notes), weeks (project plans, meeting agendas, sprint goals), months (reports, proposals, documentation), years (published works, policies, foundational references) — map to increasing levels of required investment in structure, accuracy, and polish. Hours-lifespan outputs can be rough and informal. Years-lifespan outputs require careful structure, thorough review, and polished presentation.
When This Fires
- When creating your personal output taxonomy or quality standards
- When deciding how much effort to invest in a specific piece of work
- When perfectionism is applied to ephemeral outputs or insufficient care to durable ones
- Complements Define both good-enough criteria and over-investment thresholds for each output type — cap effort to prevent perfectionism on low-stakes work (good-enough + over-investment thresholds) with the temporal dimension
Common Failure Mode
Uniform quality standard: applying "high quality" to everything regardless of lifespan. This produces beautiful Slack messages (wasted effort), well-formatted meeting notes (wasted effort), and adequate published articles (insufficient effort). The quality should be proportional to the half-life, not uniform across all output types.
The Protocol
(1) List your common output types: messages, emails, notes, plans, reports, proposals, documentation, published work, etc. (2) For each type, estimate its half-life: how long does this output remain in use before being superseded, archived, or forgotten? (3) Annotate each type with one of four categories: Hours (messages, comments, chat), Weeks (plans, agendas, status updates), Months (reports, proposals, presentations), Years (published works, policies, architecture docs). (4) Calibrate your quality investment: hours-lifespan → minimal polish, prioritize speed. Weeks → basic structure, readable. Months → solid structure, reviewed, accurate. Years → polished, thoroughly reviewed, publishable. (5) When starting any output, identify its type and half-life. Let the half-life set the quality ceiling: don't exceed the investment appropriate for the lifespan.