When an employee keeps missing deadlines, start with the work and the agreement in force. Check what arrived, which date had actually been agreed and what the delay cost the person waiting. Then make the next delivery feasible and review whether it happened. A warning about a delay needs a decision; it does not settle a new deadline.
What you'll learn
- Distinguish an approved date change from a forecast or an unanswered warning.
- Judge the quality of the work separately from its timing and practical impact.
- Agree one usable delivery, including your own inputs, and check the result.
Missing deadlines: establish which promise was missed
Choose a few recent, comparable deliveries. Use the existing task note, relevant messages and actual output, alongside the employee's account. Find the original requirement, any accepted change, the delivery time and what happened next. Keep an unclear or disputed agreement marked as such; an incomplete record cannot establish someone's motive.
Consider a hypothetical help-centre release pack. The first pack was originally due Friday. After adding a feature, the manager agreed to Monday and rearranged the support team's preparation. The employee delivered the revised pack on Monday. The change still caused disruption, but this was not a missed Monday commitment.
The next pack was due Wednesday for a support review. On Tuesday the employee wrote, 'It looks more like Thursday.' Nobody agreed a new date, and the accurate pack arrived Thursday after the review. That was a forecast of a miss, not an approved extension. The manager also needs to explain what they did with the warning.
If neither person can identify the expected output, decision authority or necessary inputs, first separate a performance problem from unclear responsibility. Here, the narrower question is what happened to a particular delivery commitment as the work changed.
Review quality and lateness separately
Fang and Maglio's research, published in 2024, examined how submission timing affects evaluations. The authors' university explains that participants judged identical work less favourably when it was described as late. This concerns perceived quality and evaluations of the worker, rather than evidence that the content itself became worse. It is a reason to check your judgment, not a reason to ignore missed commitments.
In the second help-centre pack, the screenshots and instructions may all be correct. Keep that finding. Also record that the support team could not use them in Wednesday's review. Ask what actually had to be repeated, delayed or abandoned. Avoid replacing that specific impact with 'you let everyone down' or assuming an impact you have not checked.
Ask what happened between accepting the date and delivering the work. Which input was missing? What changed in scope or priority? When did the employee know the date was at risk, and what happened after they raised it? Check your own changes and response as well as their planning. An explanation helps you choose the next action; it does not erase the result.
If risks repeatedly appear only after the deadline, work on making early escalation useful. Thank someone for a timely warning while still making an explicit decision about the work, the date and the people waiting.
Agree one next delivery the team can use
Acas advises that objectives should reflect normal tasks and workload, be realistic and time-bound, and be recorded and shared after the discussion. Apply that principle to the next actual delivery. A short note in your existing work system is enough; do not create a parallel reporting process.
- 01
Name the output and its use
Describe the version the recipient needs and the checks it must meet. Include access or review requirements that genuinely determine readiness. Do not add new acceptance criteria after delivery.
- 02
Agree dates for the different responsibilities
State the employee's delivery date and time, any reviewer deadline and the recipient's preparation or use time. Check the dates with the people responsible; the event start is not necessarily the latest useful handoff.
- 03
Make your inputs and trade-offs explicit
Name required access, information or decisions, who supplies them and when. Say which competing work moves out. Check that the change actually happens rather than adding another promise to a full queue.
- 04
Decide how a change gets accepted
Name who can approve a revised scope or date with the recipient. Set a proportionate checkpoint while options remain. A risk update should state the forecast and the decision needed; the authorised response should say what is now agreed.
For the hypothetical next pack, the employee will prepare screenshots for three features, check the links and place the pack where the trainer can open it. It must be ready for preparation on Thursday at 15:00, ahead of Friday's training. The manager will provide final product access by Tuesday at 12:00 and remove a competing design request.
They agree to check the missing input at Tuesday's 14:00 meeting if access has not arrived. The manager will confirm any scope or date change with the trainer. A two-feature pack might be a useful fallback, but only if the trainer agrees it serves the session. Otherwise they need another source, a different plan or an authorised change to the session.
If there is no room for even that bounded output, review the workload and remove or change real work. Asking for a more confident estimate does not supply missing capacity. Do not treat overtime as the unspoken solution.
Check what happened at the next delivery
In the example, access arrives Tuesday at 16:00, after the manager's promised time. At the 14:00 checkpoint, the manager has already contacted the trainer. The trainer confirms that two features are enough for Friday; the manager approves that smaller pack for Thursday at 15:00. They give the third feature its own owner and date.
The employee delivers the two-feature pack Thursday at 14:40. The links work and the trainer confirms it is usable for preparation. That meets the revised commitment. Record the manager's late input too. Do not treat the agreed smaller pack as a failure to deliver, and keep the outstanding third feature in the work record.
If the pack had arrived at 14:40 with broken links that failed the agreed checks, the sent timestamp alone would not establish usable delivery. Find when a usable version actually became available and what caused the gap. If the manager instead delayed a promised approval after a timely, review-ready handoff, keep that separate from the employee's delivery.
One successful delivery does not prove the pattern is permanently fixed. Use the same distinctions on the next comparable piece of work. Check whether the agreed changes held, rather than judging the person from a single recovery or an enthusiastic promise.
If feasible commitments keep slipping
In a separate hypothetical case, you might say: 'We agreed these two delivery times. The required inputs arrived when promised, but the usable packs arrived after both reviews. What is still preventing this from working?' Check the answer against the actual work. If scope, inputs or priorities changed again, deal with that condition rather than describing the same agreement as unchanged.
Where the pattern may require formal performance action, use your company's procedure and qualified support appropriate to the situation. Health, disability, retaliation or other serious concerns need their proper route; a delivery note cannot resolve them. This article's practical agreement is not a validated assessment tool or a substitute for that process.
Cooperly's Fundamentals can support a conversation about accountability and shared expectations. Keep the assessment of delivery grounded in the work, the agreement and the people involved; the product context does not prove when a usable output arrived or decide who caused a delay.