← All postsHow-to

Due date: setting deadlines people actually meet

A due date without an owner and a consequence is a wish. How to set dates that hold, what to do when one slips, and why most overdue lists are ignored.

How-toD

Teams rarely have a deadline problem; they have a dates-nobody-agreed-to problem. A due date assigned to a task in a system, without the person who has to do it being asked, produces an overdue list that everybody learns to scroll past — and once a list is routinely ignored, the dates on it stop carrying information of any kind.

What makes a due date hold

  • One named owner who agreed to it out loud, rather than a date entered on their behalf.
  • A date set by the person doing the work, not by the person who wants it done.
  • A size the date can plausibly contain — most missed dates are estimation failures, not effort failures.
  • A visible consequence of missing it: something downstream that waits, somebody who is told.
  • A reason it is that date rather than another, which is what makes it worth defending when something else arrives.

Why overdue lists stop working

Because they fill with items nobody intends to do. Every list accumulates tasks that were a good idea once, were given a date out of optimism, and are now three months overdue with no consequence attached. People learn, correctly, that the list is not a commitment — and from that point the genuinely urgent item is invisible among forty stale ones. Cleaning that list is more valuable than chasing anything on it: either give an item a new date somebody agreed to, or close it as not being done.

Treat a date change as normal and a silent slip as the problem. A task re-dated with a reason is information; a task that quietly goes red is somebody hoping nobody looks, and the second behaviour is learned from how the first one is received.

When a due date slips

  1. Say so before the date, not after it. Everything that makes lateness expensive happens downstream, and downstream needs warning.
  2. Re-date it once, with a reason, rather than letting it drift unacknowledged.
  3. Check whether the task is actually smaller than it looked — frequently the honest answer is that it was never a one-day job.
  4. If it slips twice, ask whether it is going to happen at all; two slips usually mean it is not a real priority.
  5. Close what is not going to be done. An explicit no costs far less than a date that is quietly carried forever.

Fewer dates, meant more

The most effective change most teams can make is to stop putting dates on things that do not need them. Dates belong on work with a dependency or an external commitment; everything else can sit in a prioritised list without a fictional deadline. A short list of dates that are real beats a long one where red means nothing, and it takes a deliberate clean-out to get there because removing a date feels like lowering a standard.

Ettex Board keeps the date beside the owner and the column, so overdue is visible in the place the work already lives rather than in a separate report. Where the commitment is external rather than internal, the date belongs in a register with the evidence beside it instead of on a card.

Frequently asked

Who should set the due date?

The person doing the work, agreed with whoever needs it. Dates assigned without that conversation are the main source of overdue lists nobody reads.

What should happen when something is late?

It should be re-dated once with a reason, before the original date where possible. Silent slippage is the behaviour to discourage, not the change itself.

Should every task have a due date?

No. Dates belong where something or somebody depends on them. Dating everything is how red stops meaning anything.

MI
Written by Maria I.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.