TBM 437: Tokens, Hours, Points, and Other Curious Proxies

The Beautiful Mess

SubscribeSign in

TBM 437: Tokens, Hours, Points, and Other Curious Proxies

John Cutler<br>Aug 17, 2026

36

Share

Everyone is talking about “return on tokens.” Vendors love it (as long as the news is good). Companies that had long since given up on any sort of value architecture or on understanding the ROI of product work are suddenly chomping at the bit. Which makes sense: they haven’t been able to lay off enough people to cover their token budgets while still hitting their promises to the board.<br>It is hard to know what sits below the surface: a genuine effort to understand how AI might augment human capabilities, or some version of “how many people can we safely fire?” Or both?<br>It is as if the whole world suddenly shifted from a buffet model to buying each dumpling one at a time, and now everyone is freaking out about the ROI of each dumpling. But we’ve been here before. We’ve been here with hours. We’ve been here with capacity. And the problems have always been roughly the same:<br>Spending more time on the “I” side than the “R” side of ROI.

Myopically choosing shorter-term, easier-to-attribute use cases for the “R” side.

Gravitating toward whatever is easiest to measure. And tokens are very easy to measure.

This post takes a trip through hours and flow metrics, detours into an alternative way of thinking about ROI, and eventually gets to TOKENS—everyone’s favorite dumpling.<br>My goal is to show that the underlying measurement problems are remarkably universal. AI introduces some genuinely new twists, but in the end, it still hinges on a theory of value.<br>With these comparisons, ask yourself, “How might this relate to the current return on tokens question?”<br>Leave a Coffee Tip!<br>Hours

Hours, as commonly used to understand investment, represent a major construct validity problem. There’s nothing inherently wrong with measuring “time we spent on things” (hours) to understand better where effort is going, provided you make it clear that:<br>Time is not a fungible thing that can be infinitely allocated/re-allocated. This holds across skill sets, team context, and even across a “normal day”. For example, the “magic hour” of uninterrupted morning productivity can be vastly more productive than trying to wrap your head around something complex between 4 and 5 PM. The developer deep in the onboarding space, an expert in onboarding analytics and the user journey, working primarily with what customers see/interact with, can’t be immediately swapped into a deep, legacy backend refactoring effort.

Where you allocate time tells you nothing about the “quality”, efficiency, or efficacy of that expenditure of time. The highly skilled developer reactively called in to debug an area of the code they have no experience with will not have the same leverage as someone more junior, but more contextually situated. Ten people spending ten hours each is not equal to one person spending one hundred hours. Sometimes the entire system is constrained by a single specialist, a single decision, a single dependency, or a single review. Spending time elsewhere has negative leverage.

The context switching tax is real. Most efforts to understand the allocation of time, whether explicit or implicit, leave out large time investments. Imagine alternating between two tasks every ten minutes for a six-hour day. You’ll spend three hours (at least) on context switching and calibrating/orienting around the new task. Coordination is multiplicative, while time accounting is additive.

The relationship between time and outcomes is non-linear. 2x-ing where you spend time doesn’t 2x the outcomes. You might bang your head against a problem for eight hours and get nowhere, and the ninth hour “unlocks” all the value. The metric treats the input as continuous even though the production function contains thresholds and fixed setup costs.

Where we invest focus can have a long-term effect. Imagine spending 5% longer on every enhancement to pay off a bit of debt and “garden” the codebase. Three years later, a version of the team—some people have stayed, but some have left—is absolutely flying. Where do you “book” that time? And how do you connect that investment to the long-evolving, game-changing “return”? Some hours multiply future options. Some hours limit future options.

Time allocation schemes often force allocations into individual buckets, but there are typically causal relationships between those buckets. They aren’t mutually exclusive. One impacts the other.

Lean/Flow Metrics (and “story points”)

Helpful, when focused.<br>Lean/flow metrics include cycle time, lead time, practical WIP limits, and throughput (e.g., N stories per week). Most of these metrics have a storied history in manufacturing, which is both a positive—there’s actual math, theory, and practice behind them—and a negative when misapplied to software development.<br>Note the following:<br>In manufacturing, it...