Your Monday Morning Transformation Plan
The whole course, compressed
Here's eleven lessons compressed into what actually happens Monday morning.
Lesson 1 opened with a trial that should worry you: in METR's randomized controlled trial, experienced developers used AI tools on real tasks and felt 20% faster while measurably running 19% slower. That gap is the entire reason this course exists. A twelve-week automation push has no single before-and-after the way one task does, so a felt sense of "this is going well" is even easier to get wrong. The fix was a fixed Week 1 baseline and five numbers logged against it every week, never against last week, never against a memory of last week.
Lessons 2 through 4 got that fix running for real. The transformation-tracker skill (github.com/profrodai/transformation-tracker-course) has no install step, because log_week.py and report.py import only from Python's standard library. Clone it, or copy .claude/skills/transformation-tracker/ into a project you already have, and Claude Code reads SKILL.md on startup with no registration step. Logging a week is a conversation: six numbers, asked one at a time, never estimated or carried over from something you said three messages ago. Those six numbers produce five metrics, and the fifth field worth remembering is what none of them can hold: a dollar figure. revenue_ratio is a float measured against your own Week 1, so the log is safe to post publicly or pull up on a client call, not because you're careful, but because the schema has nowhere to put a real number even by accident.
| Lessons | What they actually established |
|---|---|
| 1 | Felt progress and measured progress are different instruments; a trial found them nearly 39 points apart |
| 2-4 | The real skill installs by cloning or copying one directory; five metrics compute off six honestly-logged numbers; revenue is stored only as a ratio, never a dollar |
| 5-6 | Four real weeks show automation outpacing revenue-per-hour and client capacity; a rough week can still measure well, and the number wins that disagreement |
| 7-8 | The log is plain JSONL by design, so it reads into whatever charting tool you already have; a bad entry gets hand-corrected, never silently re-run |
| 9 | The mechanism doesn't change after Week 4. What breaks a twelve-week run is a skipped week or a batch of weeks reconstructed from memory |
Lessons 5 through 9 ran that loop for real and showed what it looks like at scale. Four logged weeks showed automation climbing almost 4x while Revenue Efficiency Multiple and Client Capacity Score climbed more slowly, proof that a freed hour and a well-used hour are not the same claim. Lesson 6 logged a week that felt like nothing but firefighting and measured a 53.70% automation index and a 1.20x revenue multiple anyway, and the rule that lesson left you with was to trust the number by default on exactly the weeks feeling and measurement disagree. Lesson 8 logged a real typo, a revenue ratio carried over from the wrong week, and showed the honest fix: a plain hand-edit to the JSONL line, never a re-run, because the append-only log has no way to tell a correction from a cheat. Lesson 9 named the two failure modes waiting in weeks 5 through 12: skipping a quiet week, which breaks the consecutive-week count the graduation gate checks, and batch-logging several weeks from memory, which quietly reintroduces the estimation problem Lesson 3 already solved once.
Module 3 carries that data to the finish: a graduation gate built on consecutive logged weeks and the recurring-revenue percentage moving toward the 50% target Lesson 4 named, and twelve weeks of transformation-log.jsonl read back as a record of what actually happened, not a marketing claim about it.
Monday morning, in three moves
git clone https://github.com/profrodai/transformation-tracker-course.gitOr copy just .claude/skills/transformation-tracker/ into a project's own .claude/skills/ folder. Either path ends with Claude Code reading SKILL.md automatically. This is Lesson 2, and it takes minutes, not a sprint.
Total hours, automated hours, active clients, a revenue ratio of 1.0 (Week 1 always compares to itself), your recurring-revenue percentage, and the two sentences on what got automated and what's still slow. A rough number logged today beats a precise one reconstructed three weeks from now. This is Lesson 3.
Not a hope to remember. A standing appointment, because Lesson 9 named the real failure mode: not forgetting how to run the script, but letting the ritual compete with everything else on a Friday afternoon by week nine and lose.
What actually compounds
A Week 1 logged today, even an unflattering one, is a fixed point every later week gets measured against. A Week 1 deferred until conditions feel better is not a safer version of the same plan. It's a week with nothing to compare against, still waiting to happen, and Lesson 1's whole argument was that waiting for the week to "feel right" is the exact impulse this course was built to replace with a number.
Don't wait for a slow week to make the numbers look better, and don't wait for a busy week to prove the pace is real. Log the week actually in front of you. Week 1 isn't graded. It's the thing every other week gets measured against.
Checking the misconception one more time
The whole course, in two sentences
A felt sense of progress and a measured one are not the same claim, and only one of them holds still long enough to trust. Fix Week 1, log five numbers against it every week for twelve weeks, and the number that comes out the other end is the one thing in this whole program you didn't have to take on faith.
That's all twelve lessons. Revisit any of them, or open Claude Code and log your own real Week 1 right now.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
