Due Date

Back when a list of work was only a list, the longer it got the less it told you. Open a thirty-line list in the morning and nothing in it says which line belongs to today. Working top to bottom feels reasonable until you notice the top item is simply the one someone typed first, while an item tied to next week's contract sits near the bottom.

So the urgent things traveled by voice instead. Someone would stop by a desk, say "that one's due Friday," and leave. From then on only the people who heard it knew the date. When one of them went on vacation the date went with them, and Monday brought a conversation that started with "this was supposed to be done last week." The commitment existed. There was just nowhere it lived.

A due date moves that sentence inside the item. The date stays after the person who said it walks away, and the tool can read it and reorder the list. What's urgent gets answered by the record rather than by whoever happens to remember.

Put one date on one item and the tool compares it against today, sorting that item into one of three states: still ahead, due today or within a few days, and already past. Sorting a board by date or filtering it down to "due this week" runs on that single value.

Teams that get good use out of it agree on three things first.

1. Who sets it. A date dropped in by the person handing over the work is a request, not a commitment. It holds only when the person doing the work has seen the size of the job and agreed to the date. Items with a date but no assignee are common, and nobody can answer for a date that belongs to no one.
2. What it means. Does that day mean development finishes, or that the change has been reviewed and is live for customers? Read the same twelfth of the month one way on one side of the table and the other way across it, and two full days go missing.
3. What gets left behind when it moves. Pushing a date is ordinary and often correct. Editing it quietly is the problem, because afterward nobody can tell a first slip from a fourth. One line of reasoning on each change makes the pattern readable once an item has moved four times.

One date on its own also can't describe progress. It names the finish and says nothing about where the work currently stands, so it only means something read next to a workflow status — the value that says which stage the item is in. Due tomorrow while the status still reads "to do" is late. The same date with the status at "in review" usually holds.

It belongs on work with a commitment made outside the team. A customer question logged as a ticket — one request captured as one item — carries a response deadline, and when a service level agreement (SLA) promises a first reply within 24 hours of intake, that clock becomes the date. Regulatory changes with a fixed effective date, or a feature that has to open the morning an ad campaign starts, work the same way. The team can't move any of these, so the date has to live on the item.

Internal schedules use dates too, but a level up. Rather than stamping every item, teams put the date on a milestone — a checkpoint used to confirm progress — or on a release, and hang the items off it. Move the checkpoint once and forty items move with it, instead of forty separate edits. It also keeps the dates that do exist meaningful, because each one marks something the team actually planned around rather than a guess typed in at creation time.

Teams working in fixed cycles barely use the field at all. On a two-week sprint, the end of the cycle already serves as the deadline for everything inside it. Adding per-item dates on top writes the same fact in two places, and when the cycle shifts by a day, forty dates become wrong at once. In those teams the field survives only for promises made outside the cycle.

"Why is this one due yesterday? If it's moving, leave the reason in a comment."

Calling out a date that passed with no record of what happened.

"The date says the twelfth — does that mean shipped to customers, or just merged?"

The team hasn't agreed on what the date marks as complete.

"Drop the date on this and just raise the priority. We haven't promised it to anyone."

With no outside commitment, order is a better tool than a date.

Not many Pagedeck items carry a date. Most of the board runs on sprint cycles with the field left empty, and dates appear only on the work Sofia has committed to an enterprise customer and the work Ravi has to land alongside a campaign. Theo scans the dated items first, which works precisely because the column is mostly blank.

It wasn't always like that. During a quarter when every item got a date, half the board glowed red, and within a few weeks nobody read the red anymore. Mia cleared the field entirely and added it back only for externally promised work, which turned the marker back into a signal.

The first assumption is that dating everything makes a team move faster — dates create pressure, blank fields invite drift. It runs the other way in practice. Give all hundred items a date and thirty of them are past due at any moment, and on a screen showing thirty overdue items permanently, red stops being information and becomes background. The one item with a contract behind it sits in that same red and nobody picks it out, and the miss usually surfaces from the customer's side rather than from the board. Dates work in inverse proportion to how many you hand out.

The second is reading a due date as a priority. Both influence what gets picked up next, so they blur together. But a date says when, and a priority says how much it matters. A minor reconciliation task due next week should still lose to an undated payment bug. Order the day by dates alone and work that looks urgent keeps pushing out work that is important. That gap is why tools carry a separate priority field alongside labels rather than letting the calendar decide.