I want to tell you about a specific week that I think about more than I probably should.
It was at Drups Ventures. I had tasks assigned, deadlines had passed, and when the next standup came around there was nothing to report — not because the work was done, but because nothing had moved and nobody had said anything. No update, no flag, no explanation. Just silence until the meeting forced the issue.
The problem was not that tasks had gone overdue. Tasks go overdue in every operation. The problem was that there was no signal. The system had no way of surfacing the fact that something was stuck until we were all in a room together and I had to explain why a deadline I had agreed to had passed with no output.
That experience made a specific thing visible: overdue tasks without documentation are operationally invisible. You cannot manage what you cannot see, and a task that is technically overdue but sitting in a tool with no status update looks exactly the same as a task that is on track. Until it doesn’t.
The fix was simpler than I expected
After that week, I implemented a protocol that I have used ever since: any task that passes its due date triggers three mandatory questions, and the answers have to be written down before the next meeting.
The three questions are:
- What happened?
- What is the current status?
- What is the revised completion date?
That is it. No retrospective. No root cause analysis document. No meeting to discuss the missed deadline. Just three questions, written answers, visible to whoever needs to see them.
The first question forces an honest account of what actually occurred. Not an excuse — an account. Did the task get deprioritized? Was there a blocker that was not flagged? Did the scope turn out to be larger than estimated? Writing down what happened makes the cause visible without requiring a conversation. It also prevents the pattern where the same reason gets recycled for every missed deadline — if you write it down every time, you can see when the same cause appears repeatedly.
The second question is the one most people skip when they are embarrassed about a missed deadline. They want to jump straight to “I’ll have it done by Friday” without acknowledging where the task actually stands. Is it 50% done? Is it not started? Has a new blocker emerged? The current status matters because it determines whether the revised date is realistic.
The third question is a commitment, not a request. It is not “when do you think you might get to this.” It is “given what you just wrote in questions one and two, what date are you committing to now.” The revised date is binding in the same way the original date was.
Why this works better than a follow-up meeting
The instinctive response to a missed deadline is to schedule a conversation. Talk through what happened, make sure everyone is aligned, agree on a path forward. This feels productive. It is usually not.
Follow-up meetings have two failure modes. The first is that they turn into explanations rather than accountability — the person who missed the deadline spends ten minutes providing context, the meeting ends with everyone feeling like they understand the situation, and nothing has actually changed about the task’s trajectory. The second failure mode is that they create overhead proportional to the problem. A missed task that would take three minutes to document requires a 20-minute meeting to discuss.
The three-question protocol creates a paper trail without creating overhead. The written answers are there if anyone needs to review them. They do not require a meeting to generate. They do not require the manager to probe and follow up — the protocol is the probing. And because the answers are written, they cannot be retroactively revised in someone’s memory. Either you wrote that the task was 80% complete on Tuesday, or you didn’t.
What changed after implementing it
The most immediate change was behavioral. When people knew that a missed deadline would require three written answers, they were more likely to flag blockers before the deadline passed. The protocol made the cost of silence explicit. Silence no longer meant the deadline would pass quietly — it meant a written record would exist of the missed commitment and its explanation.
The second change was in my own visibility as the operations lead. Instead of discovering overdue tasks in meetings, I could see them in the tracking system with status and dates attached. That shifted my role from chasing people for updates to reviewing documentation that was already there.
The third change was harder to quantify but more important: the team’s relationship with commitments got more honest. When you know that a missed deadline produces documentation rather than just a conversation, you stop agreeing to dates that feel optimistic. The protocol did not make people more capable — it made them more precise about what they were actually committing to.
That week at Drups Ventures was frustrating. The protocol it produced has been worth more than the frustration.
