Deadlines that stay visible: how a small team stops dropping dates
Ask a founder what went wrong last quarter and you will hear about a thing that slipped. Ask what the thing was and it is almost never a task nobody did. It is a task somebody did, two weeks after the day it was needed.
That is a different failure, and it has a different fix. Nobody forgot the work. They forgot, or never knew, the date.
The thing that gets dropped is the date, not the task
In a company of ten people, work does not go missing. There are too few people and too much visibility for a whole piece of work to vanish. What goes missing is timing.
The pattern looks like this. A date gets agreed in a conversation between two people. One of them holds it in their head, because they are the one doing the work and they know roughly when they will get to it. The other one holds a different version of it, because they heard “next week” and planned on Tuesday. Neither is lying. The date simply never became a fact that both of them could point at.
At a large company this is handled by ceremony: a sprint, a project plan, a status meeting where dates are read out. Small companies skip the ceremony, usually for good reasons, and then act surprised when the thing ceremony was doing stops happening.
A date counts only when the people planning around it can see it
Here is the test worth applying to every deadline in your company: who is arranging their own week around this date, and can they see it without asking?
If the answer is “they would have to ask”, you do not have a deadline. You have an intention held by one person. Intentions are fine. They are just not something a second person can plan against.
This is why “I have it written down” is not enough. Written down where, and readable by whom? A date in a private note costs the same to read as a date in somebody’s head: you have to interrupt a person and wait.
The useful version is narrower than a company-wide dashboard and wider than one person’s memory. It is: the two or three people whose work depends on this date can look at it whenever they want, without a conversation.
Put the date on the todo, not in a second place
The most common mistake is keeping dates somewhere other than the work they belong to.
It happens by accident. The work lives in one place, because that is where work goes. The dates go somewhere else, because that other place is better at dates. Now every deadline exists twice, and the two copies start to differ the first time one of them moves.
They always move. A date that never moves is a date nobody is working against. So the real question is not “where do we keep dates”, it is “when this date changes, how many places have to change, and who is responsible for each one?” If the answer is more than one place, the date will be wrong somewhere within a month, and the person reading the wrong copy will not know they are reading the wrong copy.
Keep the date on the item itself. One item, one date, one thing to change. It sounds too simple to matter, and it is the highest-value habit here.
What the daily look at dates is for
Most small teams either look at their dates constantly or never. Once a day is close to right.
The daily look is not a review of everything. It is three specific questions, and it should take four minutes.
First: what is due today, and is it actually going to happen today? Not “could it”, “will it”. If the honest answer is no, the date changes now rather than at six in the evening.
Second: what is due in the next few days that has not been started? This is the only forward-looking question, and it exists to catch the item that is fine today and impossible on Thursday.
Third: what has a date that has already passed? Anything here is either done and not marked done, which takes two seconds to fix, or it is overdue and the person planning around it does not know. That second case is the expensive one, and it is the reason to do this every day rather than every week.
Nothing about that list requires a meeting. It requires a place where dates are visible and four minutes.
Following up on somebody else’s date
The other half of this is social, and small companies get it wrong in both directions.
The under-communicating version: you say nothing, because asking feels like nagging, and then the date passes and you are annoyed about something the other person did not know mattered. The over-communicating version: you ask every day, which reads as distrust and makes people defensive about dates in general, which makes them stop giving you real ones.
There is a narrow path between those. A few things that help.
Ask about the date, not the person. “Is Thursday still right for the pricing page?” is a question about a fact. “Are you going to make Thursday?” is a question about them.
Ask early enough to be useful. A check-in the day before a deadline is not a check-in, it is an announcement of a problem. Two or three days out is when the answer can still change the plan.
Make it cheap to move the date. If saying “it will be Monday” costs somebody an argument, they will not say it, and you will find out on Thursday evening instead. The cost of a moved date is a rearranged week. The cost of a hidden moved date is everything downstream of it.
What a chief of staff does here, and what it does not
There is a version of this that software can carry, and a version it cannot.
Software can hold the date next to the work. It can notice that something is due tomorrow and has not moved, and tell you. It can notice that a date has passed and nobody marked the item done. It can write the message asking about a date so that sending it costs you one read and one click rather than five minutes of wording it politely.
What it cannot do is decide. Whether Thursday is still the right date, whether the project should slip or the scope should shrink, whether this person needs a nudge or some room — those are judgements about people and priorities, and they belong to the person who has to live with the answer.
The right division of labour is narrow and boring. The system remembers and raises. You decide and send. A tool that tries to decide will be wrong in ways you only find out about later, and a tool that will not raise anything leaves you exactly where you started.
Where Opitor fits
Opitor is an AI-native operating system for small companies, where every person gets their own AI chief of staff. Todos and their deadlines are part of the same product as the messages, so a date lives on the item it belongs to rather than in a second place. Each person’s chief of staff follows up their todos and deadlines and drafts the message asking about somebody else’s, and then it stops: it drafts, you send, and everything it writes is signed in purple. Opitor is free to start and one person can start alone and invite the team later. More on what that means is on what is an AI chief of staff and on the questions and answers page.