Follow-through
Delegate the action, not the accountability: a practical waiting-for system
Delegation fails when assignment is treated as agreement. A reliable waiting-for system records what another person has accepted, the evidence they will return, and what you will do if the checkpoint passes. This guide separates access, ownership, dependency, reminder, and completion so a task can leave your hands without disappearing from your operating review.
By QuadrantWorksUpdated 7 min read
The short version
- A name in an owner field is not proof that the person accepted the work.
- Use a named waiting counterpart and a specific requested result.
- Workspace invitation delivery, account acceptance, task agreement, and calendar RSVP are different events.
- Review stale waits by the next decision required, not by sending more reminders.
In this article
Replace a vague handoff with a small agreement
Please handle the supplier review sounds delegated, but it leaves the recipient to guess whether you need a recommendation, a signed agreement, or a meeting. In a fictional operations team, the request becomes: Compare the two approved supplier options and return a one-page recommendation by Thursday, including the unresolved tradeoff. The operations manager retains the decision; the analyst owns the comparison.
Agree what the recipient may decide independently and what needs approval. State the deadline and the next checkpoint separately. If the recipient cannot accept the scope, update the commitment before calling it delegated. The purpose is not to document every conversation. It is to leave enough shared context that either person can answer what happens next without reopening a week of messages.
- Result: the concrete artifact, decision, or verified change to return.
- Authority: what the recipient may decide without further permission.
- Acceptance: a recorded acknowledgement or explicit counterproposal.
- Checkpoint: when to review progress before the final deadline.
- Closure: the evidence the accountable owner will inspect.
Choose between one task, plan steps, and separate commitments
Use one task with execution-plan steps when the work is one coherent commitment and the steps share its overall deadline. Critical Path can assign plan steps to workspace members. Create separate tasks when contributors need distinct due dates, meaningful effort allocations, or independently reviewable results. A plan-step assignee should not be mistaken for a separately scheduled calendar commitment.
For the supplier example, the analyst's comparison and the manager's decision are different commitments. The manager can wait on the analyst while preparing questions that do not depend on the final comparison. Avoid creating three copies of the same comparison under three managers. One authoritative action, with a short dependency reference where needed, is easier to update and less likely to create contradictory status.
| Work | Representation | Why |
|---|---|---|
| Check both options against agreed requirements | Step in analyst's comparison task | Same owner and deliverable |
| Return one-page supplier recommendation | Analyst-owned task, 90 min | Independent deadline and acceptance evidence |
| Choose the preferred option | Manager-owned task, 30 min | Different decision authority |
| Confirm the decision reached the purchasing owner | Closure step in decision task | Evidence completes the handoff |
Verify the invitation without assuming delivery
If a colleague needs workspace access, an owner or admin can use Team to send an invitation with an explicit role. Check the result. The application distinguishes a sent invitation from a created invitation that needs its secure link delivered, and a preview workspace only stages an invitation. An Invited label means acceptance is still outstanding. Deliver a secure link only to the intended person through an approved channel; do not put it in a public guide or shared screenshot.
Then ask the colleague to open the intended task and confirm the request. This confirms a real workflow, not just account creation. Calendar invitations add another layer: Google's documentation explains that a guest's settings can require a response before an event appears. Check the actual RSVP when attendance matters. Workspace access does not prove calendar attendance, and a calendar RSVP does not prove acceptance of an assigned deliverable.
Sources: Google Calendar: invitations, guest settings, and RSVP responses
Record the next mover and the checkpoint
A waiting list is useful only if each entry names the next mover and the result owed. In task details, choose Waiting when another person owns the next move and populate Waiting on. Use the execution note or a task update to record the agreed checkpoint. The delegation-state field can describe Delegated, Awaiting update, or Accepted, but a manually selected label is not a verified external acknowledgement.
For example, the manager's decision task waits on the analyst's comparison until Thursday. Wednesday's checkpoint asks whether the two options can still be compared on the agreed basis. A clear answer may be No: one supplier has not supplied the required information. That is useful progress because it changes the decision. The manager can narrow the comparison, extend the deadline explicitly, or obtain the missing information.
Configure reminders around an agreed cadence
The current automated follow-up email path requires the task to have a due date, follow-up enabled, and selected workspace recipients. Offset choices are relative to the due date, not a universal promise to message at a particular local hour. Check the displayed reminder plan after saving. A follow-up recipe can enable the feature, but it does not choose recipients or establish the working agreement for you.
Start with the least intrusive cadence that supports the commitment. An analyst who has agreed to a Wednesday checkpoint may not need multiple daily nudges. A late, high-consequence dependency may need a direct conversation rather than an additional automated email. Task comments and status updates can inform the application's response checks; a reply in an unrelated email thread should not be assumed to synchronize into the task. Record the material decision where reviewers can find it.
Use a short waiting-for review
At each agreed review, sort the open waits mentally into three questions: is the result still needed, does the named person still own the next move, and is the existing checkpoint credible? This prevents a polite reminder from perpetuating a commitment that has already become irrelevant. If ownership changes, update the task and confirm the new handoff instead of silently replacing the old name.
Do not treat silence as acceptance. If the checkpoint passes, ask for an explicit revised plan. If nobody has the authority or capacity to supply one, mark the blocker and take it to the appropriate decision-maker. In Critical Path, blocked or overdue open tasks appear in At risk rather than being hidden by a manually chosen pipeline stage. That visibility is a prompt for judgment, not an automatic escalation to a senior person.
- Inspect the promised evidence, not only the latest status label.
- Ask whether the current owner accepts the next checkpoint.
- Choose continue, renegotiate, reassign, cancel, or escalate explicitly.
- Record the changed decision and review the reminder recipients.
- Check that the saved state reflects the agreement.
Close the action without keeping a shadow reminder
When the analyst returns the comparison, the manager verifies that it answers the agreed question. The comparison task can close even if the purchasing decision remains open. This preserves an honest distinction between a completed contribution and an unfinished outcome. If the result is incomplete, name the missing criterion; do not keep the entire task open with a generic Not good enough comment.
Complete the required execution-plan steps before closing the parent action. Check the associated follow-up configuration and any separate manual calendar reminder so you do not continue chasing work that is already accepted. The aim is a small waiting-for list in which every open item represents a real future decision. Start with one current handoff, confirm it with the recipient, and review one full cycle before expanding the method across the team.
Common questions
Is changing the task owner enough to delegate successfully?
No. The owner field records responsibility in the planner. The recipient still needs to understand and accept the result, authority, deadline, and checkpoint.
Can I invite an external person just to test the workflow?
Only invite someone who is intended to receive access and has agreed to the test. An invitation is a real external message and may grant workspace access after acceptance.
Does Accepted in delegation state prove the recipient replied?
Not by itself. It is task metadata that can be edited. Keep the actual acknowledgement or a concise, accurate record of it as the evidence for your operating process.