The more data you provide to a board of directors, the less likely they are to understand what your company actually does. We have been conditioned to believe that transparency is a function of volume-that if we simply increase the frequency and granularity of our reporting, the truth will eventually emerge from the noise. It is a seductive lie. In reality, the most sophisticated dashboards in the corporate world function less like windows and more like heavy velvet curtains. They provide the illusion of visibility while ensuring that no one actually has to look at the mess behind the fabric.
I realized this most clearly while performing a minor surgical operation on my own hand . I had a splinter, a tiny, jagged shard of cedar from a fence post, lodged deep under the skin of my thumb. It was a binary problem. The splinter was either in, or it was out. There was no “throughput” metric for splinter removal. There was no “velocity” for the extraction. There was only the sharp, localized reality of the pain and the necessity of the result.
When I finally pulled it out, the relief was absolute. In business, however, we have developed a profound allergy to that kind of binary clarity. We prefer the dull ache of an unanswered question over the sharp discomfort of a definitive answer.
The Anatomy of a Defensive Measurement
Consider the quarterly review of a mid-sized software firm, into a private-equity cycle. The room smells of expensive coffee and the faint, ozone scent of high-end air purifiers. Ravi, the CTO, is at the head of the table. He is a capable man, a man who understands the architecture of a legacy codebase as well as he understands the architecture of a balance sheet. But he is currently under fire. , an operating partner asked a dangerous question: “What, exactly, are we getting for our eleven million dollars in annual engineering spend?”
It is the kind of question that should lead to a fundamental reckoning. It should lead to a discussion about technical debt, about the friction of a fifteen-year-old monolithic architecture, and about the actual market value of the features shipped in the . Instead, it led to a project. Ravi commissioned a dashboard.
Fig 1: A visualization of the “18% tile” that distracted the board from an $11 million capital inefficiency.
Six weeks later, the dashboard is ready. It has sixteen tiles. Four of them are glowing green. Two of them are refreshing live, their little line graphs jittering with the simulated heartbeat of a “data-driven” culture. When Ravi clicks to slide nine, an operating partner leans forward. He doesn’t ask about the eleven million dollars. He doesn’t ask about the ROI of the latest release. He points at a specific tile and asks, not unkindly, “What does the eighteen percent refer to?”
Ravi knows the answer. He knows that the eighteen percent represents “ticket completion against sprint commitment,” a metric that is almost entirely meaningless in the context of business value. He knows that if he explains what it actually is, the partner will ask why it isn’t twenty-five percent, which will lead to a conversation about story points, which will eventually reveal that the entire engineering department is spinning its wheels trying to keep a decaying database from collapsing under its own weight.
“That’s our delivery throughput. It’s a measure of our pipeline efficiency.”
– Ravi, CTO
The partner nods. He writes down “Delivery Throughput” in his notebook. He feels like he has performed his due diligence. He has asked a question, received a technical answer, and seen a number. The meeting moves on. Ravi has bought himself another quarter of survival, and he knows exactly what it cost him: the truth.
The Theater of Rigour
This is the defensive deployment of measurement. We assume that dashboards are built to reduce uncertainty, but in the high-stakes environment of executive leadership, they are often built to manufacture a very specific kind of certainty. They are designed to absorb questions rather than resolve them. When a number is questioned and the immediate response is to add three more numbers to the slide, you are no longer in a decision-making meeting. You are in a theater of rigour.
The tragedy of this theater is that it becomes addictive for everyone involved. The consultant is paid for the build, the executive is paid for the appearance of control, and the board gets something shiny to look at during a three-hour slide deck. By the third meeting, even the most skeptical board member will stop asking about the eleven million dollars. They will start asking why the “Velocity Index” has dipped by three percent. They have been successfully redirected from the forest to a very specific, irrelevant leaf.
In my years of looking at how organizations handle their capital, I’ve seen this pattern repeat across every industry, but it is most toxic in software engineering. Because code is invisible, and because the work of a developer is often indistinguishable from magic to the uninitiated, the dashboard becomes the only reality. But software isn’t just “magic”; it’s an asset that either produces a return or incurs a cost. When you have a brownfield codebase-one of those aging, revenue-generating systems that has been patched and propped up for a decade-the gap between what the dashboard says and what the code does can become an abyss.
Most engineering partners will tell you they can fix this by “scaling the team.” They want to sell you more hours, more bodies, and more tiles for your dashboard. They promise that if you just increase the headcount, the throughput will follow. But adding more people to a high-friction system is like trying to put out a fire with a leaf blower. You’re just moving the oxygen around.
Scaling vs. Efficiency
The Gift of Discomfort
True clarity requires a different approach. It requires someone to step into the daily stand-up, commit to the actual repository, and ship through the existing pipeline. It requires an evidence-based look at the friction. If you want to know what your eleven million dollars is buying, you don’t need sixteen tiles. You need to know if the team can ship a change faster than they could . You need to measure the lift against a baseline, not against a theoretical “sprint commitment.”
This is why the model used by
is so disruptive to the traditional reporting theater. By embedding a delivery pod directly into the client’s team, they aren’t just reporting on the weather; they’re helping to change the climate. They use DORA-style measurement to provide evidence of productivity gains-actual, verifiable lifts of fifteen percent or more-rather than just adding more noise to the QBR. It’s the difference between a doctor showing you a chart of your heart rate and a surgeon actually removing the blockage.
The discomfort of the “eleven million dollar question” is actually a gift. It is a signal that the organization still cares about the relationship between spend and value. When we smother that question with a dashboard, we are rejecting the gift. We are choosing the comfort of a green tile over the necessity of a hard decision.
I’ve made this mistake myself. Early in my career, I spent building an automated reporting suite for a client who was bleeding cash. I was so proud of the data integration, the real-time updates, and the elegant color palette. I presented it with the confidence of a man who had solved the problem. At the end of the presentation, the client looked at me and said, “This is beautiful, Max. But am I still losing money?”
The dashboard couldn’t tell him. Or rather, it was telling him in sixteen different ways, but it was doing so in a language designed to make the loss look like a “strategic pivot” or an “operational realignment.” I had built him a high-tech gauze for a wound that needed stitches.
We have to be willing to ask the “splinter” questions. We have to be willing to look at a dashboard and ask, “If this number goes to zero, does the company die? And if this number doubles, do we actually make more money?” If the answer to both is “I don’t know,” then the tile shouldn’t be on the screen. It is a distraction, a defensive wall built of pixels and hope.
Real transparency isn’t about seeing everything; it’s about seeing the one thing that matters.
In a legacy engineering environment, the one thing that matters is the ability to change the software without breaking the business. Everything else-the story points, the velocity charts, the “throughput” metrics-is just commentary. If your engineering spend is a black box, the solution isn’t to paint the box green. It’s to open the box, reach inside, and start pulling out the splinters.