A blocked action item needs two owners

When an action item is blocked, keep one owner for the result and name a second owner for the input that unlocks it. Give the dependency its own due date and define what happens when that date passes.

Otherwise the result owner stays visible while the real next move belongs to someone who appears nowhere in the record. The task looks late, the blocker looks passive, and follow-up turns into repeated messages asking for an update.

Keep ownership of the result stable

A blockage does not automatically transfer the original commitment.

Suppose Leon owns “deliver the revised onboarding plan by Friday,” but he cannot finish until Priya confirms support capacity. Leon still owns the plan. Priya owns a narrower input: “confirm the number of pilot accounts support can cover by Wednesday at noon.”

That distinction matters because the two owners answer different questions:

• result owner: Who is accountable for producing the agreed deliverable?
• input owner: Who controls the next fact, approval, file or decision required to continue?

Do not replace Leon with Priya as the task owner. Priya did not agree to write the plan. Do not leave Priya only in a comment, either. Her input is now a commitment with consequences for other work and should be visible as such.

Describe the dependency as a deliverable

“Waiting on Priya” is a status, not a handoff. It gives Priya no clear result to accept and gives the team no way to tell when the wait is over.

Write the dependency with the same discipline as any other action item:

Priya will confirm the maximum pilot cohort support can cover, including the on-call constraint, by Wednesday at 12:00.

That is stronger than:

• “support to review”;
• “need numbers from Priya”;
• “blocked by capacity”;
• “follow up Wednesday.”

The input may be a fact, a decision, an approval, a file or completed work. Name the artifact or answer, not the activity around it. “Review the draft” is weak; “approve the draft or list the blocking changes” defines an end state.

If the input owner was not in the meeting, treat the assignment as proposed until they accept it. The guidance on assigning work to someone who missed the meeting applies to dependencies too.

Give the dependency an earlier date

The input deadline and the result deadline cannot be the same if work must happen between them.

Work backwards from the result:

• Friday 16:00 — revised onboarding plan delivered;
• Thursday — Leon incorporates capacity and completes review;
• Wednesday 12:00 — Priya supplies the capacity answer;
• Wednesday 12:01 — escalation rule applies if the answer is missing.

The gap should match the real work left after the dependency resolves. A five-minute approval may need little space. A dataset that changes the analysis may need days.

Avoid solving a blockage by quietly moving the final deadline. A due date is an agreement with whoever depends on the result. If the dependency makes that agreement impossible, use a new deadline agreement rather than editing the date as though nothing changed.

Define the unblock signal

Teams often disagree about whether a task is still blocked because the handoff has no completion test.

Choose an observable signal:

• a named document is attached;
• the approver records “approved” or lists blocking changes;
• the required number is added with its source;
• a decision is recorded by the person with authority;
• access is granted and the result owner confirms it works.

Sending a message is not the same as delivering the input. Uploading a file is not enough when the owner cannot open it. A meeting is not enough when it ends without the required decision.

The result owner should acknowledge the handoff. That short confirmation catches the common failure where one person believes they supplied the answer and the other believes a crucial part is still missing.

Choose what happens when the input is late

“Chase again” is not a dependable escalation rule. Decide the next move when the dependency is created.

Use the least dramatic response that protects the commitment:

1. notify the input owner that the agreed time passed;
2. tell the result owner whether the final date is now at risk;
3. escalate to a named decision-maker if priority or authority is the problem;
4. use a documented fallback input when one exists;
5. renegotiate the final deadline with affected people.

For the onboarding plan, the record might say:

If capacity is not confirmed by Wednesday at noon, Leon asks the support lead for a same-day decision and marks Friday's plan at risk. He does not invent a capacity number or treat silence as approval.

Escalation is not punishment. It is the planned response to a dependency crossing the point where it threatens the outcome.

Make blocked time visible without creating a blame score

A useful record shows when the task became blocked, what it needs and which commitment unlocks it. It does not need a leaderboard of who caused delay.

Capture:

• blocked since;
• blocked on;
• input owner;
• input due;
• unblock signal;
• impact on the result date;
• next escalation.

This lets a manager distinguish different problems. The result owner may be waiting responsibly. The input owner may be handling a genuine priority conflict. The dependency itself may have been discovered late because the task was poorly scoped.

The goal is to move the work, not to convert every dependency into evidence against a person. Review the pattern later: repeated blocks from the same approval step may mean the process needs redesign, not more reminders.

Keep the two commitments connected

The dependency and the result should not become unrelated rows that require memory to connect.

In Scripta, action items can keep an assignee, due date, priority, status and source meeting. Record the input as its own action and use clear wording that names the result it unlocks. Keep both beside the meeting record so later readers can see why the result paused and what resolved it.

Scripta does not infer hidden dependencies or decide who should accept them. The meeting close still needs a human read-back:

Leon owns the revised plan by Friday. Priya owns the capacity confirmation by Wednesday at noon. Priya's answer unlocks Leon's final revision. If it is late, Leon escalates to the support lead and marks Friday at risk.

Ask each person to confirm their part. General silence is not acceptance.

Use a seven-line blocked-action record

When a dependency appears, capture it without inventing a large workflow:

Result: Revised onboarding plan.

Result owner: Leon.

Result due: Friday at 16:00.

Blocked on: Confirmed pilot support capacity.

Input owner: Priya.

Input due: Wednesday at 12:00.

If late: Escalate to the support lead and mark Friday at risk.

Add the unblock signal when the wording is not already obvious. Then connect any date change to a real conversation with the people relying on the result.

One owner keeps accountability simple. Two explicit commitments make the dependency real. That is the difference between a task that is merely labelled “blocked” and work the team can actually unblock.