My husband Jake has a simple standard for any system I bring into the house or describe from client work: if it needs a system to maintain the system, it is already too heavy. He is not anti-organization. He is anti-complexity that does not pay for itself under real conditions. Over the years his skepticism has become one of the more reliable filters I use when testing productivity tools, AI workflows, and household logistics.

I’m Audrey Whitlock. I live in Denver with Jake, our kids Noah and Sophie, and Cooper the golden-retriever mix. Jake teaches high-school athletics and coaches trail running. He grew up in Colorado Springs, spends as much time as he can outdoors, and has little patience for processes that look impressive on paper and then require constant tending. His recurring line—“If your system needs a system, it’s not a system”—shows up more often than I would like to admit, usually when I have just finished explaining a new setup.

This piece is about what his case against elaborate systems actually looks like in practice, where it has improved my own work, and where I still push back.

The Core of Jake’s Argument

Jake’s position is not that structure is useless. It is that structure has a carrying cost, and most elaborate systems underestimate that cost.

He notices when a new tool or process requires its own maintenance rituals: weekly reviews that never happen, tags that need updating, dashboards that demand attention, or rules that only work when everyone is operating at full capacity. He has watched me build clean workflows on Sunday evening and then abandon pieces of them by Wednesday when school schedules shift, work calls run long, or simply when energy is lower than the system assumed.

His standard is practical. Does the system reduce friction on ordinary days, or does it create a second layer of work that has to be managed alongside the original problems? If the second layer grows, the system has failed even if it looks sophisticated.

This perspective comes from his own work. Coaching and teaching reward preparation, but they punish over-engineering. A practice plan that cannot absorb a weather change, an injured athlete, or a last-minute schedule shift is not a good plan. The same logic, he argues, applies to productivity systems at home and in knowledge work.

Where His Skepticism Has Been Useful

I have lost count of the tools and processes I adopted and later dropped. Jake’s questions often accelerated the decision.

The maintenance test

When I describe a new system, he asks how much time it will take to keep current once the initial setup glow fades. If the honest answer is “more than a few minutes most days,” he is unconvinced. That question has killed several elaborate tagging schemes, multi-layered task systems, and automated routines that looked powerful and then demanded ongoing attention.

The interruption test

He points out that our household does not operate in uninterrupted blocks. School pickups, activity changes, and the normal background noise of family life are not edge cases. A system that only works when conditions are calm is not designed for the life we actually have. This has pushed me toward shorter capture steps, fewer required fields, and processes that tolerate incomplete information.

The “who is this really for” test

Jake has a low tolerance for systems that seem designed to impress an imagined audience rather than serve the people using them. If a workflow is more complex than the problem it solves, he calls it out. That pressure has been useful in client work as well. Teams often adopt tools that signal modernity more than they reduce friction. His filter helps me notice when that is happening.

These tests are not sophisticated. They are consistent. Consistency is what makes them effective.

Examples From Our Household

The pattern shows up clearly in family logistics.

We once tried a more elaborate shared task system with recurring chores, point tracking, and automated reminders. It looked thorough. Within two weeks the kids ignored the reminders, the points felt artificial, and the adults were spending more time managing the system than the actual household work. Jake’s comment was mild and accurate: the system had become the project. We returned to a short shared list of only the items that mattered that week and verbal coordination for the rest. Friction dropped.

The family calendar went through a similar cycle. Early versions included color codes by person, multiple layers of detail, and elaborate notification rules. Maintenance rose. Trust fell. The version that survived is simpler: one shared calendar, same-day updates by whoever learns the information, and minimal required fields. Jake did not design that version, but his repeated questions about upkeep shaped it.

Even small experiments get the same scrutiny. When I tested an AI-assisted meal planning routine, he asked only how often it would need correction and whether the correction time exceeded the time saved. On weeks when the AI suggestions required heavy editing to match actual preferences and schedules, we dropped it. On weeks when it reduced decision fatigue, we kept a lighter version. The standard stayed the same.

Where I Push Back

Jake’s filter is valuable. It is not complete.

Some systems require a modest amount of upkeep because the alternative is repeated chaos. A shared calendar needs updating. A short decision log after client calls needs a few minutes of human review. These costs are real, yet they are often lower than the cost of reconstructing context later or resolving avoidable confusion.

I also push back when the critique becomes a blanket preference for having no system at all. In client work, teams with no shared source of truth for decisions and ownership pay a high coordination tax. The solution is rarely an elaborate platform. It is usually a few clear agreements and the lightest surface that supports them. Jake’s skepticism helps keep those surfaces light. It does not eliminate the need for them.

The productive tension is useful. His default is to subtract. Mine is sometimes to refine. The systems that survive both filters tend to be the ones worth keeping.

How This Shapes the Work I Do With Clients

The same questions travel into consulting. When a team wants to adopt a new tool or expand an existing one, I now start with Jake-inspired prompts:

• What maintenance will this require once the novelty fades?

• Does it still function when people are interrupted, out of office, or operating at less than full capacity?

• Are we solving a real friction, or are we adding structure because structure feels responsible?

These questions do not forbid tools. They change the burden of proof. A system has to demonstrate that it reduces net coordination cost under ordinary conditions, not just that it is capable of impressive organization in ideal ones.

Clients sometimes resist the minimalism at first. Elaborate systems feel like evidence of seriousness. Over time most teams prefer the version that still works on the messy days. The ones that keep adding layers usually return later with the same problems plus new maintenance overhead.

What His Case Ultimately Protects

Jake’s skepticism protects attention. Every elaborate system extracts a little focus for its own upkeep. In a household and in knowledge work, attention is already fragmented by real demands. Systems that quietly demand more of it are costly even when they look clean.

His stance also protects against a particular kind of self-blame. When a complex system fails, it is easy to conclude that the failure is personal—insufficient discipline, insufficient consistency. Jake’s framing is different: the system was probably over-built for the conditions in which it had to operate. That shift is small and useful. It turns abandonment into information rather than evidence of personal shortcoming.

Will This Still Work on Tuesday?

Jake’s case against elaborate productivity systems is itself a system of sorts, but a light one. It asks whether the structure still functions when the day is imperfect. That question remains one of the clearer tests I know.

The workflows and household habits that survive both my tendency to refine and his tendency to subtract are usually the ones that remain useful on ordinary Tuesdays. They are rarely the most impressive. They are the ones people actually keep using.

Make it useful. Make it human. Make it survive Tuesday.