Action Step Index
This appendix collects every Action Step from the book in sequence. Use it as a checklist — work through the steps that match wherever you are in the Sequence. If you’re running your first sprint, start with the Signal steps and work forward. If you’re mid-rhythm, use this as a review to catch anything you skipped.
Chapter 1: Diagnosis
These steps establish your operational baseline — naming where the AI problem actually lives in your company and scoring your readiness to address it.
Walk into your next L10 or leadership meeting with this question: “If AI were an employee, what would its scorecard say?” Write down whatever the room produces. If the answer is silence, that silence is the diagnosis.
Poll your leadership team individually — not in a group. Ask each person: “What is the ONE operational problem AI should solve for us?” Write down their answers verbatim. If you get five different answers from five people, you have your diagnosis.
Pick your most critical workflow. Ask the person who owns it: “If you had to hand this off to someone new on Monday, what would you give them?” Whatever they describe is the actual state of your documentation — not whatever lives in SharePoint.
Whiteboard your most constrained workflow in fifteen minutes. Put every handoff on the board. Circle the ones where work stalls, errors appear, or people say “I’ll just handle it myself.” Those circles are where the real problem lives.
List the five most frequent decisions in your constrained workflow. For each one, write down who currently makes the decision and whether it requires judgment or just follows a rule. The rule-based ones are AI-eligible. The judgment ones need a human-in-the-loop design.
Do the math right now. Hours per week spent on the constraint, multiplied by loaded cost per hour, multiplied by thirteen weeks. That’s your quarterly cost floor. If you can’t fill in the numbers, write down what data you’d need and where you’d get it. That gap is your first task.
Before you turn the page, fill in the scorecard. All five dimensions. Write the scores down — don’t just read the descriptions and nod. The scorecard travels with you through the rest of the book, and every chapter will ask you to reference it. Sixty minutes with your leadership team. Do it before your next L10.
Chapter 2: The Co-Operating Model
These steps map the human-versus-agent ownership split for a real role in your company and calculate the cost of not redesigning it.
Pick one role in your company — yours, or a direct report’s. Estimate: what percentage of that person’s week is spent on work that belongs in the right column? Write it down. That number is your baseline. You’ll use it before the chapter ends.
Take the role you picked earlier. List 10–15 tasks that person actually does in a typical week — not what the job description says, what they do. Pull their calendar. Check their sent folder. Then sort every task into Column A (Human Intelligence: judgment that changes based on context a machine can’t observe) or Column B (Agent Intelligence: processing that follows rules a machine could learn). Some tasks will split — “managing scope change requests” includes reading client politics (Column A) and updating the change log (Column B). Split those and sort each part.
Here is what this looks like for a Project Coordinator at a professional services firm:
| Column A (Human Intelligence) | Column B (Agent Intelligence) |
|---|---|
| Managing scope change requests (reading client politics, judging which changes to push back on) | Scheduling client and internal meetings |
| Coordinating between client and delivery team (navigating competing priorities, reading tension) | Sending weekly status update emails |
| Negotiating timeline adjustments (judgment on what to concede, what to hold) | Tracking deliverables against timelines |
| Handling client escalations (de-escalation, relationship repair, knowing when to involve leadership) | Writing meeting summaries and distributing action items |
| Flagging overdue items to project managers | |
| Updating scope change logs (dates, costs, approvals) | |
| Compiling lessons-learned documents from project notes |
Column B accounts for roughly 55% of this coordinator’s week. At a loaded annual cost of $65,000, that is $36,000 per year of human intelligence allocated to work that follows learnable rules.
Take the Column A / Column B sort you did earlier. Count the tasks in each column. Estimate the hours per week for each. Calculate the percentage of the role’s week that lives in Column B — that is your design opportunity, the share of the role that could be running on agent intelligence instead of human hours.
Write it as a single number: “This role is __% Column B.”
Now multiply that percentage by the person’s loaded annual cost (salary + benefits + overhead). That number is the annual operating cost of not redesigning this role.
For the Project Coordinator example: 55% Column B at $65,000 loaded cost = $36,000/year spent on work that follows learnable rules. That is the dollar value of human intelligence being spent on agent-intelligence work.
If Column B tasks were handled by agents, what would this person do with the freed capacity? Write a one-paragraph description of a typical day — not a vision statement.
Here is the Project Coordinator’s hybrid version: Monday morning starts with reviewing agent-generated status reports and flagging anything that needs a human conversation. The rest of the week goes to managing two difficult scope negotiations, sitting in on a client call where the relationship is at risk, and coordinating a cross-functional delivery problem that involves competing priorities between three teams. Meeting summaries write themselves. Overdue items surface automatically. The coordinator’s calendar is no longer consumed by administrative motion — it is consumed by judgment calls, relationship management, and the kind of coordination that keeps clients from leaving.
If you have multiple roles touching the same constraint, repeat this process for each one. Compile the results into a single table: Role, Column B %, Loaded Cost, Annual Misallocation Cost. That table is the raw material for the sprint design work in the chapters ahead.
Chapter 3: The Framework
These steps produce your first Sprint Planning Canvas — a compass for the sprint before Signal begins.
Write down the constraint you’d solve first. One sentence. If it takes more than one breath to read aloud, it’s too long. This is your draft Signal — you’ll sharpen it in Chapter 4.
Fill in a Sprint Planning Canvas for your company. Constraint in one sentence. One first-pass answer per stage. Name the Orchestrator. Book the review. A wrong first guess is better than a blank row — blanks stay blank, guesses get corrected.
Pick your constraint. Fill in the Sprint Planning Canvas. Book the quarterly review. The Sprint is real when the review is on the calendar.
Chapter 4: Signal
These steps walk you through the full Signal process — surfacing constraint candidates, tracing symptoms to root causes, quantifying costs, and locking the one constraint the sprint will solve.
Pick your top three candidates. Run Is/Is Not on each. Then run Five Whys on the survivors. Cross off anything that traces to a market condition, a personality, or a problem you can’t put a number on.
Open a whiteboard or shared doc. Spend twenty minutes listing candidates using the five questions above. No filtering, no debate about whether something belongs. Write everything down.
Fill in the one-page constraint statement template for your chosen constraint. Read it aloud to the team. If the room can’t agree that this is the one constraint worth a Sprint, you’re not done. Keep working until you have real agreement — the kind where people nod because the math convinced them, not because the meeting has gone long.
Pull your current issues list, your stalled rocks, and any open headcount requests. Pick the one that feels most expensive and run it through the five constraint questions. If you can put a real number on it, you have a constraint worth a Sprint. If you can’t, keep walking the list.
Chapter 5: Source
These steps produce the Knowledge Map — a one-page picture of what your organization knows about the validated constraint, where that knowledge lives, and what’s missing or at risk.
Open the constraint statement from Signal. List every digital system that touches the constraint workflow. For each one, fill in all six columns — Source, Type, Owner, Status, Pipeline, Notes. Don’t filter. If it touches the constraint, it goes on the map.
Name every person whose judgment is load-bearing for the constraint. For each one, write specifically what they know that no system holds. Flag anyone who’s a single point of failure.
Review your map from Pass 1 and Pass 2. Write down every gap — every question a designer would ask that your current sources can’t answer. Add them to the map as Missing sources.
Review each source on your map. Mark whether it’s structured or unstructured, durable or ephemeral, and which AI tier it belongs to — standing context, retrieved, or historical.
Identify the highest-risk organic source on your Knowledge Map — the person whose knowledge is most at risk of leaving. Schedule a structured interview this week. Ask: what decisions do you make that nobody else makes? Record it. Transcribe it. Add the output to the map.
Run the six-item completeness test against your Knowledge Map. Fix any gaps. Then put the constraint statement from Signal at the top of the page and the Knowledge Map below it. That one page is what you hand to Design.
Chapter 6: Designing the System
These steps produce the Hybrid Accountability Chart entry and the governance framework that make the designed workflow safe to hand to Build.
Pick one accountability from your constraint workflow. Write down the information flow: what data comes in, from where, what happens to it, what goes out, to whom. Don’t describe the role — describe the information. This is the foundation for everything Design produces.
For each accountability in your constraint workflow, place it on the AI-assisted-to-automated spectrum. Write down your rationale — not just the label, but why. “AI-assisted because the exception rules aren’t fully documented yet” is a rationale. “AI-assisted” by itself is a checkbox.
Identify your Human Orchestrator candidate. Ask: does this person have authority over the constraint outcome? Are they willing to shift from executing to designing? Write down the name. If there’s a development gap, name it — and plan the first sprint as the ramp-up, not as a test they need to pass.
Chapter 6b: Designing the Work
These steps run Work Deconstruction on your constraint workflow, visualize the design, and confirm all five Design Gate items are locked before Build begins.
List every task in the constraint workflow. Sort each one into the four categories. Count the tasks in each bucket. If more than half land in “Human judgment required,” challenge each one: is this genuinely judgment, or is it judgment because nobody has written down the rules? The exercise takes sixty to ninety minutes for a real role. Do it on paper or in a shared doc.
Pick the workflow you’re designing. Draw a swim lane diagram with two lanes — human and agent. Map every step. Count the handoff crossings. If the count is higher than the number of steps, redesign the handoffs before moving to Build.
Run the five-item Design Gate checklist against your current sprint’s design. If any item has a gap, that gap is your next working session — not your next Build discovery. Fix it now.
Chapter 7: Build
These steps translate the locked design into a developer-ready Build Spec, apply the Guardrails Checklist, and confirm the build is truly done before handing off to Deliver.
Before your next Build, ask: does the builder need to be a developer, or does the builder need to be the person who knows the work? If the answer is the second, put them in front of the tool and let them build. Pair them with IT for access and security — not for construction.
Pull the designed workflow from Design. Run the three-question decision tree above. Write down which path you’re on and why. If you can’t answer the questions without guessing, Design isn’t done — go back.
When a vendor or builder proposes fine-tuning, ask: “Could we get the same result by giving the model access to our data at query time?” If the answer is yes, you’ve just saved weeks and thousands of dollars. RAG first. Fine-tune only when RAG can’t get you there.
Open a document. Write the eight section headers. Fill in Sections 1-3 from your Design artifacts — if you can’t fill them without guessing, Design isn’t done. Then complete Sections 4-8 using the Hybrid Accountability Chart and Knowledge Map. Every section must have content before the spec goes to a builder.
Walk through all seven items with the builder present. Check each one against the completed spec. Any item that can’t be checked off is a gap that must be resolved before build begins.
Answer all seven questions in writing. Attach the answers to the Build Spec as a companion document. If any question can’t be answered, the build is not ready to deploy — resolve the gap before going live.
Pull last week’s real inputs. Run the full four-question test. Document the results. Fix any failures and retest. The test results are part of the Build handoff to Deliver.
Chapter 8: Deliver
These steps close the gap between “deployed” and “delivered” — training affected roles, logging what production reveals, measuring the sprint outcome, and confirming the change has actually taken hold.
Pull up your Hybrid Accountability Chart from Design. List every person whose daily work changes because of this sprint. For each one, confirm they’ve completed hands-on training — not a meeting, not an email. If anyone hasn’t, that’s your first task before deploy.
Pick one role from your Hybrid Accountability Chart whose handoffs changed. Write the three-column entry — input, output, escalation — in one sentence each. Be concrete: “Reviews output” is not specific enough. “Opens the quote draft in the shared folder, checks unit costs against the rate card, approves or flags within 4 hours” is.
Create the log template — four columns: Date, What happened, Category, What it signals — in whatever tool your team already uses. Name the person who owns it. Do this before you flip the switch, not after.
Go back to your Signal instrument. Copy the constraint statement and quantified cost exactly as written. Measure the same metric now — same unit, same timeframe, same source. Calculate the delta. Write the outcome in one sentence. No spin.
Chapter 9: Compound
These steps run the Sprint Retrospective, install the one design change, re-rank the Signal Backlog, and update the three living documents — turning the delivered sprint into the foundation of the next one.
Before the sprint enters Build, put the Compound session on the calendar. A 90-minute block with the Human Orchestrator and every supervisor who owned a sprint accountability. If it’s not scheduled before the sprint ships, it won’t happen after.
After the retrospective, write the one design change on a card with four fields: what the change is, who installs it, how you’ll know it’s working, and the date it’s installed by. If any field is blank, the change isn’t specific enough.
At the end of the Compound session, update all three living documents before anyone leaves the room. Chart row made permanent, backlog re-ranked, sprint outcome recorded in one sentence. Fifteen minutes. No exceptions.
Chapter 10: The Rhythm
These steps install the quarterly operating session into your existing cadence and start the Compounding Scorecard that proves the returns are real over time.
Put the quarterly operating session on the calendar for the end of this quarter. Book 90 minutes. Invite the leadership team. Set the agenda using the four steps above.
Create the Compounding Scorecard. Fill in the first row with your current sprint. Tape it to the wall next to your accountability chart.
Chapter 11: What to Do Next
These steps produce your First Sprint Plan — a one-page commitment with a named constraint, a team, a path, and a start date.
If you haven’t completed the AI Readiness Scorecard yet, go back to Chapter 1 and do it now. It takes ten minutes and tells you exactly where to start.
Decide which path you’re taking. Write it down. If Path A, schedule the Signal session with your team this week. If Path B, book the Clarity Call. The decision that doesn’t work is the one you defer.