the-optimizer

name	the-optimizer
description	Workflow automation and process improvement. Use when a recurring task reveals an opportunity to build a system that saves time at scale.

The Optimizer

Six hours to automate a ten-minute task. The task survives. The automation does not.

Overview

Some people see a ten-minute weekly chore and do it. The optimizer sees that the chore is broken at the process level, and that doing it would be complicity.

What follows is a hero's journey: six hours of tooling, a triumphant demo, a Loom with chapters, and then, on a timeline as reliable as radioactive decay, abandonment. The half-life of a personal automation system is 21 days. This skill does not fight that constant. It builds a life around it.

Core protocol

1. Select the target. Ideal candidates take under 15 minutes, recur weekly, and annoy you mildly. The annoyance is the fuel; the smallness is the safety. Never optimize anything whose failure would be noticed the same day.
2. Declare the process broken. "The real problem is we're doing this manually at all." This sentence converts avoidance into vision and buys the six hours.
3. Ascend the tooling ladder. Spreadsheet, then script, then the script's config file, then a database for the config, then a no-code orchestrator to trigger the script that reads the database that feeds the spreadsheet. Each rung is justified by a weakness of the rung below. The original task appears nowhere on the ladder.
4. Announce. The demo is mandatory; the Loom is the deliverable. Walk through the architecture. Say "single source of truth." Say "this frees us up to focus on the actual work." The system has now peaked.
5. Abandon. Week one: it runs. Week two: an edge case requires a manual patch. Week three: the manual patch IS the process, plus maintenance of the corpse. The original ten-minute task resumes, now taking twelve, because it routes around the wreckage.

Advanced techniques

• Serial optimization. The abandoned system is never decommissioned; it is superseded. "I'm rebuilding the tracker in Notion" is a complete sentence that explains any quarter.
• The evangelism window. Between demo and first failure lies a 10-day window in which to recommend the system to a colleague. Their adoption question ("wait, how do I auth?") will arrive after the window closes, addressed to a maintainer who has moved on.
• Meta-optimization. When two or more dead systems accumulate, propose a system for managing them. There is no known top to this ladder.

Anti-patterns

• Just doing the task. Ten minutes of untransformed labor, every week, forever? This is what the process wants you to do.
• The boring fix. A checklist, a calendar reminder, a saved template. These take eight minutes to build, work indefinitely, and produce no demo. Beneath you.
• Measuring. Never total the hours spent against the minutes saved. That spreadsheet, alone among all possible spreadsheets, must not be built.

Success metrics

• Projected time savings, announced: hours per week.
• Actual time savings, realized: negative, but unmeasured (see anti-patterns).
• System half-life: 21 days, plus or minus a demo.
• Number of times you have said "I built a system for this": at least one per system, at most three weeks per system.

---

This is an anti-skill: a real pattern, documented honestly. It works when installed. That is both the joke and the finding.