When the Number Disagrees With the Week

Four real weeks logged in Lesson 5 all told a story that lined up with how the work felt: automation climbed, hours came back, and the operator behind that log would have described the month as going well even without a single number to check. That agreement is not guaranteed. This lesson is about the week it breaks, because that week is coming, and it is exactly the week you will be tempted to skip logging or round the numbers in whatever direction matches your mood.

The trial again, because it is the same failure twice

Lesson 1 opened with a randomized controlled trial run by METR: experienced developers used AI tools on real issues from their own codebases, took 19% longer to finish, and afterward believed the tools had made them about 20% faster. Felt experience and measured outcome pointed in opposite directions, by close to forty points, in people who knew their own work well enough to judge it.

That gap is not a quirk of software developers or of one study. It is what happens whenever a felt sense of "this is going well" substitutes for a number that was actually computed. A twelve-week transformation program hands you the same trap every week, just quieter: no clock running, no clear task boundary, only a memory of how the week went compared to a fuzzier memory of the week before.

A week built to make the point, not a real student's week

Here is a hypothetical Week 7, continuing the same fictional run Lesson 5 logged through Week 4. It is not a real operator's data. This program does not fabricate student outcomes, so every number here is labeled as constructed, chosen specifically to make the numbers and the felt experience disagree, and then run through the same formulas from Lesson 4 so the arithmetic is real even though the story around it is not.

In the operator's own words: a client sent an angry email over a missed detail in a deliverable, two calls ran long and unproductive, and by Friday the whole stretch felt like nothing but putting out fires. Ask this operator how it went and "rough" is the honest answer.

Here is what actually got logged, still measured against the same fixed Week 1 baseline from Lesson 3: 55 total hours, 8 automated, 3 clients, revenue ratio 1.0.

python3 .claude/skills/transformation-tracker/scripts/log_week.py \
  --week 7 --total-hours 54 --automated-hours 29 --active-clients 4 \
  --revenue-ratio 1.18 --recurring-pct 24.0 \
  --automated-this-week "Client status updates, invoice follow-up" \
  --bottleneck "Handling the escalation ate two days"

Run the same formulas Lesson 4 named, by hand, against those six inputs and Week 1's fixed baseline:

Printed the way the script would actually print it:

Three of five numbers show real, measurable progress against the fixed Week 1 baseline. One (Time Liberation Score) is barely positive. None of them show the week the operator would describe from memory, which was a week of firefighting and one very unhappy client.

Why the number wins the disagreement

Nothing about the escalation was imaginary. The complaint happened, the two lost days happened, and pretending otherwise would be its own kind of dishonesty. What memory cannot do is hold still against a fixed comparison point: an impression only has last week's impression to measure against, and that one was itself judged against the impression before it. Lesson 1 named this directly. The reference drifts along with the person forming it, and a drifting reference cannot tell you anything reliable.

The log does not have that problem, because it is not asking "was this seven-day stretch pleasant." It is asking "how far from Week 1, and in which direction," against a baseline fixed in Lesson 3 and untouched since. An angry client changes how Friday feels. It does not retroactively change how many hours got automated or what came in per hour billed, and arithmetic has no opinion about the phone call, which is exactly why it holds up on the stretch a person's judgment does not.

The mirror image: a great week that measures worse

The same disagreement runs the other direction too, worth naming even without a second full worked example. A big new client signs, the mood in the room lifts, everyone calls it the best stretch in a month, while the log shows total hours crept up and automated hours slid backward, because a manual process quietly returned under deadline pressure. Same mechanism. Only the direction of the mismatch flips. Elation is not evidence of progress any more than dread is evidence against it; the log is the only one of the two readings computed against a fixed point instead of against a mood.

The honest caveat: the number can be wrong too

None of this claims the log is infallible. A mis-typed hour, a revenue ratio entered as a dollar figure by mistake, an entry filled in from memory ten days late: any of those puts a wrong figure into a file that then gets treated as ground truth for every later comparison. Lesson 8 covers that failure mode directly, including what it looks like to catch and correct a bad entry without quietly rewriting history to make a trend look better than it was.

The claim here is narrower than "the log is always right." It is that logging beats guessing by default, because the arithmetic runs the same way every time, against a fixed point, through a script that refuses to estimate or carry a figure over from a prior entry. An impression has none of those properties. It rounds toward whatever mood the stretch left behind, and Lesson 1's trial already priced what that rounding costs: a 39-point gap, in the flattering direction, from people whose job depended on judging their own output accurately.