Holding a Commitment Accountable Without Owning the Work
Responds to a slipping commitment by finding the real blocker first, offering to unblock directly, and escalating to the right owner when the blocker sits outside their control — without absorbing the work or waiting silently for a date to be missed.
What this is
A task that was estimated, committed, and tracked in the plan starts showing signs of slipping — progress that has stalled against its date, or an owner who has gone quiet against a milestone they had agreed to. I don’t have technical authority over the person doing the work, and I’m not the one who can fix whatever the underlying problem is. What I do have is visibility into the commitment and the standing to ask why it’s moving off track.
How I operated
- Find the real blocker before assuming anything. The first move is always a direct conversation with the person who owns the task, not a status update in a tracker and not an escalation. Slipping work has a reason, and the reason determines what happens next — it’s rarely “not working hard enough.”
- Offer to unblock what’s actually mine to unblock. If the blocker is something I can move — missing information, an unclear requirement, a decision waiting on someone else, access or priority conflict — I take that on directly so the engineer can get back to the work instead of managing the obstacle themselves.
- Escalate to the right owner when the blocker is outside the person’s control. If the real blocker sits with another team — a dependency, a review queue, a decision another lead needs to make — I go to that team’s lead directly, not around them and not by pressuring the original engineer to chase a peer they have no standing with. The person who owns the commitment shouldn’t also have to own escalating a blocker that isn’t theirs.
- Keep the commitment visible throughout, not just at the deadline. The task’s status reflects the real blocker and who now owns unblocking it, so anyone looking at the plan sees the true state — not a green status that turns red on the due date with no warning.
- Follow through until it’s actually moving again, then confirm the revised timeline with the original owner rather than assuming the blocker’s removal automatically fixes the date.
Outcome and value
The slipping commitment surfaced while there was still room to act, and the blocker moved to whoever could actually resolve it — the engineer, me directly, or another team’s lead — instead of sitting unaddressed behind a green status. The original owner stayed accountable for their piece, the revised date was re-confirmed rather than assumed, and nothing arrived at the deadline as a surprise. The value is keeping a commitment visible and honestly owned when the person coordinating it has no authority to compel the work.
What this shows about how I operate
I don’t chase people, and I don’t quietly absorb their blocked work onto my own plate to protect the date. The system is built so a slipping commitment surfaces early and gets routed to whoever can actually move it — the engineer, if it’s something I can clear directly, or another team’s lead, if it isn’t. That keeps the original owner accountable for their piece without leaving them stuck, and it keeps me accountable for the thing I actually own: making sure nothing slips silently until it’s too late to do anything but explain it after the fact.