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 room can’t answer — if there’s no scorecard, no number, no owner — that’s your answer. There is no scorecard. And that’s exactly the problem.
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’ve got 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.
The scorecard is the input every other chapter references. Take an hour with your leadership team, ideally before your next L10, to score each dimension and write the scores down. Every chapter ahead will ask you to come back to them.
Chapter 3: 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.
Pick the role you flagged earlier. Think through what that person actually spends their week on — the work as it happens, not the work as the job description writes it. Then sort each 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.
Consider a typical professional services role — a Project Coordinator at a mid-sized firm. (This is an illustrative composite, not a specific client.) Here is what the sort looks like:
| 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 illustrative Project Coordinator: 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.
Now that you’ve split the role into Column A and Column B, map the hybrid version: who does what when human and agent share the role. The human manages; the agent does the labor that follows rules.
| Human Manages (Column A) | Agent Labors (Column B) |
|---|---|
| Reviews agent-generated status reports; flags items that need a human conversation | Generates weekly status reports from project data |
| Manages scope negotiations (reads client politics, makes the judgment call) | Updates the change log after each negotiation |
| Sits in on relationship-at-risk client calls | Drafts the follow-up notes and action items |
| Coordinates cross-functional priorities between teams | Tracks task dependencies and surfaces blockers |
| Decides whose pricing exception to honor | Applies documented exception rules and flags edge cases |
This hybrid split is enough to see the shape of the redesigned role. Chapter 6 introduces the full design instrument — the TML framework (Task / Management / Leadership) — which sorts work into three categories rather than two; for now, the two-column version is the right starting point.
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 4: 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. (You may not know your constraint yet — that’s exactly what Signal in Chapter 5 is for. Write your best guess. Signal will sharpen it.) This is your draft constraint.
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.
The blank Sprint Planning Canvas table sits in Chapter 4 above the populated Meridian example. Copy the eight-row structure into the tool of your choice and fill in each row as the stage chapters teach you how.
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 5: 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. Trace each one to root with the Five Whys, out loud, with the people closest to the work. 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 6: 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 the constraint workflow depends on. 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 7: 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 operational authority over the workflow? Are they willing to shift from executing the work to directing the team that executes it? 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 7b: 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 three TML categories — Task, Management, Leadership. Count the tasks in each bucket. If more than half land in Leadership (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 8: 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. Start with context windows for small datasets. Move to RAG when the data outgrows the window. Fine-tune only when neither gets 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 five-question test. Document the results. Fix any failures and retest. The test results are part of the Build handoff to Deliver.
Chapter 9: 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 10: Compound
These steps run the Sprint Retrospective, install the one design change, re-rank the Constraint 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 11: 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. 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 12: 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.
Appendix: Prompt Engineering
This step closes the loop between agent output and the design discipline this book describes. If a prompt is producing weak output, the diagnosis usually lives upstream — in Source.
Take your most recent agent interaction that produced disappointing output. Run the four-step diagnostic. Was the problem in the prompt, or in the context? If you don’t have a Knowledge Map for the constraint the agent was working on, that’s your answer — the context was never designed.