Complexity is a loan against future maintenance
Every calendar, color, category, and connected tool is a small standing obligation: something to keep current, consistent, and true. Systems fail when the sum of those obligations exceeds the attention the system saves — at which point the apparatus starts consuming its own dividend. The insidious part: complexity arrives in reasonable-sounding single steps ("a calendar just for errands!"), and nobody audits the running total.
The eight signs
- Filing hesitation: creating an event requires deciding which of five calendars it belongs to — and you sometimes get it "wrong". Taxonomy that demands thought at capture time is taxonomy working against you.
- Color archaeology: you cannot state, from memory, what all your colors mean. Meanings you must look up are meanings that stopped informing.
- Sync babysitting: any regular ritual of checking whether tool A still reflects tool B — the definitional symptom of one tool too many.
- The system backlog: a standing to-do like "reorganize calendar categories" that recurs quarterly. Systems needing scheduled reorganization are hobbies.
- Ghost layers: calendars nobody has written to in a quarter, still subscribed, still rendering.
- Duplicate entry: the same commitment typed into two systems (calendar + planner app + team tool) because no single one is trusted.
- Onboarding dread: you couldn’t explain the system to a colleague in two minutes — which also means you re-derive it under load.
- The load-bearing fiction: at least one component exists because deleting it feels like admitting the time spent building it was wasted. (It was; sunk costs don’t schedule anything.)
Why it creeps: three honest drivers
Naming the driver picks the descent path. Anxiety-building: elaborate systems as control rituals over overwhelming demand — the fix is subtraction upstream (load), not better categories. Tool enthusiasm: each new app’s onboarding adds a layer that outlives the enthusiasm — the fix is the one-in-one-out rule. Inherited structure: the system still shaped like a job, project, or life you no longer have — the fix is the quarterly question "what would I build today, from zero?"
The descent path (one hour)
Simplify by rebuilding, not pruning: pruning negotiates with every existing piece; rebuilding starts from the floor. The floor is: one primary calendar (plus work/personal split only if account ownership demands it), four colors with sayable meanings, one glance surface + the native web app, and events limited to true commitments. Migrate forward only what the floor demonstrably lacks after two weeks — most people re-add one layer (a shared family calendar, usually) and discover the other five were the hobby. Keep the exported .ics of the old world as the security blanket; nobody ever opens it, which is its own lesson.
A simplified system has a definitive test: the two-second glance. If a toolbar strip — Calendar Extension for Google Calendar™ renders one in a click — shows your day and you understand it instantly, without color-decoding or layer arithmetic, the system is right-sized. Complexity always announces itself first at the glance layer.
Frequently asked questions
Yes: complexity that mirrors external structure (six clients = six calendars a consultant bills against) earns its maintenance. The audit target is internal taxonomy — categories serving self-image rather than decisions. The test is per-layer: name the weekly decision this layer changed. No answer, no layer.
Freeze the shared interfaces (the family calendar, the team layer stays), simplify unilaterally behind them, and propose shared-layer changes as experiments with revert dates. Most shared complexity turns out to be one person’s architecture that others tolerated politely — the proposal often lands as relief.
Export everything (.ics) before consolidating, then merge-import what has lookup value into the survivor calendar — past events carry no maintenance cost. The instinct to preserve structure for history’s sake confuses the archive with the architecture; keep the data, retire the scaffolding.
With a job description: the layer returns with a named decision it serves, a sayable rule for what goes on it, and the one-in-one-out payment if it is a subscription. Layers that can’t fill in the job description were nostalgia — give it another two weeks.