Retire workflows inactive for 60+ days (unless seasonal/event-triggered) — inactive workflows are maintenance debt without value
Retire workflows that have not been executed in 60+ days unless they are seasonal or event-triggered, as inactive workflows accumulate maintenance debt without providing value.
Why This Is a Rule
Every documented workflow has a maintenance cost: it takes mental space in your system, requires periodic review (Three review altitudes: weekly (execution), monthly (portfolio), quarterly (strategic) — each catches different kinds of drift), and creates cognitive overhead when scanning for the right workflow to use. Workflows that haven't been executed in 60+ days are paying this cost without producing any value — they're the process equivalent of dead code in a codebase.
The 60-day threshold is chosen because it's long enough to exclude temporarily paused workflows (vacation, project hiatus, seasonal dip) but short enough to catch genuinely abandoned ones. If a workflow hasn't been useful in two months of normal activity, the probability it will be useful again is low enough to justify retirement. The exceptions — seasonal workflows (tax preparation, annual reviews) and event-triggered workflows (incident response, onboarding new team members) — have legitimately long intervals between executions by design.
Retirement doesn't mean deletion. It means moving the workflow to an archive where it doesn't clutter the active portfolio but can be retrieved if needed. The archived workflow preserves the knowledge in case the context changes, but it no longer occupies active system space or demands review attention.
When This Fires
- During monthly portfolio reviews (Three review altitudes: weekly (execution), monthly (portfolio), quarterly (strategic) — each catches different kinds of drift) when checking execution status
- When the workflow system feels bloated with unused documentation
- When scanning for the right workflow is slow because there are too many options
- When you're maintaining workflows "just in case" without evidence they'll be needed
Common Failure Mode
Workflow hoarding: "I might need this someday" keeps dozens of unused workflows in the active system, each adding cognitive overhead and review burden. The sunk-cost fallacy applies — you invested time creating the workflow, so retiring it feels like wasting that investment. But the cost of maintaining unused workflows exceeds the cost of recreating them if they're ever needed again.
The Protocol
(1) During monthly reviews, check the last execution date of each workflow. (2) Flag any workflow not executed in 60+ days. (3) For each flagged workflow, classify: Seasonal/event-triggered (expected long intervals) → keep, but tag with the expected trigger so it's reviewed in context. Abandoned (no reason to expect future use) → retire to archive. Uncertain → set a 30-day deadline. If not executed by then, retire. (4) Move retired workflows to an archive folder/tag — not deleted, just out of the active portfolio. (5) If you later need a retired workflow, restore it. The restoration rate is a signal: if you're frequently restoring, your 60-day threshold may be too aggressive. If you never restore, your portfolio was bloated.