Who's working on what? Answering it without a meeting

It is Tuesday morning and a client wants a landing page by Friday. Before you can say yes, you need to know one thing: who has room this week? So you ask in Slack. Two people reply within the hour, one is in a workshop until three, and by the time you have the full picture the answer has cost you half a day plus the status meeting you scheduled just to be sure.

"Who's working on what?" is the most common question in a small team, and in most tools it is the most expensive one to answer.

Why your project tool can't tell you who's working on what

Most project tools, Asana and Trello among them, organise work by project. Generalise so it holds for both named tools, e.g. "Open the tool and you see projects: one per client, each with its own lists or boards, each with its own tasks." Or attribute the boards/cards shape to Trello alone. The information you need exists in there somewhere. To assemble it you open six boards, filter each by assignee, hold the results in your head, and hope nobody edits anything while you count. That's why the standup survives. The meeting is a workaround for a data model: when a tool files work under projects, the only place the per-person picture exists is in everyone's mouths, once a day, for fifteen minutes.

Guesswork fills the rest. He seems busy. She didn't push back, so she must have room. Seeming busy is not data.

Put the task on a person and a day

The structural fix is small. Give every task two coordinates: a person and a day. Once every task carries those two coordinates, one grid can answer the question. Rows are people, columns are days. Scan a row and you get someone's whole week. Scan a column and you get today across the team. Nobody reports anything, because the plan itself is the report.

This is how ToDoing's Overview works. The whole team's week sits on one grid, and you can flip the rows from people to projects when a client asks the same question the other way round. Milestones sit on the same calendar as the tasks feeding them, so a deadline that is quietly slipping shows up days early, while there is still time to move something. If a task needs to move, you drag it: to another day, or to another person. Edits reach everyone in under a second, so the grid you are looking at is the grid your team is looking at.

There is no second system to maintain. Each person plans their own week in My Week; the Overview is the same data seen from above. The two views cannot drift apart, because there is nothing to sync. (Anyone who has kept a resourcing spreadsheet beside a task tool knows exactly what drift costs.)

Reword to something sentence-cased and searchable, e.g. '## What changes when capacity is visible' or '## When the week is visible, the quiet overcommit dies'.

Something else happens when capacity becomes visible. The quiet overcommit dies.

In most teams, overload stays invisible until it turns into a missed deadline. Someone accepts a fourth project because refusing would mean proving they are full, and there is nothing to point at. On a grid, a full week looks full. When a new task lands on Thursday, everyone can see Thursday already holds three. The conversation shifts from "can you squeeze this in?" to "which of these moves?". The second question has an answer.

It works in both directions. Managers stop over-assigning because the evidence sits in front of them, and quieter team members stop silently absorbing because they no longer have to argue from memory. Work that has no date yet goes to the Someday column, one click from a real slot.

We wrote elsewhere about why the week is the right planning unit; the short version is that a week is small enough to be honest about. ToDoing is free for three people and three projects, and at the time of writing five people cost $10 a month after that.

Next Tuesday, when the client calls, look at the grid.