A task list can tell you everything except what matters

Open any team's task tool and you will find the same thing: a long list, mostly accurate, sorted by something nobody chose. Due date, if you are lucky. Creation order, if you are not. Everything on it is real work. Almost none of it is labelled with why it is worth doing.

So the ranking happens somewhere else — in a manager's head, in a Slack thread, in the ten minutes before a standup — and then it evaporates, and next week someone does it again from scratch.

This is not a discipline problem. The list genuinely does not contain the information needed to sort itself.

Priority fields do not fix this

The usual answer is a priority field. High, medium, low. Within a fortnight everything urgent is High, the field stops discriminating, and you are back to sorting by due date.

The reason is that "high priority" is not a property of a task. It is a relationship between a task and something the team is trying to achieve. Store it as a property and you have written down the conclusion while throwing away the reasoning — which means nobody can check it later, and it silently goes stale the moment the goal moves.

Objectives are the missing half

The context a list needs is the objective the work serves. Not in a strategy deck, not in a quarterly planning doc — attached to the task itself, where the person deciding what to do next will actually see it.

That single link does a surprising amount of work:

Sorting becomes explicable. "This first, because the objective it belongs to is behind" is an argument someone can disagree with. "This first, because it is marked High" is not.

Neglect becomes visible. An objective with no tasks linked to it is a goal nobody is working on. That is usually true for at least one objective per quarter, and it is nearly impossible to notice when goals and work live in different tools.

Progress stops being self-reported. If tasks roll up to key results, progress is arithmetic. The moment you instead ask someone to type a percentage into a form each Friday, the number becomes a negotiation.

And then it has to survive contact with a meeting

Here is where most of this falls apart in practice. The objectives are set, the tasks are linked, and then the team has its weekly review — and the decisions from that meeting land in a notes doc that nobody opens again. A fortnight later the work has not happened and nobody is sure whose it was.

So we made the meetings read from the same tasks. A team review builds its agenda from objectives, worst-first. A 1:1 opens with what is still outstanding from every previous 1:1. And a follow-up agreed in either becomes a real task, with an owner and a date, on the board the team already works from — because there is nowhere else for it to go.

None of that is clever on its own. It only matters because it means there is one list, and it is the list everybody is already looking at.

What we deliberately did not build

Deciding what a tool is includes deciding what it is bad at.

We do not do project management: no Gantt charts, no dependency graphs, no resource levelling. If you are running a construction schedule, buy Monday.

We do not join your calls. No transcription, no recording, no AI notetaker. Granola and Fathom are good at that and we would rather point you at them.

We do not do performance management. No review cycles, no calibration, no compensation planning. That is an HR system's job, and building it would change what a 1:1 here is for.

And we removed our AI inbox, which we wrote about at the time.

What is left is a task manager for teams, with the two things a task list cannot supply on its own: a reason each item is on it, and a cadence that keeps it honest.