When an engineer misses a deadline: a practical 1:1 playbook for EMs

Andrea Belluccia — Wed, 14 Oct 2026 14:21:25 +0000

An engineer missed a deadline. Your Tech Lead says they need more ownership. You have a 1:1 tomorrow. What do you actually do?

This is a practical guide for the Engineering Manager running that conversation. Throughout this article, “you” means the EM, not the engineer.

The situation: Tuesday's 1:1 with Sam

You're an EM managing a software team. Sam is one of your direct reports and has been explicitly assigned as Epic Lead for an API integration initiative. In your team's working agreement, the Epic Lead coordinates delivery visibility: risks, blockers, dependencies and confidence in the target date. This role doesn't mean Sam controls Product's scope decisions or another team's dependencies.

Last Friday, the API integration Sam was leading wasn't ready for the team's checkpoint. It's the second delivery date that has slipped in a month.

There are complications. Product changed the acceptance criteria on Tuesday. Another team owned a dependency. The risk wasn't clearly raised to the team until Friday afternoon.

After the checkpoint, your Tech Lead told you: “Sam needs to take more ownership.”

Tomorrow, Tuesday, you have your regular private 1:1 with Sam.

What you know: Sam was assigned Epic Lead, two dates slipped, the latest dependency became visible to the team late, and Product changed scope.

What you don't know yet: when Sam recognized the risk, whether Sam had a realistic opportunity to raise it, whether the team's Epic Lead communication expectations were explicit, and what help or decision was needed.

Your job in this meeting isn't to prove the Tech Lead right or wrong. It's to understand the situation, give fair feedback where needed, and agree on what happens next.

Save this: the quick version

Before the 1:1 (10 minutes): Write down one observed incident, the original expectation, what changed, and what you still need to ask.

In the 1:1 (20 minutes): Describe the incident → ask for Sam's timeline → separate system issues from individual actions → agree on one observable behavior and one action you'll own.

After the 1:1 (5 minutes): Confirm the agreement privately, assign owners, and revisit it at the next relevant checkpoint.

The details below are what make that sequence useful rather than just another feedback formula.

1. Before the meeting: prepare facts, not a verdict

You don't need a dossier on Sam. You need a clear example and enough context to have a fair conversation.

For this scenario, your preparation notes might look like this:

Expected: as Epic Lead, Sam would keep delivery confidence, risks, blockers and dependencies visible in Epic Reviews or Daily Stand-ups. A significant change threatening the Delivery Date would require a timely update outside those checkpoints. The integration was forecast for Friday; confirm whether that date was a commitment or an estimate.
Observed: it wasn't ready, and the dependency became visible to the wider team on Friday afternoon.
Changed: Product altered acceptance criteria on Tuesday; another team controlled the dependency.
Unknown: when did Sam first know the Delivery Date might genuinely be missed? Was Wednesday just lower confidence with the date still credible, or a significant change requiring action? Did Sam have time and an agreed way to raise it?

Notice what isn't written: “Sam lacks ownership.”

That's an interpretation, not a useful starting fact.

If you discover that the date was never agreed, or nobody defined how to flag a blocker, acknowledge that gap. A manager can't fairly hold someone to an unspoken process.

Before calling this an ownership issue, reconstruct the timeline of the Product change. When did the requirements change? When did Sam find out? Did Sam have enough information and a realistic chance to adjust the plan or raise the risk? A sudden change can leave an engineer with no workable opportunity to warn anyone. In that case, fix how the team communicates and replans scope changes before asking for more “proactivity.” Also distinguish a drop in delivery confidence from a Delivery Date that is actually under threat; they call for different communication urgency. If Sam knew the date was genuinely at risk, had time and a clear escalation path but did not use it, that is a different conversation.

2. In the 1:1: make the moment explicit

You're now in the meeting. It's just you and Sam, in a private conversation—not a team stand-up, sprint review, or performance hearing.

Start with the situation, not a character judgment:

“Sam, I'd like to revisit Friday's integration checkpoint. We expected to have the integration ready, but the dependency was raised very late, so we had few options left. I also know Product changed the scope. Can you walk me through how the week looked from your side?”

Then stop talking.

Try to establish the timeline with questions like:

“When did you first think Friday might be at risk?”
“What did you try, and what was blocking you?”
“Did you know who to tell or how to escalate it?”
“What could I or the team have changed earlier?”

Don't interrogate Sam with all four questions in a row. Follow the answers; you're looking for the actual decision points.

If Sam says, “Product kept changing the scope”

Don't dismiss it, and don't let it end the discussion automatically.

“I agree the scope changes mattered. I'll address how we make those decisions with Product. Separately, I want us to spot delivery risks early enough to make a different plan. When did it become clear to you that Friday was unlikely?”

Now there are two separate responsibilities: you, the EM, need to improve planning and decision-making conditions; Sam, as the assigned Epic Lead, is responsible for keeping delivery risks and confidence visible when there is enough information and opportunity to act. Both can be true.

When should the Epic Lead communicate?

Routine update: If Sam's confidence has dropped but the Delivery Date remains credible, Sam can explain the change, why it happened and what is being monitored at the next Epic Review or Daily Stand-up. Lower confidence alone isn't an emergency.

Extraordinary update: If something changes drastically and the Delivery Date is now seriously at risk, Sam should make that visible without waiting for the next routine checkpoint. The purpose is to give the team time to decide what to change—not to send more status messages.

The trigger is the likely impact on delivery and the urgency of a decision, not a fixed confidence percentage. This is a working agreement to make explicit with the lead, not an expectation to assume retroactively.

If Sam knew on Wednesday the Delivery Date was genuinely at risk

Once you've established that this was a significant delivery risk—not merely lower confidence with a still-credible date—and confirmed the timeline and expectations, give direct feedback:

“Sam, as Epic Lead, I expect you to keep delivery confidence, risks, blockers and dependencies visible in our usual Epic Reviews or stand-ups. But when there's a major change that puts the Delivery Date at risk, I need you to flag it outside those checkpoints so we still have options. If you knew on Wednesday that Friday's date was seriously at risk, but we only heard on Friday, we lost the chance to adjust the plan. What prevented you from raising it sooner?”

The question at the end matters. If something prevented Sam from communicating—unclear ownership, missing access, an abrupt change or a blocked escalation route—address that too. If the route was clear and usable, explain the impact of waiting and agree on a better communication habit.

3. Choose the right response based on what you learn

Don't use the same feedback script in every case.

What you discover	Your next move as EM
The date or escalation expectations were never clear	Clarify the agreement and communication route. Don't present an undefined rule as Sam's failure.
Scope changes or external blockers made the plan unrealistic	Own the cross-team/Product follow-up. Agree how Sam will surface the impact next time.
Sam's confidence dropped but the Delivery Date remained credible	Use the next Epic Review or Daily Stand-up for a routine confidence and risk update; don't demand extraordinary communication without meaningful delivery impact.
Sam was the assigned Epic Lead, knew a major change made the Delivery Date genuinely at risk, had a clear route and time to flag it but waited	Give direct feedback on late escalation, explain the lost chance to replan, and agree on the trigger for an extraordinary update.
The same agreed behavior fails to improve after reasonable clarity and support	Collect comparable evidence, give explicit follow-up feedback, and use your company's People process if appropriate.

This is the distinction that matters: a missed date is not automatically a performance issue. But changing scope doesn't automatically explain late communication, either.

4. End with two commitments, not “be more proactive”

Make the agreement observable and mutual.

Sam's commitment

“As Epic Lead, I'll share changes in delivery confidence, risks, blockers and dependencies in our regular Epic Review or Daily Stand-up while the Delivery Date remains realistic. If a major change seriously threatens the date, I'll flag it promptly outside the routine checkpoint, including the impact and the decision or help needed—even if I don't yet have a solution.”

Your commitment as EM

“I'll clarify with Product which scope changes require a date review, make escalation and decision ownership explicit, and help remove blockers Sam cannot resolve alone.”

Agree where regular updates happen, which channel is used for a genuine delivery threat, and what the next meaningful checkpoint is. Use the team's existing way of expressing delivery confidence; don't invent thresholds or response-time targets without a team agreement.

Reusable Epic Lead update: Current delivery confidence and why → What changed → Risks, blockers or dependencies → Impact on the forecast → Help or decision needed → Next update.

Before closing, ask:

“Does this feel workable? Is there anything that would stop you from doing it?”

That's more useful than ending with “please take more ownership.”

5. After the 1:1: follow through on your side too

Send a brief private recap through an approved work channel:

“Thanks for talking through Friday. We agreed that you'll cover routine confidence changes and dependencies in Epic Review or stand-up, and flag a major new threat to the Delivery Date separately and promptly. I'll align with Product on scope-change decisions and help unblock what sits outside your control. We'll review this at the next delivery checkpoint.”

At that checkpoint, check both sides: Did Sam raise risks earlier? Did you remove ambiguity or help change the plan when needed?

If the next delivery succeeds, great—but don't confuse one successful date with proof that the underlying issue is solved. If the pattern continues, use specific observations rather than repeating a vague label.

Copy this before your next difficult 1:1

Who I'm meeting: [Direct report / role]

Why we're meeting: [One situation and its impact]

What we expected: [The actual agreement, not hindsight]

What I observed: [Verifiable event and timing]

What changed around them: [Scope / dependency / priorities / support]

What I don't know: [Two questions to ask, not assumptions]

Their perspective: [Fill in during the meeting]

Their role and action: [Assigned Epic/Initiative Lead? Routine update vs extraordinary delivery-risk trigger; channel and owner]

My action as EM: [Which scope decision, expectation, dependency or escalation I will clarify, unblock or change]

Review point: [Next meaningful checkpoint]

Keep real employee details only in appropriate private company systems—not in public templates or external AI tools. If a formal performance, safety or HR issue is involved, follow the relevant internal policies rather than treating this guide as a substitute.

The test of a useful feedback 1:1 isn't whether you delivered a strong message. It's whether you and the engineer leave knowing what each of you will do differently, and how you'll tell if it worked.

Editorial note: This is a fictional scenario designed for learning. The management approach was reviewed by a practicing Engineering Manager, and the article was drafted with AI assistance.

DEV Community: Andrea Belluccia