4. The Secret to a Work System That Never Goes Stale
Here’s something that doesn’t get talked about enough in productivity advice:
Most systems don’t fail because they were wrong at the start. They fail because reality changed and the system didn’t keep up.
You built something that worked. Then your situation evolved, or your schedule changed, or your client needs shifted — and the system that used to be so helpful is now like a phone that’s so old it spends more time updating than charging. Slowly, quietly, its usefulness has faded. And one day you noticed you weren’t using it anymore.
This isn’t a failure of the system. It’s a failure of maintenance. And the good news is it’s entirely preventable.
The essence of Agile: observe, adjust, repeat
In Agile methodology — the framework I’ve worked in for 20 years — there’s a foundational practice called the retrospective. At regular intervals, the team pauses and asks: what’s working, what isn’t, and what should we change?
Not once, at the beginning. Repeatedly, as a built-in part of the process.
The insight behind it is simple but powerful: you cannot accurately predict in advance how things will go. Plans made at the start are based on incomplete information. Also: everything you do creates new (and important) information. The only way to build something that actually fits reality is to watch what happens and adjust accordingly.
This applies to work systems just as much as it applies to software development.
Most people are terrible at predicting their own behavior
When setting up a new system, most people plan based on how they imagine they’ll work — not what actually happens once they start working..
They set a weekly review, then discover monthly works better. They create five categories, then find they only use two. They build in a daily check-in, then realize it’s too frequent to sustain.
None of this is failure. Just information.
The mistake is treating the initial setup as fixed — something to comply with rather than something to refine. A system designed to be revised is fundamentally more durable than one designed to be perfect.
The review questions that keep a system alive
In the Gmail lead-tracking system I described in the last post, the review step includes a question that might seem small but is actually doing a lot of work:
Does this label still fit?
That question is an invitation to observe rather than comply. It’s asking: is this system still an accurate reflection of how your business works right now? Or has reality moved on without you noticing?
Some other questions worth asking during any system review:
Is the timebox realistic? If you set a weekly review and keep skipping it, weekly is probably wrong for you right now. Monthly might be more honest. There’s no right answer — there’s only what you’ll actually do.
Are the categories still meaningful? Labels, folders, tags — whatever your system uses — should map to decisions you actually need to make. If a category never gets used, it’s adding overhead without adding value. Remove it.
Is there anything the system isn’t capturing that it should? Sometimes a system that was right six months ago is missing something your business now needs. A new service, a new type of contact, a different stage of the client journey. The review is where you notice the gap.
What’s causing friction? If there’s a step you keep avoiding or forgetting, that’s not a discipline problem — it’s a design signal. The system is telling you something needs to change.
What’s the fatal flaw of your system? Take the quiz and find out!
Iteration is what makes this sustainable
Here’s the thing about an iterative approach: it’s forgiving in a way that static systems aren’t.
An iterative process can survive when everything else doesn't because it's a circle. You cannot get lost in a circle. (This concept isn’t from software BTW, it’s a feature of the natural world.) A bad week doesn't mean starting over — it means rejoining the loop at whatever point you left it. Then the next review cycle absorbs whatever needs catching up.
The repetition of the process essentially polishes the system over time, wearing away the things that don’t work and accumulating whatever does.
This is why I’d rather have a “good enough” system that gets reviewed regularly than a sophisticated system that might be abandoned. The review is the mechanism that turns “good enough” into genuinely useful.
It’s also why recovery matters more than consistency. A system you can restart easily is more valuable than one that requires you to never stop.
Trust the system to tell you what needs to change
You don’t have to figure out in advance what will work. You just have to pay attention to what’s actually happening and be willing to adjust.
The system will tell you. A category that doesn’t get used. A review that always gets skipped. A step that irritates you every single time. Those aren’t signs that you’re doing it wrong. They’re your system communicating what it needs.
Listen to it. Adjust. Repeat.
That’s the whole practice. And it’s what keeps a work system alive indefinitely — not perfect design at the outset, but honest observation over time.
In the final post in this series, I’ll get personal: what ADHD taught me about building systems that work for everyone, and why the methods developed for neurodiverse people also turn out to be better for most people.
Amy Lightholder is an Agile and ADHD coach who helps neurodiverse professionals and solopreneurs build work systems that survive real life. She speaks to small business groups on lightweight, resilient systems for lead tracking and productivity. Learn more at Agile4ADHD.com.
