The problem with letting people mark their own work done

Open any task tool your company has used in the last fifteen years and you will find the same control: a checkbox, a status dropdown, a progress slider, that the person doing the work can operate by themselves. One click and the task is done. Nobody else is involved.

This is so normal that it is hard to see as a decision at all. But it is a decision, and very nearly everything managers dislike about their project tooling follows from it.

The dashboard problem, stated precisely

Ask a manager whether they trust the completion figures on their own board. Most will say something like “broadly”, and then describe the work-arounds: they spot-check the important ones, they know which two people mark things done optimistically, they ask in the stand-up anyway.

That hedging is rational, because a self-reported status is not an observation. It is a claim, made by the only person with an incentive for it to be true, with nothing between the claim and the record.

A number that one person can set alone is not evidence. It is an assertion that happens to be stored in a database.

And here is the cost, which almost nobody attributes to the right cause. Because the dashboard is an assertion, it cannot replace the conversation that verifies assertions. So the status meeting survives. You bought the tool specifically to stop having the meeting, you still have the meeting, and you conclude that the tool did not work.

The tool worked exactly as designed. The design was wrong.

The alternative is one extra party, not one extra process

The fix is structural and quite small: separate the person doing the work from the person accountable for it, and make progress a two-party event.

In Axgenta, an assignee cannot move a task's status or progress directly. They submit a request. The owner approves it, approves it with a modification, or rejects it with feedback. The owner — one person, usually the reporting manager — can change things directly, because the whole point is that somebody is accountable for the number.

Two details make this hold up in practice rather than in theory.

It is enforced by the server, not by the interface. A performer calling the progress endpoint directly gets back 403 Forbidden. This matters because a rule that only exists in the UI is a convention, and conventions erode. A rule the backend refuses to break is a property of the system.

Authority follows the task, not the org chart. A director who is merely an assignee on someone else's task submits requests like anyone else. A junior member who owns a task holds full owner authority over it. This removes the most common political failure of enterprise tooling, where seniority silently overrides process and the audit trail stops meaning anything.

What you get, beyond a tidier board

• Every advance was vouched for by a second human. The figure on the dashboard is a two-party agreement. That is a different kind of object from a self-report, and it is the reason you can act on it without checking.
• The vouching is timestamped and permanent. Which turns performance conversations from “I feel like you've been doing well” into a record neither party has to reconstruct from memory in November.
• The employee gets something they usually have to manufacture. A defensible account of what they contributed, assembled as a by-product of working, rather than written in a rush before a review.
• The scoring layer above it becomes meaningful. If completion is self-declared, every number built on top of it inherits the same softness — including your objectives.

Now the cost, because it is real

It adds a step. That is not a presentational concern to be minimised; it is the actual trade-off and it deserves to be stated plainly.

Specifically: an owner who sits on the approval queue blocks their team. If your managers are already overloaded, or your management layer is thin, the queue becomes a bottleneck and the tool will get blamed for it. We think that is the honest risk of this design, and it is worth knowing before you adopt it rather than in week three.

Three things make it survivable, in order of how much they help:

• Treat clearing the queue as the habit, not the software as the fix. One pass before your first meeting of the day. The single adoption metric worth instrumenting is whether managers actually do that.
• Make queue health visible upwards. A department whose approvals average three days should be a number a director can see. That is a management problem surfacing, which is genuinely useful information — not a product failure.
• Reject with a reason. A rejection with no explanation creates a painful loop. “Missing the Q3 variance column — resubmit when that section is done” costs ten seconds and saves days.

Who this genuinely does not suit

Some honesty is in order, because this design is not universally correct.

If you are eight people in one room, the approval split is overhead you do not need — you already have verification, it is called sitting near each other. If your organisation is deliberately flat and treats the absence of managers as a cultural commitment, this will read as an attack on that, and it more or less is. And if your managers are not going to manage, no enforcement mechanism will produce accountability; it will just produce a slower version of the same problem.

What it suits is the situation most companies between thirty and five hundred people are actually in: a real management layer, work that spans people who cannot see each other, and a dashboard that nobody quite believes.

And it is worth saying the uncomfortable version out loud, because it is the honest one. Yes, this requires your managers to manage. That is not a side effect to be apologised for. A tool that lets an absent manager look present is a tool that produces dashboards nobody believes — which is precisely the situation you are trying to get out of.