What to Do When a Teammate Says a Task Is Done but You Cannot Verify It

A developer says the login bug is fixed. A designer says the onboarding flow is done. A contractor says the invoice is sent. In each case you have two options: believe them, or go find out. Most managers pick the first option because the second one feels like distrust. But the choice isn't really about trust in the person. It's about whether the task was built to be checked at all.

"Done" is a claim about a state of the world. Some claims are self-evident the moment they're made — you can see the page load, hear the test pass, watch the invoice appear in the client's inbox. Others are invisible by default, and the only evidence you'll ever get is the sentence itself. The problem isn't that people lie about being done. Most don't. The problem is that a huge number of tasks are designed so that "done" and "not done" look identical from the outside.

The three ways "done" goes unverifiable

In practice, unverifiable completion tends to come from one of three habits, none of which are anyone's fault in isolation.

• No acceptance criteria was ever written down, so there's nothing to check the result against.
• The work happened somewhere you don't have access — a local branch, a personal test account, a staging environment nobody sent you a link to.
• The task description described an intention ("fix the checkout bug") rather than a state ("checkout completes for a guest user with an expired card").

None of these require a bad actor. A task can be marked complete in good faith and still be impossible for you to independently confirm. That gap is where most "is it actually done?" conversations come from — and most of those conversations feel worse than they need to, because by the time you're asking, it sounds like you doubt the person instead of the process.

Ask for the artifact, not the assurance

The fix isn't more check-ins. It's asking, at the point a task is assigned, what evidence "done" will produce — before the work starts, not after someone claims it's finished. That single change moves the awkward conversation from the end of the task ("can you prove this?") to the beginning ("what will I be able to look at?"), which is a much easier conversation to have.

A few concrete forms of evidence hold up better than a status update, depending on the kind of work:

• A link to the deployed environment where the change is live, not just the pull request that contains it.
• A screenshot or short recording of the actual before-and-after state, not a description of it.
• The specific test steps someone else can run themselves, in plain language, without needing the original author to narrate.
• The acceptance criteria that were agreed on before the task started, checked off one by one against the delivered result.
• A visible state change in a system of record — the invoice marked paid, the ticket closed on the client's side, the record updated — rather than a private claim that it happened.

None of these require special tooling. A link and a screenshot cost the person doing the work about ninety seconds. What they buy the manager is enormous: the difference between trusting a sentence and confirming a fact.

Three scenarios, same underlying fix

A backend engineer says the migration ran successfully. Without evidence, you have a sentence. With evidence, you have a query result showing row counts before and after, or a link to the monitoring dashboard where the error rate stayed flat through the deploy window. The task didn't get harder to do. It got harder to fake, in the rare case that matters, and effortless to trust in the common case that doesn't.

A designer says the new flow is ready for review. Without evidence, you have their word that they tested it. With evidence, you have a recording of someone unfamiliar with the design completing the flow without help, or a staging link you can click through yourself in under two minutes. The review stops depending on a meeting where they walk you through their own work and you nod.

A contractor says the client sign-off is done. Without evidence, you have a claim about someone else's inbox. With evidence, you have the forwarded email, or the signed document, or the client's own reply in the thread. This one matters more than it looks, because "the client agreed" is the kind of claim that becomes expensive to unwind three weeks later if it turns out to be optimistic rather than false.

Why this is a design problem, not a trust problem

If you find yourself asking one person for proof more often than everyone else, it's tempting to read that as a character issue. Usually it's a task-design issue: that person's work happens to sit in an environment you can't reach, or on a kind of task where acceptance criteria are rarely written. The same person, given a task with a deployed link and a written checklist, will produce exactly the same kind of evidence as anyone else.

This is also why a flat status field — to do, doing, done — tends to make the problem worse rather than better. It gives the appearance of visibility while carrying none of the substance. A checklist item that's ticked off tells you someone thinks it's finished. It doesn't tell you what "finished" looked like, whether anyone else reviewed it, or whether something is quietly blocked behind it. That's a large part of why a checklist task benefits from attention markers separate from status, and why a longer piece of work benefits from a written progress report instead of a percentage bar — the report is where the evidence lives, not just the verdict.

The conversation to have before the task, not after

When you hand off a task, ask one extra question: "When this is done, what will I be able to look at?" If the honest answer is "you'll have to take my word for it," that's worth fixing at assignment time — add a staging link, write the acceptance criteria, name the state change that should be visible when it's finished. It costs a sentence up front. It saves the far more expensive sentence later: "wait, are you sure this is actually done?"

The goal was never to catch people out. It's to make completion something anyone on the team can check for themselves, so the only conversation left to have is about the work itself — not about whether the work happened.