The tool became the work

I've probably reorganised my task system more often than I'd want to admit. I don't think that's a failure of willpower. Configuring feels like progress. It has the shape of productive work without the risk of actually doing any.

At the other end are people who've given up on tools entirely - a sticky note on the monitor, a mental list half-forgotten by lunch. They look like the opposite of the system-builder, but they're responding to the same overwhelm. One over-structures. The other opts out. Neither questions whether the complexity was necessary.

Nothing slips through

Most task tools sell the same promise: capture everything, structure it correctly, and nothing falls through. So you build the structure - goals, milestones, tasks, sub-tasks, each nested inside the last.

Then the doubt creeps in. Are your milestones at the right level - weeks or deliverables? Does the Gantt chart reflect reality or last Monday's optimism? Should that be a Task or a Sub-task? The system offers so many ways to be wrong that you stop trusting your own sense of what matters.

You're not doing your work any more. You're describing it to a machine, hoping the description is accurate enough. In some organisations, the overhead becomes its own department - entire roles dedicated to maintaining the system rather than doing the work it tracks.

Each feature that promises to organise adds another layer your work has to fit into. The questions never resolve.

Why simplicity feels suspicious

When a tool has suspiciously few moving parts, the first reaction is distrust. A flat list feels like a toy.

That instinct comes from somewhere real. Code genuinely needs layers of abstraction - thousands of interacting parts, state that compounds, failures you can't predict. But your task list isn't a codebase. The things you need to do on a given day don't warrant that structural apparatus. They got one anyway.

A tool that makes good decisions about how work should be structured doesn't need to ask you how to structure it. The absence of options isn't a limitation - it's a sign that the thinking happened before you arrived.

Complexity compounds

Features don't add up. They multiply. A priority system interacts with sorting. Sorting interacts with filtering. Filtering interacts with views. Each new capability doesn't add one decision - it multiplies the decisions already there. The overhead grows faster than the capability.

This is why complex tools feel heavy even when each feature is well-designed. The weight isn't in the parts. It's in the interactions between them. You can understand every feature in isolation and still feel lost in the combination.

Complexity accumulates one reasonable feature at a time, until the tool itself becomes the work.

What simplicity costs

Simple products aren't easy to build. Cutting a feature is harder than adding one, because you have to be right about what the tool should do instead of handing the user a choice. Every feature you remove is a bet that your judgment is better than an option. That takes research, taste, and a willingness to be wrong.

Most tools take the other path. Adding a feature is easy to justify - it satisfies the request and sidesteps the question of whether the feature should exist at all. Features accumulate. Each makes sense on its own - someone wanted it, a competitor shipped it. But the cumulative cost isn't borne by the maker. It's borne by everyone who opens the tool and has to find their way through what it became.

Someone else's thinking

The lightest tools aren't the ones with the fewest features on a spec sheet. They're the ones that absorbed the most decisions, so you never had to make them.

You open them and start working. No structure to learn, no taxonomy to maintain, no layers between you and the thing you sat down to do.

Simplicity isn't the absence of thought. It's the presence of someone else's.