# The two-week dependency test and scoring rubric

Use this to build the first dependency map, and again every quarter to refresh it.

## The two-week test

Imagine you are unreachable for two weeks: no calls, no texts, no email replies. Walk through a normal two-week stretch of the business and write down everything that would stall, slow down, or go wrong because you specifically were not there to do it, approve it, or answer a question about it.

Rules for the list:

- One line per item, not a category. "Sales" is not an item. "Approving every quote over $2,000" is an item. "Quarterly tax filing" is not an item. "Reviewing the bookkeeper's numbers before they get filed" is an item.
- Only list things that depend on you personally: your access, your signature, your knowledge, your relationship with a specific customer or vendor, or your judgment call. If someone else already owns it end to end and just happens to loop you in out of habit, that is a different problem (a habit to break, not a dependency to fix) and does not belong on this list.
- Write it down even if it feels small. A five-minute approval that happens nine times a week is a bigger dependency than a two-hour task that happens once a quarter.

Aim for at least 15 to 20 items on the first pass. If you get fewer than 10, you have probably been grouping things into categories instead of listing the actual tasks. Go back through a real week's calendar, inbox, and phone log and pull out what you touched.

## The ownership-dependency diagnostic

Score every item on the list against these four questions. Use the 0 to 3 scale under each question, then add the four numbers for a total score out of 12.

**1. Who does the customer think they're buying from?**
- 0: The company. The customer has never asked for you by name.
- 1: Mostly the company, but you've stepped in a few times.
- 2: You, with the company as a secondary relationship.
- 3: You personally. If you left, this customer believes the relationship ends.

**2. Where does the process live?**
- 0: Written down somewhere (a doc, an SOP, a checklist) that someone else could follow today.
- 1: Mostly written down, with a few steps only you know.
- 2: Lives mostly in your head, with scattered notes.
- 3: Lives entirely in your head. Nothing is written down anywhere.

**3. Does anyone else have real authority to decide this?**
- 0: Yes. Someone else can make this call and it sticks, no check-in with you required.
- 1: Someone else can decide it below a stated threshold (a dollar limit, a scope limit).
- 2: Someone else can decide it, but in practice always checks with you first.
- 3: No. Only you can make this call, formally or by habit.

**4. How much of your week does this cost you, reviewing and approving versus building and selling?**
- 0: Under 15 minutes a week.
- 1: 15 to 60 minutes a week.
- 2: 1 to 3 hours a week.
- 3: Over 3 hours a week.

**Total score (0 to 12) and what it means:**

| Score | Read it as |
|---|---|
| 0 to 3 | Low risk. Not urgent, revisit next quarter. |
| 4 to 7 | Medium risk. Worth redesigning in the next month. |
| 8 to 12 | High risk. This is a task where the business genuinely cannot run without you right now. Fix this one first. |

Do not substitute gut feeling for the score. The point of the rubric is that a task you personally enjoy (and therefore want to believe is "fine to keep doing") gets scored the same as any other task. If it scores 8 or higher, it goes near the top of the list regardless of how much you like doing it.

## Sorting and storing the map

1. Sort the scored list highest total first.
2. Within a tie, put the more customer-facing and more frequent item higher.
3. Check your sorted list against `examples/audit-filled-example.md` for the level of detail expected. That file is a pattern to match for specificity, not a source of facts for your business; none of its numbers or task names are yours.
4. Save the dated list somewhere you'll actually reopen it (a shared doc, a spreadsheet, a pinned note). Date the file name or the top line ("Dependency map, reviewed 2026-10-06") so the next quarterly pass knows what it's updating instead of rebuilding from scratch.
5. Pick the single highest-scoring item to redesign first. One handoff at a time beats trying to fix the whole list in a week.

# The six-point failure lens and the four-part handoff brief

Use this before any task moves to someone else, whether it's the first handoff or a re-handoff after work came back wrong.

## The six-point failure lens

Before writing a new brief, check the task (or the last attempt at delegating it) against these six points. Name which ones are actually broken. Most failed handoffs trace back to one or two of these, not all six.

1. **Outcome versus activity.** Was the person told what "done" looks like as a result ("the customer has a signed quote and a scheduled start date"), or just handed a list of things to do ("call the customer, send the quote, follow up")? A list of activities can be completed perfectly and still miss the outcome.
2. **Decision rights.** Did the person actually get to decide anything, or did every real call still route back to you? If every judgment call still needs your sign-off, you haven't delegated the task, you've delegated the typing.
3. **Where the process lives.** Was the method written down somewhere the person could check, or did they have to guess at steps that only exist in your head?
4. **Inputs and channel.** Did the person have everything they needed (numbers, access, prior history with the customer) before they started, arriving through one defined place (an email, a shared doc, a ticket), or did they have to chase down pieces as they went?
5. **One named owner.** Is exactly one person accountable for this task, or is it "the team" or "whoever has time"? A task owned by a group is a task nobody actually owns.
6. **Tools and status reporting.** Does the person know which tool to use and when and how to report status, or are you finding out the task is behind by asking?

Write down which of the six failed. If the brief below doesn't fix that specific point, it will fail the same way again.

## The four-part handoff brief

Fill in each part using only what you actually know about this task. Never invent a deadline, a dollar figure, or a scope boundary you haven't actually set; leave it blank and go find the real number instead.

```
TASK: [the one task from the dependency map]
DATE DRAFTED: [date]

1. OUTCOME (a result, not a to-do list)
When this is done, what exists that didn't before? Describe the end state,
not the steps to get there.

2. ACCOUNTABLE OWNER
Exactly one name. Not a team, not a role left to whoever's free.

3. DECISION BOUNDARIES
What can [owner] decide alone, no check-in needed?
-
-

What must come back to [you] before it moves forward?
-
-

4. ACCEPTANCE CONDITIONS
What will you personally check before you call this done?
-
-
-
```

A filled example of this exact template, for a real task, is in `examples/handoff-brief-example.md`. Match its shape and level of detail; it is a pattern, not a source of facts for your task.

## Before this brief goes anywhere

- The brief is not final until it has been reviewed and approved. Nothing goes to the delegate until that approval happens.
- Once approved, deliver it through your own channel (in person, your email, your project tool). This brief is a draft to approve and hand off yourself, not something sent on anyone's behalf.
- Log the task, the date it was handed off, and the acceptance conditions somewhere you can check back against when the work is due. You'll need this log the next time this same task comes around, to see whether it needs documenting (see `references/documentation-rule.md`).

# The first-run-versus-second-run rule

## Why the first run doesn't get written up

A task that has only run once is still unstable. The first time someone does a handed-off task, you're watching for whether the brief itself was right: was the outcome clear, did decision rights land where they should, were the inputs complete. Writing a standard procedure from a single run usually just writes down whatever happened to go wrong (or right) that one time, which is the exception, not the rule.

Wait for the second run. On the second time this exact task comes around, whether it went well or came back wrong, that's when you write the SOP.

## What to do on the second run

1. Interview whoever ran the task both times (yourself, if it was you, or the delegate). Ask specifically:
   - What were the actual steps taken, in order, both times?
   - Where did the person pause, ask a question, or guess?
   - Where did the result diverge from what you actually wanted?
2. Write the SOP from what was observed on those two runs, not from how you imagine the task should go in theory. If step 4 on paper is "confirm the measurements," but in practice the person always double-checks with the customer by text first, write down the text-check. The real process beats the idealized one.

## The SOP template

Each step states the action, what it needs as input, and the check that confirms it was done right.

```
SOP: [task name]
OWNER: [accountable person, from the handoff brief]
LAST UPDATED: [date]

STEP 1
Action:
Input needed:
Check (how you know this step was done correctly):

STEP 2
Action:
Input needed:
Check:

[... one block per step, in the order they're actually done ...]

FEEDBACK LINE
If anything in this SOP is unclear or doesn't match what actually happens,
write the correction directly into this document (don't just mention it
in conversation). Note what changed and the date.
```

The feedback line matters as much as the steps. If the delegate only ever raises a question verbally, the correction lives in that one conversation and the next person who runs the task hits the same confusion. Writing it into the document is what keeps the SOP current instead of slowly going stale.

## Approval and what happens after

Show the drafted SOP to whoever owns this task area before it becomes the standing procedure. Once approved, this SOP replaces the handoff brief for this specific task going forward. The next time this task is handed off (a new hire, a different contractor, a vacation fill-in), you point them to the SOP instead of writing a fresh brief from zero.

# The continuity checklist: what a checklist alone can't replace

Run this once a year, or any time you start seriously thinking about taking real time away from the business. These three items sit a level above task handoffs and documented SOPs: they're structural, legal, and financial instruments, not procedures you can write yourself. This checklist tells you which professional to call for each one; it does not draft any of them.

## 1. A stay arrangement for whoever runs things in an unplanned absence

If you were out for two weeks with no warning, is there a specific person who would run day-to-day operations, and do they have a reason to stay and do it well (a retention bonus, a defined temporary pay bump, a clear path to a bigger role if it goes well)? Without that arrangement, the person most able to keep things running during a crisis has the least reason to stick around during one.

- [ ] A specific person is named for this, not "whoever's senior."
- [ ] That person knows they're the one, in writing.
- [ ] There's a financial or career reason for them to stay through a rough stretch, not just goodwill.

**Who to involve:** an employment attorney or an HR advisor, to structure this correctly and avoid creating a legal obligation you didn't intend.

## 2. Advance disclosure to your bank or lenders

If you have a business loan, a line of credit, or a lease that names you personally, check whether the agreement has a key-person clause or a change-of-control trigger, and whether your lender already knows there's a continuity plan in place. A lender who is surprised by your absence behaves very differently from one who was told the plan in advance.

- [ ] You've pulled the actual loan and lease documents and checked for key-person or change-of-control language.
- [ ] Your banker or lender has been told, in advance, who takes over and how.
- [ ] Any required notice period for a change in ownership or management is known, not assumed.

**Who to involve:** your accountant and your banker directly; a business attorney if the loan documents have unclear or restrictive language.

## 3. A named person pre-authorized to act during an absence

If something happened to you tomorrow, could anyone sign a check, approve a wire, access the business bank account, or make a binding decision on the company's behalf, legally? Most owner-led businesses have no one pre-authorized for this, which means routine operations (payroll, vendor payments, signing a renewal) stop the moment you're unreachable, not just the judgment calls.

- [ ] A specific person has been granted operational or financial authority to act in your absence (a power of attorney, a bank-authorized signer, an operating agreement amendment, whichever applies to your structure).
- [ ] That authorization is on file with the bank or institution that would need to honor it, not just in a drawer.
- [ ] You've confirmed with your insurance advisor whether a key-person policy makes sense given what this absence would actually cost the business.

**Who to involve:** a business or estate attorney to draft the authorization correctly, your insurance advisor for the key-person question, your accountant to confirm it's reflected correctly in the company's records.

## What this checklist is not

This is a list of what to ask for, not a legal document. Do not treat any box you check here as the authorization, the disclosure, or the policy itself. Each one needs the named professional above to actually exist. Checking a box without making the call is the same as not checking it.

# Worked example: a filled dependency map (one task)

This shows the level of detail and the scoring expected from `references/bus-factor-audit.md`. The business, the person, and the numbers below are illustrative only: a pattern to match for specificity, not facts to copy into your own map.

**Business:** a 9-person commercial landscaping company.
**Owner:** Dana.
**Task from the two-week list:** "Approving every change order over $1,500 on an active job."

## Scored against the ownership-dependency diagnostic

**1. Who does the customer think they're buying from?**
Score: 1. Most commercial clients deal with the project manager day to day. Dana only gets looped in for the change-order sign-off itself, not the relationship.

**2. Where does the process live?**
Score: 3. There is no written threshold logic. Dana eyeballs each change order against the original bid and her sense of the client's budget tolerance, something she has never written down.

**3. Does anyone else have real authority to decide this?**
Score: 3. The two project managers both route every change order to Dana regardless of size, because the $1,500 line was never formally delegated to them.

**4. Time cost per week?**
Score: 2. Averaging 4 to 6 change orders a week at roughly 15 to 20 minutes each (reviewing the bid, texting a project manager with questions, approving or sending back), this runs just over 1.5 hours most weeks.

**Total: 9 out of 12. High risk.**

## Why this one gets fixed first

At a score of 9, this task sits above several others on Dana's list (vendor contract renewals scored 5, new-hire onboarding scored 4) because it is weekly, not quarterly, and because the lack of a written threshold means every project manager defaults to "ask Dana" even on change orders that are clearly within normal bid variance. This is the item Dana picks to run through Phase 2 (the handoff redesign) next. See `examples/handoff-brief-example.md` for the brief built from this exact task.

# Worked example: a filled four-part handoff brief

Built from the task in `examples/audit-filled-example.md` ("approving change orders over $1,500"), using the template in `references/handoff-redesign.md`. The names and numbers are illustrative; match the shape and the level of detail, not the content.

```
TASK: Approving change orders over $1,500 on an active landscaping job
DATE DRAFTED: 2026-09-14

1. OUTCOME (a result, not a to-do list)
The client has a signed, itemized change order on file before any additional
work starts, and the job's budget variance stays inside 12% of the original
bid unless Dana has specifically approved going over that.

2. ACCOUNTABLE OWNER
Marcus (senior project manager, 6 years with the company)

3. DECISION BOUNDARIES
What can Marcus decide alone, no check-in needed?
- Any change order under $3,000 that keeps the job's total budget variance
  inside 12% of the original bid
- Change orders requested in writing by the client (email or signed form),
  regardless of amount, as long as the 12% variance line holds

What must come back to Dana before it moves forward?
- Any change order, of any size, that would push the job's total budget
  variance past 12% of the original bid
- Any change order the client is requesting verbally with no written
  confirmation yet

4. ACCEPTANCE CONDITIONS
What will Dana personally check before she calls this done?
- The signed change order is in the shared job folder before work starts
- The running budget-variance number for the job is updated the same day
- Any change order Marcus approved alone is logged with the client's written
  request attached, so Dana can spot-check a sample each month
```

## What happened after this brief was approved

Dana reviewed and approved this brief, then delivered it to Marcus directly in their weekly one-on-one and followed up with the written version by email the same day. The task was logged with the date handed off and the acceptance conditions above, so Dana had something to check against the next time a change order came up.

The first run surfaced one gap: the 12% variance line didn't account for change orders that were themselves corrections to an earlier mistake (re-doing drainage work that failed inspection). On the second run of the task, this got folded into a documented SOP per `references/documentation-rule.md`, with an explicit carve-out for correction work, and that SOP now replaces this brief for every future change-order approval on that crew.

Usually one of six things broke in the handoff: the outcome was described as activity instead of a result, you kept the real decision rights, the process only existed in your head, the inputs were incomplete, no single person was named accountable, or the tools and reporting expectations were never stated. Name which one broke before you redo the handoff.

Run the two-week test: list everything that would stall or slow down if you were unreachable for two weeks, restricted to tasks only you can do, access, or are trusted to approve. Score each item on customer trust, tribal knowledge, decision authority, and how much of your week it eats.

A four-part brief: the outcome described as a finished result, one person named as accountable, the decision boundaries for what they can decide alone versus what comes back to you, and the acceptance conditions you'll check before calling the work done.

Wait for the second time the task repeats. A task that has only run once still describes the exception, not the rule, so an SOP written that early usually documents the wrong thing.

Every quarter. The dependency map isn't a one-time list, it's something you keep updating as tasks move off your plate and new ones land on it.

Start with the two-week dependency list, not the vacation plan. Fix the highest-risk, most customer-facing items first, since those are what actually breaks when you step away.