---
name: crawl-walk-run-launch-plan
description: Use this skill when a practice is about to launch, restart, or add a Medicare between-visit program, has inherited one it didn't design, or has a pilot that has run without a decision, and wants a plan that starts with one program and one cohort and grows only when the operation proves it works. It picks the program from the practice's own Opportunity Map and Practice Math, sizes a 50–100 patient crawl cohort with one clinical champion, writes success and kill criteria before the first patient enrolls, lays out the ninety-day plan in seven blocks, runs the weekly Capture Ladder fix loop, and ends the crawl on a date with stop, hold, or walk, then sets the entry requirements for walk and run. Triggers on requests like "help us launch CCM," "plan our first ninety days," "write our success and kill criteria," "how big should the pilot be," "our pilot has been running a year," "should we stop, hold, or walk," "we want to enroll everyone at once," "I just took over a program as administrator," or "are we ready to scale."
---

# Crawl, Walk, Run Launch Plan
This skill is Labor as Code™ for the launch method in *Getting Paid to
Do the Right Thing*. Labor as Code is a skill
that encapsulates a person's knowledge, judgment, taste, and skill in
durable, inspectable, versioned form. The know-how is starting a
between-visit program small enough that being wrong is cheap, watching
every step before automating any of it, and ending the first stage on
a date with a decision instead of letting it drift.

The method lives in "Test One Program for Ninety Days Before You Grow It": the five parts of a crawl, the
stage gates (Table 12.1), the ninety-day plan (Table 12.2), Riverbend's
success and kill criteria (Table 12.3) and its crawl week by week
(Table 12.4), the pilot trap, the walk, the run's four measurements
(Table 12.5), and Maria Okafor's first thirty days with an inherited
program. "Medicare Has Paid for Care Outside the Visit for Over a Decade" gives the
Opportunity Map the program choice starts from, and "A Program Survives Only if Each Patient-Month Covers Its Cost" gives the Practice Math it's checked against. Read them
for the argument and the cases, including Summit Endocrine's six hundred
enrollments in eight weeks. This skill builds the same plan for the
user's practice and never reuses Riverbend's counts or criteria as the
user's.

**The skill plans; the partners decide.** It drafts the criteria, the
plan, and the day-90 recommendation. The partners sign the criteria
before launch and make the stop, hold, or walk call. The skill never
writes a criterion after the results are in; criteria written afterward
describe what happened and don't judge it.

**The skill works from counts.** Opportunity Map counts, Capture Ladder
counts, minutes, and a de-identified crawl log. No patient records come
into the session.

## Before running

1. **Find out where the practice is.** Before launch (start at Step 1),
   mid-crawl (start at Step 5 with the log), at day 90 (Step 6), deciding
   whether to walk or run (Step 7), or newly responsible for a program
   someone else started (Step 8).
2. **Ask for the size of the organization.** Solo or small practice,
   small group with several sites, or large group or health system. The
   walk changes with size.
3. **Ask for the pressure.** A vendor offering to enroll the whole
   list, a partner who wants revenue this quarter, a pilot nobody wants
   to disturb. Name it; the plan has to withstand it.

## Step 1: Pick one program from the practice's own counts

1. Start from the patients' problems, not the fee schedule. Have the
   user count Medicare patients by the Opportunity Map's ten groups
   (continuity, transitions, monitoring, behavioral health, navigation,
   social barriers, caregivers, prevention and planning, serious
   illness, chronic pain), each with the definition they used. The
   groups overlap; the shape matters, not the total.
2. For a solo or small practice, expect two or three groups to matter.
   For a small group, build the map per site. For a large organization,
   build it per clinic and don't average.
3. Match the two largest relevant groups to candidate programs, and
   check each candidate against the user's Practice Math (the
   `practice-math-program-model` skill runs it). Pick the program whose
   base case works at realistic participation and realistic labor cost.
   Weigh what the team already knows how to do and how much new
   machinery the program needs (monthly programs need a registry and a
   queue; event programs need a trigger; team-based programs need
   defined roles).
4. One program. Not two. Two at once and nobody can tell which one is
   teaching what.

If no Practice Math exists, say the program choice is provisional until
it does.

## Step 2: Define the crawl

A crawl has five parts, and the skill checks each one:

- **One program.** From Step 1.
- **One cohort of 50–100 patients.** Small enough that one coordinator
  knows every patient by name by the third week; big enough that the
  ladder's gaps show up as patterns. The book prefers a cohort defined
  by one physician's panel, because it gives the champion a reason to
  care and keeps the escalation path short. Keep the crawl to one payer's
  rules (the book's example is traditional Medicare only) if the panel
  mixes payers.
- **One clinical champion.** A named physician who signs care plans,
  takes escalations, and attends the weekly review, with the minutes
  blocked on a real calendar.
- **Explicit success and kill criteria.** Step 3.
- **Manual observation of every step.** Someone writes down what
  happens at each step of the Attention Loop (Find, Enroll, Attend,
  Record, Collect, Verify): how long it took, who did it, where the
  information came from, where it went next.

Size the crawl's staff time from minutes if the user has them: cohort ×
(care + admin minutes per enrolled patient-month). Budget more than the
arithmetic says, because watching every step takes time. Say plainly
that the first crawl month will likely cost more per patient than the
old way; that's the price of learning, and it's why the cohort is small.

If anyone proposes enrolling the whole eligible list, or a vendor offers
to enroll hundreds of patients in weeks, show the arithmetic the book
uses against it: patients × the program's monthly required minutes is
the care work owed every month from the first bill, before admin
minutes, and every patient needs to understand a monthly charge. Enroll
at the speed the team learns, not the speed someone else can dial.

## Step 3: Write the success and kill criteria before launch

Draft them from the user's baseline ladder, admin minutes, cohort size,
and champion. Rules:

1. Every criterion is a number the practice can measure from counts it
   already collects, with the date it will be measured.
2. Include at least one criterion about whether patients were helped
   (Riverbend used contact within two business days after emergency
   visits and discharges), and at least one about staff workload
   (Riverbend used whether its nurse left on time four days of five).
3. Remove criteria that use revenue alone or that need new software to
   measure.
4. A kill criterion must trip on a trend visible by day 75. Replace any
   that trips only on catastrophe ("a compliance finding").
5. For each criterion, say how it could be gamed without improving
   anything, and tighten it.

Typical kinds, all with the user's own targets: served rate in the
second crawl month; admin minutes per enrolled patient-month by day 90;
claims sent without documented consent and a signed care plan (the book
sets this at zero); collection rate; the helped proxy; the workload
criterion. Typical kills: admin minutes on a day-75 spot check above the
old program's level; a served rate below a floor; patient complaints
about charges traced to the enrollment conversation.

Mark the list "draft: partners to sign on [date]." The partners sign it
in days 11–20.

## Step 4: Lay out the ninety days

Use the book's seven blocks and the deliverable each ends with:

| Days | The job | What you have at the end |
| --- | --- | --- |
| 1–10 | Define the question and take a baseline | A current Capture Ladder from counts, and a two-week admin-minutes log started |
| 11–20 | Pick the program and the cohort using Practice Math | One program, one named cohort, one champion, and written success and kill criteria |
| 21–30 | Map the Attention Loop by hand for that program | A step-by-step map with owners, minutes, handoffs, and where each piece of information lives |
| 31–45 | Launch the crawl | Patients enrolling, every step logged, the consent script revised at least once |
| 46–60 | Measure the Capture Ladder weekly and fix the widest gap | A weekly ladder, one gap named as the widest, one fix tried and checked |
| 61–75 | Automate the three most repeated admin tasks | Three tasks moved from people to software, and minutes measured before and after |
| 76–90 | Decide: stop, hold, or walk | A written decision with a date, signed off by the partners |

Put real dates on each block. Add the book's specifics:

- Days 21–30: walk the Attention Loop for one imaginary patient on a
  whiteboard with the people who'll do the work. For each step, write
  who does it, how long it takes, what they need to know, and where they
  get it. Mark every step where the answer is one person's memory; those
  are the steps to watch hardest.
- Days 31–45: launch at the start of a calendar month if the program
  bills monthly, so crawl months line up with billing months.
- Days 46–60: build the cohort's ladder every Monday, name the single
  widest gap, try one fix, check it the next Monday. One gap at a time.
- Days 61–75: take the three admin tasks the log shows were repeated
  most, move them to software, a report, or a checklist, and measure
  minutes before and after. Check first whether the existing EHR
  contract already includes a module nobody switched on. Don't automate
  a step nobody has watched a person do.

Thirty of the ninety days happen before the first patient enrolls. If
the user wants to compress them, say what the book says: the practices
that compress those thirty days spend the next sixty guessing.

## Step 5: Run the weekly loop during the crawl

When the user brings a week's log or ladder:

1. Compute the cohort's ladder and the drop at each rung.
2. Name the widest gap and one fix, with an owner.
3. Record one thing the practice stopped doing, if the week produced
   one. Habits left over from an old attempt (calling in list order,
   counting minutes on sticky notes, a spreadsheet) usually never stop
   unless someone decides they stop.
4. Check last week's fix against this week's number.

Use the `capture-ladder-diagnosis` skill for any gap whose cause isn't
obvious.

## Step 6: End the crawl on a date with one of three words

On day 90 (or the date the partners set), grade the crawl against the
criteria signed before launch, not a new set. For each criterion:
target, result, met or missed, and where a miss points. Note which
results are ahead of their remittances; a crawl decision usually runs a
few weeks ahead of its paid claims, so say which month's collection rate
the decision rests on.

Recommend one of the book's three answers:

- **Stop.** The program doesn't belong in this practice now. Tell
  enrolled patients plainly, close out the month's billing, and write
  down what was learned so the next attempt starts from it.
- **Hold.** One named problem stands between the practice and a walk.
  Fix it for thirty more days, then decide again. One hold only. A
  second hold is a stop nobody has admitted yet.
- **Walk.** The criteria were met, or the misses point somewhere
  specific. Move on a written schedule, with the conditions written into
  the decision and a date by which the partners vote again if they
  aren't met.

Give the reasoning, tied to specific criteria. Where the results
genuinely support two answers (for example, most criteria met but a
workload criterion missed for a cause that may or may not be the crawl
itself), present both side by side with what would make each right, and name the fact that would settle it.
If a kill criterion tripped, say so first; the recommendation has to
answer it.

Watch for the pilot trap. A crawl still at its starting size long past
its decision date, working well enough that nobody wants to disturb it
and not well enough that anyone wants to bet on it, is a pilot trap. If
the user describes one, the recommendation is to set a decision date
now and grade against the original criteria, or write them now and say
plainly that they were written late.

## Step 7: Set the gates for walk and run

**Walk** requires that the crawl met its success criteria for two
consecutive months and the partners said "walk" on a specific date.
Plan the walk's three jobs:

1. **A written workflow,** one page per Attention Loop step. The test:
   could a new medical assistant hired next spring run the step from
   the page? Delete any step the crawl log doesn't show; generic steps
   describe a vendor's workflow.
2. **Automate the next repetition the log exposed,** ranked by total
   minutes.
3. **Bring in the rest of the eligible patients in batches** small
   enough to watch, each with its own first-month ladder so the practice
   can see whether new patients behave like the crawl cohort.

Only then a second program, as its own crawl with its own champion and
criteria, after the first program meets its criteria for two
consecutive months at the larger size.

By size: a solo or small practice walks with the same people who ran
the crawl, and writing the workflow matters most because the program
still lives with one nurse. A small group walks one site first, copies
the written workflow to a second site, and compares the two ladders
month by month. A large group or health system crawls at one site and
walks at two or three before anyone draws an organization chart.

**Run** requires that the practice can produce four monthly measures
for every program without a special project: quality (whether patients
were helped), exceptions (escalations opened, closed, and past deadline;
patients who fell off), margin (contribution margin per enrolled
patient-month from actual minutes and collections), and patient
experience (complaints, questions about charges, who stopped and why).
List which of the four the user can produce today and which still take
hand work. Adding patients before these numbers come easily is walking
faster, which is more dangerous than walking.

## Step 8: If the program was inherited, observe for thirty days first

For a new administrator walking into a running program, treat it as a
crawl someone else designed and observe before changing anything. The
book's five moves, in order:

1. Build the Capture Ladder from counts.
2. Find out who owns each step, including steps a vendor owns and steps
   nobody owns.
3. Read ten patient records end to end (the user does this, not the
   skill).
4. Pull the vendor contract's payment terms and name the behavior each
   term rewards. Flag any term that rewards billing activity whether or
   not the patient is helped.
5. Put the program on hold for new enrollment only. Existing patients
   keep their services until the problems have owners.

Build a week-by-week thirty-day plan: what to look at, which counts to
pull, what question each count answers. Strike any step in the first
thirty days that switches vendors, restructures staff, or changes
clinical protocols; the plan's job is to produce facts. On day 30, the
recommendation is stop, hold, or walk, as in Step 6.

## Checks before calling the work done

- **One program and one cohort of 50–100 patients,** with a named
  champion and blocked minutes.
- **Criteria were written before launch,** each a number with a date,
  with at least one helped criterion and one workload criterion, and
  every kill criterion visible by day 75.
- **Every block of the ninety days has a date and a deliverable.**
- **The day-90 answer is stop, hold, or walk,** graded against the
  original criteria, and a second hold is called a stop.
- **Walk and run each have their entry requirement stated,** and the
  plan doesn't grow before it's met.

## What this skill does not do

It doesn't pick a program on payment rate alone, and it doesn't borrow
Riverbend's cohort, criteria, or targets as the user's. It doesn't
write criteria after the fact to match the results. It doesn't make the
stop, hold, or walk decision; the partners do. It doesn't recommend a
vendor or switching one in the first thirty days of an inherited
program. And it doesn't treat enrollment speed as progress. Served rate,
documentation quality, patient understanding, and whether anyone was
helped lag by weeks or months, and a practice that enrolls faster than
it can observe is borrowing against numbers it can't see yet.