The Folly of Tokenmaxxing Or Reinventing the Wheel

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.

Por qué importa

Los proyectos rara vez fracasan el día que se declaran fracasados. Fracasan meses antes, en una reunión donde alguien vio venir el problema y calculó que no le convenía decirlo. Todo lo demás —el cronograma que se corre, el presupuesto que se estira— es la consecuencia visible de ese silencio.

Mi filtro es la calidad del reporte de estado. Si todos los proyectos están en verde, el sistema de información no sirve: en cualquier portafolio real hay iniciativas en problemas, y una organización sana las muestra a tiempo en vez de descubrirlas en el comité de cierre.

Lo que suele salir mal

Donde suele romperse es en el traspaso a operación. El proyecto se declara terminado cuando se entrega, no cuando el área que lo recibe puede sostenerlo. Tres meses después el equipo se disolvió, nadie documentó nada y la operación convive con algo que no entiende y no puede modificar.

Qué mirar

• Si el reporte de estado muestra proyectos en rojo: un portafolio todo en verde es un portafolio sin información.
• Qué riesgos están identificados, quién es dueño de cada uno y cuándo se revisaron por última vez.
• El tamaño de la primera entrega útil: mientras más lejos esté, más se parece a una apuesta.

Cómo leo esta entrada

Yo lo usaría para revisar cómo se estima en la organización. Si las estimaciones históricas se pasaron sistemáticamente por la mitad y nadie ajustó el método, no hay proyecto que salga bien: se está planificando con un metro que mide corto y culpando al equipo por no llegar.

La noticia original está publicada en otro idioma; acá se cita el extracto tal como lo entrega el medio y el comentario se escribe en español.