Ownership vs. whose move: what task management software misses

Monday stand-up. The CEO asks about the new packaging launch: why is it stalled? The owner is the product engineer, and that’s right there on the task. The engineer says, “I’m waiting on marketing to approve the artwork.” Marketing says, “We sent it to legal to check the labeling.” Legal says, “Nothing ever reached me.” Twenty minutes go into figuring out where the work is. The answer is nowhere. It fell between people, even though it had an owner the entire time.

This is the biggest blind spot in most task management software. A task has an “assignee,” and that feels like enough. But who owns it and whose move it is are different questions. The owner is responsible for the whole outcome. The move belongs to whoever needs to act right now, which might be a different person, a different team, or simply “whichever lawyer is free.”

Owner and move: what’s the difference

Think of a relay race. The team and its captain are responsible for the result. But at any moment, the baton is in one runner’s hand. Ask “who’s responsible for this race” and you’ll learn the captain’s name. Ask “who has the baton” and you’ll learn who’s running right now. To understand why the team has stopped, you need the second question.

In TASKUS task management, every task answers both:

• the owner is a permanent role, accountable for the outcome and following the task from start to finish;
• the ball marks who is expected to act right now, and it moves from person to person as the work progresses.

In the packaging example, the engineer owns the task end to end. The ball, though, went to marketing and was supposed to move on to legal. If the handoff had gone through the ball, one look would have settled it at the stand-up: the ball has been with marketing for six days, and nothing was ever passed to legal. Ten seconds, question answered.

How the ball works

Pass it to a person, a team, or a role

You don’t have to hand the ball to a specific name. You can pass it to:

• a person: “Olivia, please check the numbers”;
• a team: the task lands in the legal team’s inbox, and whoever’s available takes it;
• a role: “need a lawyer,” “need the controller.”

That last option matters for any company where people take vacations, get sick, or move on. A process tied to a role survives one person leaving.

Every handoff is a step with a note

You can’t pass the ball silently. Every handoff is a step with two short fields: what’s done and what the next person needs to do. A month later, the task shows the full trail of steps: who did what, and when they passed it on. Nobody has to reconstruct the story from chat history.

Parallel branches

Sometimes several people hold the move at once. Say the artwork needs review from both legal and finance. There are three modes for that:

• all: move on once everyone has responded;
• any: one response is enough;
• quorum: a set number of responses is required.

The ball can’t get lost

The worst failure is a task where nobody has the move. It doesn’t show up in anyone’s “today,” and it quietly dies. So the ball in TASKUS is built not to go missing:

• change the owner, and the ball follows the new owner, unless someone deliberately passed it to a third person;
• reopen a closed task, and the ball returns to the owner;
• remove someone from a task, and their ball goes to the owner, or to the requester if there is no owner.

A task nobody accepted isn’t a task yet

The second big source of chaos is work that was assigned but never accepted. The requester assumes it’s underway. The assignee never even opened it. A week later it turns out the task was “somewhere in the list.”

In TASKUS, a new task has an explicit acceptance step: Accept or Send back with a question. You can do it from the task card, from My Tasks, or straight from the Telegram notification. When someone accepts a task, four things happen together:

1. if that project’s rules say the assignee sets the due date, you can’t accept without one;
2. acceptance is recorded for that person, so with several owners, each accepts for themselves;
3. the ball moves to whoever accepted;
4. the task moves to In Progress and the requester gets notified.

A task that’s “in progress with me” glows gold in every view: list, kanban, Gantt chart, and canvas. Submit it for review and the ball leaves, so the glow goes out. Get it sent back and it lights up again. At the top of My Tasks there are always two sections: “New, waiting for you to accept” and “In progress now.”

Who sets the due date

Another argument that eats time is who decides when something will be ready. In TASKUS it’s a project setting. In one project the requester sets the date, in another the assignee does, in a third the manager. When the assignee sets it, the requester’s date is recorded as the latest acceptable date, and the assignee commits to their own. A due date can only be moved with a reason and the requester’s agreement. Promises become commitments instead of wishes.

Review and sign-off: the final move

Work isn’t finished when someone clicks Done. If the person who hands it in isn’t the person who requested it, the requester’s approval closes it. The assignee attaches a report and files, and the requester decides whether to accept it or send it back with a reason.

At that point, the ball is with the requester. That matters, because the bottleneck is often the reviewer, not the doer: work submitted a week ago that the manager hasn’t gotten to. The system makes that just as visible as anyone else’s delay. The Assistentus personal assistant, for example, pings you during the day specifically when work is waiting for your sign-off. More on that in 12 Assistentus scenarios.

Team inboxes and role-based routes

When the move belongs to a team

A task assigned to a team lands in that team’s inbox. From there, a manager can hand tasks out, an employee can claim one, or the manager can hit “give it to whoever’s least busy.” If nobody picks a task up within four hours, the team lead gets an alert.

When someone leaves the company, their tasks don’t hang on an empty seat. They go back to the team inbox. TASKUS takes who’s on which team and who reports to whom from the TEAMUS org chart, so permission to assign work follows the org chart too.

Routes that survive turnover

Many processes repeat. A contract goes from sales to legal, then finance, then the CEO. In TASKUS you can save that chain as a route built on roles and teams, not names. If your lawyer leaves, the route doesn’t break. The move simply goes to the new lawyer. The system also spots chains that keep repeating and suggests saving them as routes.

While you were away

The ball really pays off after you’ve been out. You come back from an offsite or a trip, and normally two hundred notifications are waiting, of which maybe ten matter. In TASKUS, after more than four hours away, you get a catch-up view. At the top is everything where the ball is yours: tasks waiting on your action, work awaiting your sign-off, items sent back with a question. Below that is what changed in tasks you’re part of where it isn’t your move.

That’s a meaningful difference. Instead of a chronological event feed, you get a list ordered by responsibility: first what’s blocked without you, then what’s simply good to know. Five minutes and you’re caught up, without scrolling through everything.

What it looks like in practice

Here are two ways to answer “why are we stuck”:

Question	Assignee field only	Owner + ball
Who’s responsible for the outcome?	Visible	Visible
Who has the work right now?	Unknown, you have to ask	Visible at once, with handoff date
What happened at the last step?	Somewhere in chat, if you’re lucky	In the step trail
Did the assignee accept it?	Unknown	Visible: accepted or sent back
Who’s the bottleneck, doer or reviewer?	A debate at the meeting	Visible from the ball
What if someone leaves?	Their tasks hang	They return to the team inbox

Where to start

If you’re moving to TASKUS from another tool, don’t try to rebuild every process on day one. Three steps for the first week:

1. Agree on acceptance. Every new task gets accepted or sent back with a question. “I saw it” doesn’t count.
2. Pass the ball instead of posting in chat. “Passed to legal: artwork is final, labeling needs review.” One handoff replaces three messages.
3. Pick a due-date rule for each project. In some, the manager sets dates. In others, the assignee does. What matters is that everyone knows who.

Within a couple of weeks, “where is this stuck?” gets answered with a single glance at Monday’s meeting. Abandoned work shows up even sooner: in the GARDUS task garden, only the plant of whoever holds the ball dries out. We explain why in GARDUS: why abandoned work should wither.

Setting up projects, due-date rules, and routes is part of the 14-day PRANUS implementation, and the implementation agent does it with you in conversation. To see the ball moving through your own company’s tasks, book a demo.