TL; DR: Tokenmaxxing Or Reinventing the WheelYour organization counts AI tokens, seats, and pilots, but can anyone name a single decision those numbers actually changed? Tokenmaxxing is only the symptom; five old Agile Laws explain the cause, and each one comes with a test you can run this week.
TL; DR: Tokenmaxxing Or Reinventing the WheelYour organization counts AI tokens, seats, and pilots, but can anyone name a single decision those numbers actually changed? Tokenmaxxing is only the symptom; five old Agile Laws explain the cause, and each one comes with a test you can run this week.
Thesis: Tokenmaxxing is the vanity metric of pushing low-value work through an AI tool solely to inflate usage metrics. Tokenmaxxing emerged in 2026, when large technology companies began ranking employees by token consumption on internal leaderboards. The behavior is rational for the individual but useless for the organization because tokens measure input rather than outcomes. The five Agile Laws in this article explain why organizations keep making this mistake and what to measure instead.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.
The Folly of TokenmaxxingIn April 2026, Fortune reported, citing The Information, that an employee at Meta had built an internal leaderboard ranking colleagues by how many AI tokens they consumed, drawing on usage from more than 85,000 employees and displaying the top 250. What we now know as “Tokenmaxxing” was born. The highest-ranked user, in Fortune’s wording, “averaged 281 billion tokens” across the 30-day window. The leaderboard handed out titles: “Token Legend” and “Cache Wizard.” Neither Mark Zuckerberg nor CTO Andrew Bosworth made the top 250.
At Amazon, the same failure mode surfaced as employees reportedly pushing low-value work through the company’s agentic tool to inflate their usage. As one employee put it: “Some people are just using MeshClaw to maximise their token usage.”
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 17/08/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
Projects rarely fail on the day they are declared failed. They fail months earlier, in a meeting where somebody saw the problem coming and calculated it was not in their interest to say so. Everything else — the slipping schedule, the stretching budget — is the visible consequence of that silence.
My filter is the quality of the status report. If every project is green, the reporting system is not working: in any real portfolio some initiatives are in trouble, and a healthy organisation surfaces them in time rather than discovering them at the closure committee.
What usually goes wrong
Where it usually breaks is the handover to operations. The project is declared finished when it is delivered, not when the receiving area can sustain it. Three months later the team has dissolved, nobody documented anything, and operations lives with something it does not understand and cannot change.
What to watch
- Whether the status report shows any red projects: an all-green portfolio is a portfolio without information.
- Which risks are identified, who owns each one, and when they were last reviewed.
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
How I read this entry
I would use it to review how the organisation estimates. If historical estimates were systematically out by half and nobody adjusted the method, no project will land well: you are planning with a ruler that measures short and blaming the team for not reaching the mark.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
