Your Sprint Report Tells the Truth but Hides Everything That Matters

From Status to State

The CTO walks into the Monday executive meeting with a slide deck. The first slide shows the sprint is green. The CEO nods. The report tells the truth but hides everything that matters. A status report answers only one question: is the feature done, is the sprint on track, is today’s task finished. That is a transient signal. A state report answers a more consequential one: is the technical asset getting healthier or sicker over time, is our capacity to change increasing or decreasing. That signal is structural.

The VP of Engineering presents thirteen bullet points on what the team shipped. The CEO checks a box and moves on. The structural health of the codebase never comes up, because nobody asked for it. That gap is where companies lose control of their technical assets without ever noticing, because the report that would have shown the problem is the one that never gets requested.

The rest of this article covers what the CTO and the CEO have to do to close that gap. They must report state instead of just status, negotiate trade-offs on visible data, measure the structural metrics automatically so the data is honest, and prove the savings are real with an independent module example.

1. Status vs. State

• Status (Transient): Progress on specific tasks, such as “is the feature done.” It’s a surface-level metric that hides structural decay.
• State (Structural): The internal health and evolution of the technical asset, a trend, such as “is our capacity to change increasing or decreasing.”

Monitoring and reporting the State is the CTO’s job. Valuing the State over temporary Status is the CEO’s job.

A mirror just reflects what is in front of it, and an informant feeds scraps of truth to whoever happens to be asking. The CTO has to be neither of those. The CTO has to be transparent, which means having the courage to say when things are not OK, and pushing back before bad decisions get made. If the CTO does not have the courage to escalate a warning, the company is operating on bad information, and the CEO will not know until something breaks publicly.

The pattern is real. In one of my past jobs, the company hired and let go three CTOs in four years. None of them pushed back hard enough when the CEO kept pushing top-down priorities. The CEO was bragging that he could keep raising money to extend the runway, and he did. But every fundraising round extended an unprofitable run that had a fat monolith nobody dared to plan to kill. The top-down priorities were always in the way. The CTOs never said the obvious thing out loud, which was that the spend was not justified by the demand. The lesson is not that those CTOs were bad people. The lesson is that a CTO who cannot say “no” to a CEO is a tax on the company’s future, paid in silent waste.

2. Negotiating Trade-Offs

A healthy company runs on a value-driven partnership, not a hierarchy of imposition. Two ideas anchor this, and they come from outside software on purpose.

The first is the principle President Milei has used to describe his own governing philosophy: we will do anything to improve people’s lives, as long as those decisions are moral. So, not at any cost. The second is Mises’s insight that human action is always about what a person values most at a given moment. It always comes down to what I value more: X, or my money. Y, or Z. Both of these point to the same operating rule: every decision is a trade, and the trade has to be visible, which maps cleanly onto a CTO/CEO negotiation.

• Expert Ownership: The CEO hired experts to tell him what to do, not for him to tell them what to do. The CEO’s job is to listen to the technical boundaries the CTO raises and decide whether the trade is worth it. The CEO has to be a negotiator, not an overrider.
• Subjective Value: Decisions have to be made on what is valued most at the moment. If a feature costs $10,000 in direct work but$40,000 in Sync Tax, the CEO has to decide if that specific feature is worth the total price, not just the sticker.
• The Shared Language: Negotiating through the Sync Tax multiplier (the ratio of coordination cost to direct work) removes the “us versus them” toxicity. It replaces personal friction with objective data.

The failure mode goes both ways. The CEO who demands features at any cost creates a tech department that goes toxic, full of quiet resentment, and the work quality drops. The CTO who treats the rest of the company as the enemy, treating engineers as needing protection from “the business,” creates the same outcome from the other side: distrust, micromanagement, and silent sabotage on both ends, and both postures backfire.

When the Sync Tax rises, it is a shared failure to negotiate. The CTO failed to make the State visible. The CEO failed to value the future over the immediate Status. Neither side gets to blame the other; they both let the negotiation rot.

3. Automated Transparency

For the State to be trustworthy, it has to be measured automatically. Anything manual is gameable, and engineers will game it because incentives reward looking good, not being honest.

• Zero-Manual Reporting: All the underlying data has to flow from the code and the deployment pipeline itself, with no human in the loop filling in spreadsheets. The metrics include how tangled different parts of the code are, a measure called Connascence Degree. This is where the real financial cost and risk hides, because a high degree means any change in one place is likely to break several others. We also look at how many other parts of the system get touched when you change one part (Fan-Out), and how often a change breaks something that was working before (Regression Rate). These are the structural indicators. Manual reporting of them is theater.
• One-Off Tooling: Setting up this infrastructure is a one-time technical investment. Once the data pipeline is wired into the system, it stays. It becomes a permanent part of the technical asset’s monitoring. There is no per-quarter rebuild.
• Supply and Demand of Truth: The CTO owns the supply of the data. The CEO owns the demand. If the CEO stops demanding the truth because he wants to “accelerate” at any cost, he is choosing to operate without information. The cost of that choice shows up later, and it is always larger than the cost of knowing now. The demand has to exist or the supply atrophies.

The tooling itself has to be transparent about what it measures and how, so engineers can trust it. Engineers will reject any system that feels like surveillance. A system that just measures the code automatically, with no manual reports and no subjective judgement, is hard to argue with, because the data is the data.

4. Independent Modules in Practice

The savings show up the moment a piece of the product is built as an independent module with a clean interface, meaning no dependencies on the rest of the system. Take a Payment module.

• Interchangeability: The Payment module can be rewritten in a faster language (for example, moving from TypeScript to Rust) without touching the rest of the product. Zero coupling means the rewrite is contained. It could even be outsourced, as long as the interface remains untouched, the rest of the system shouldn’t even notice the difference.
• Zero Structural Coupling: New integrations (regional payment methods like Blik in Poland) or changes elsewhere in the product have a guaranteed zero impact on the Payment module. None of those changes affect it.
• Resource Reallocation: The hours saved by removing structural friction are immediately available for work that addresses actual customer demand. That time is returned back to the company’s pocket and now can be invested in something with actual demand.

The savings compound. Every future change to that module, every new payment provider, every currency switch, every regional expansion, costs near zero hours of coordination. The module is independent and the rest of the system does not depend on its internal details. That is the State of a healthy technical asset: change gets cheaper over time instead of climbing.

References

1. Milei, J. (2026). Special Address at the World Economic Forum Annual Meeting 2026. Davos. Retrieved from weforum.org
2. Mises, L. von. (1949). Human Action: A Treatise on Economics. Chapter I, Section 2: “The Prerequisites of Human Action”. Retrieved from mises.org
3. Page-Jones, M. (1992). “Comparing Techniques by Means of Encapsulation and Connascence”. Communications of the ACM, 35(9). See also: Connascence on Wikipedia.
4. Henry, S. & Kafura, D. (1981). “Software Structure Metrics Based on Information Flow”. IEEE Transactions on Software Engineering. See also: Fan-out (software) on Wikipedia.
5. DORA (DevOps Research and Assessment). DORA Metrics: Change Failure Rate. Retrieved from dora.dev