Discuss a Missed Deadline After a Dependency Changed

A deadline slips and the reason on the surface looks clean, another team changed a file, a spec, a delivery date, and your report inherited the delay. The instinct is to let the dependency carry the whole explanation and move on. That instinct is wrong. A changed dependency explains why the original plan failed. It does not explain whether your report saw the risk early enough to say something, or whether they quietly tried to absorb the gap alone. The conversation you need is not about assigning blame for someone else's change. It is about understanding what happened between the moment the dependency shifted and the moment you found out.

Why This Conversation Goes Wrong

Managers usually take one of two bad paths here. The first is to accept the dependency as a complete excuse and skip the conversation entirely. That feels kind in the moment, but it teaches the employee that a changed input excuses silence, and the same slip happens again next quarter with a different dependency. The second bad path is the opposite, treating the missed deadline as a personal failure and pushing hard on why the work was late, without acknowledging that the ground genuinely moved. That approach puts the employee on the defensive fast, and once they are defensive they stop giving you the details you actually need.

Both paths skip the real question. When did the employee know the original date was no longer realistic, and what did they do with that knowledge. A dependency change is a fact. What the employee does after that fact, whether they escalate, renegotiate scope, ask for help, or just keep working and hope, is the part that is actually inside their control and worth discussing.

Prepare Before You Talk

Walk in with a timeline, not an impression. Write down the original due date, the date the dependency changed, the date you or the employee learned about the change, and the date any communication went out about the new risk. This takes ten minutes and it turns a vague sense of frustration into a specific set of gaps you can ask about.

Look at the gaps between those dates. If three days passed between the dependency changing and anyone raising a flag, that gap is your conversation. If the employee flagged it immediately and the delay came from waiting on your own approval, that is also worth knowing before you sit down, because it changes who owns the next step.

Decide in advance what you are trying to learn, not what you are trying to prove. You want to know where the plan stopped matching reality and what options the employee considered once they saw that. You are not building a case for a formal warning. You are trying to fix the escalation habit for the next project, and that only works if the employee tells you what they were actually thinking, not what they think you want to hear.

What to Say

Open with the timeline, not the outcome. Manager Nina said, "The client summary was due Friday. The data file arrived Thursday afternoon with new fields, and we delivered Monday. Walk me through the point when you saw Friday was no longer realistic." That question puts a specific moment on the table instead of asking a broad "what happened," which invites a story instead of a fact.

Omar said, "I knew on Thursday, but I thought I could finish over the weekend." That answer is the whole conversation in one sentence. Omar saw the risk and chose to absorb it alone rather than raise it. Nina's next move matters more than her first question.

Nina replied, "I understand why you tried. Next time, tell me as soon as the estimate changes, so we can choose between a reduced scope, help from another person, or a revised date. What message could you have sent Thursday?" Notice what she did not do. She did not relitigate the weekend or ask why he did not just work faster. She named the actual gap, the missing message, and asked him to write the version of it that should have gone out.

Omar said, "I could have said the file change added review time and asked whether the client needed every section by Friday." That is a usable answer. It gives Nina something concrete to reinforce, and it gives Omar language he can reuse the next time a dependency shifts under him.

Close the conversation by splitting ownership out loud. Nina should say plainly that decisions like approving a reduced scope or speaking to the client about a new date belong to her, not to Omar. Omar's job is timely visibility and sticking to whatever plan they agree on together. Say this part out loud even if it feels obvious, because it is the line most people skip, and skipping it is exactly what leaves an employee guessing next time.

Mistakes to Avoid

Do not let the dependency become the whole story. If you close the conversation right after hearing "the file arrived late," you have learned nothing about how your employee handles pressure, and you have set the expectation that any outside change is a full excuse.

Do not ask questions you already know the answer to as a trap. If your timeline shows the employee sat on the risk for three days, do not ask "when did you find out" hoping to catch them in a gap. Say what your timeline shows and ask them to fill in the reasoning. That gets you the truth faster and it does not feel like an ambush.

Do not skip the part where you own your own decisions. If scope approval or a client conversation needed to happen and it stalled because you were slow to respond, say so. An employee who watches you take ownership of your own delay will be far more honest about theirs.

Do not leave the conversation without a concrete next step. A vague instruction to communicate earlier next time does not change behavior. Ask the employee to flag dependencies before they commit to a date on the next project, and ask to see the first early warning message they send. That turns the lesson into a habit instead of a memory.

Practice and Score the Conversation

This conversation is hard to get right on the first try because it asks you to hold two things at once, genuine sympathy for a plan that got knocked over by someone else's change, and a real accountability conversation about what your employee did next. Most managers lean too hard into one side or the other under pressure.

Rehearsing it with an AI counterpart before you sit down with the real employee lets you test both sides. You can practice staying specific instead of vague, catch yourself if you start relitigating instead of asking forward looking questions, and see how you score on separating your own decisions from theirs. DealSpeak's HR and Leadership practice conversations include this exact scenario along with related ones, so you can run through the timeline question, the ownership split, and the close before the stakes are real.

If this deadline conversation surfaces a pattern where your employee is missing details when they hand off work, not just when a dependency changes, the piece on how to Give Feedback on Missed Handoff Details With a Specific Work Example covers that adjacent problem directly. And if you manage someone newer to the team who seems unsure whether they are even allowed to ask a clarifying question when something changes, Help a New Employee Ask for Clarification is worth reading before your next one on one.

A missed deadline after a dependency change is not really about the deadline. It is about whether your employee trusts you enough to raise a risk the moment they see it, instead of trying to fix it alone and hoping you never notice the gap.