DUTYGRAPH FIELD NOTES

If every exception comes back to you, map the dependency before delegating.

Find where work depends on the owner’s knowledge, decisions, relationships or access. Use a practical dependency log before redesigning responsibilities.

DutyGraph editorial · September 14, 2026

You have handed off the tasks, but the questions keep returning. Can we make an exception for this customer? Which supplier should we use? Is this the version of the quote that was approved?

Telling the team to “take ownership” may not fix the problem. First determine what they still need from you. The missing piece could be knowledge, decision authority, a relationship, access to information or a rule that has never been made explicit.

Four dependencies that can look like the same problem

Knowledge: Only you know the history, exception or reasoning needed to continue.

Decision authority: Someone understands the situation but is not authorized to decide.

Relationship: A customer, supplier or internal stakeholder expects the answer from you personally.

Information or system access: The necessary record or capability is not available to the person doing the task.

These categories are a practical diagnostic, not a validated scoring system. A single interruption can involve more than one.

Keep a short dependency log

For a chosen period, record the requests that come back to the owner. Capture the workflow, question, person asking, missing information and decision required. Do not log sensitive customer details in a public form or use the exercise to rank employees.

Then ask: “Could the person proceed with clearer information, an agreed boundary, another reviewer or a different handoff?” Some decisions should remain with the owner. The objective is to distinguish those decisions from preventable interruptions.

Use a recent case rather than a general job description

“Tell me what you do” can produce a broad list. A more useful prompt is: “Walk me through the last order you could not complete without asking me.”

Follow the case from its starting event to the blocked decision. What arrived? What was missing? What had already been checked? What specifically did the owner know or authorize that the employee did not?

The process discovery interview questions provide a repeatable way to collect these details.

Example: pricing exceptions

Illustrative: A sales employee asks the owner to approve a discount. That may be a required commercial decision. But if the owner is only retrieving the same approved price list each time, the problem may be information availability instead.

Do not resolve this by writing “sales owns pricing” into a responsibility chart. Establish which decisions sales can make, the evidence needed and when an exception must be escalated. A new process description does not itself change approval authority.

Turn the dependency into a work record

Document the duty, specific task, usual performer, required information, decision boundary and receiving team. Use the roles and responsibilities worksheet to capture these relationships.

For dependencies at department boundaries, check the handoff acceptance conditions. An owner often becomes the translator when two teams have not agreed what a usable input looks like.

How DutyGraph fits

DutyGraph supports a leadership conversation followed by private voice or text requests to the team. An advisor can compare the owner's account with the people performing the work and identify what needs clarification.

The method is intended to make dependencies easier to examine. It does not prove that the owner can exit day-to-day operations, eliminate the need for judgment or produce a valuation uplift.

A better next step than another delegation memo

Choose one workflow that repeatedly returns to you. Identify the participants and one or two recent examples. The first goal is to understand the dependency clearly enough to decide what, if anything, should change.

Discuss a scoped business operations audit.