The Seventh Dashboard
A VP of Infrastructure I spoke with recently has seven dashboards open on a second monitor most Mondays. Cloud spend by service. Cloud spend by team. Reserved-instance utilization. GPU hours by experiment. Egress by region. P10/P50/P90 forecast variance. A FinOps "anomaly" view that flags any line item more than two standard deviations off its trailing four-week mean.
The data is, by any reasonable measure, excellent. The instrumentation is real. The numbers reconcile to the AWS bill. He can answer almost any question a CFO asks within the meeting it is asked in.
He still cannot get his platform team to act differently from one quarter to the next.
The decision he actually has to make every cycle is narrow: which workloads should we move, which should we leave, which should we kill, which should we re-platform onto reserved capacity. He has the data. The team has the data. They still spend two weeks each quarter "aligning on the analysis" before anyone touches a Terraform file. By the time they decide, the GPU spot market has moved enough that half the analysis is stale.
In my experience this is not a tooling problem. It is the most common stall pattern I see in organizations that consider themselves "data-driven." They have crossed the threshold where the marginal dashboard does not change behavior, and they keep building dashboards anyway, because that is what their reflex tells them to do when a decision is hard. The reflex is rational at small scale: the first dashboard in an organization usually does change behavior, sometimes dramatically. So does the second, and the third. The trouble is that the reflex is calibrated to that early-stage payoff, and nothing in the analytics function's incentive structure tells it to stop.
The cognitive job has shifted under them. They are still being given information. What the leader needs is a recommendation.
This sounds like a small distinction. It is not. It is a change in the contract between the analytics function and the decision-maker, and most organizations have not noticed they are still operating under the old contract. They have a 2017 reporting culture trying to support a 2026 decision tempo, and the seam between those two things is where information-rich organizations stall.
The rest of this article is about that seam: why more information stops working, what "recommendation seeking" actually looks like in a real workflow, and three concrete things a leader can do next week without buying anything.
Why More Information Stops Working
The analytics industry has a four-rung ladder it has been climbing since roughly the early 2000s. Gartner's framing names the rungs descriptive, diagnostic, predictive, and prescriptive analytics, each answering a progressively harder question. Descriptive asks "what happened?" Diagnostic asks "why did it happen?" Predictive asks "what will happen?" Prescriptive asks "what should we do?" Decision Intelligence sits above prescriptive and asks "how do we automate the decision and feed the outcome back in?" (Teradata's framing is a clean version of this; Quantexa and Gartner Peer Insights describe the same ladder with slightly different vocabulary.)
The problem is that the technology investment in most organizations is concentrated on the bottom two rungs. Dashboards are a descriptive tool. Drill-downs and root-cause analysis are diagnostic. Both produce information. Neither produces a recommended action. The forecast view is technically predictive, but in practice it is consumed as another descriptive surface ("here is the P50 line") rather than as input to a decision.
What the BI literature does not always foreground is that each rung of the ladder asks a fundamentally different cognitive job of the human consuming it. Descriptive asks the human to interpret. Diagnostic asks the human to attribute. Predictive asks the human to weigh. Prescriptive asks the human to choose between options that have already been ranked. The first three rungs offload nothing: they hand the leader more raw material and more confidence that the raw material is correct, and they assume the leader has the time, expertise, and unbiased judgment to do the rest.
That assumption was reasonable when a typical executive faced a handful of recurring decisions per quarter and had a small enough information surface to hold the whole picture in working memory. It is not reasonable now. The cloud cost example above is a useful illustration: a single workload-placement decision in 2026 has to weigh GPU spot volatility, reserved-instance coverage, egress fees, region-level availability, model-quality tradeoffs in inference routing, and contractual minimums with at least three providers. The CloudZero 2026 GPU pricing comparison puts on-demand H100 capacity between roughly $12 and $22 per hour depending on provider and instance, with spot discounts up to 90%, meaning the same workload can swing 10x in unit cost based on placement decisions a human is supposed to make weekly. There is no version of "show me a better dashboard" that solves this. The state space is too big.
This is where information density flips from helpful to harmful. Past a threshold, every additional dashboard raises the cost of interpretation faster than it lowers the cost of bad decisions. You see this in operations literature as alert fatigue: the well-documented finding that as the number of alerts in a clinical or operational system grows, response rates degrade. The same pattern shows up in security operations centers, in trading desks, and in any environment where humans are asked to triage a high-volume signal stream. The ninth dashboard is not additive to the first eight. It is substitutive; it competes with them for attention, and the brain handles competition for attention by ignoring something.
The Bayesian framing is also useful. A leader looking at a new dashboard is, in principle, supposed to update their belief about the world based on the new evidence. In practice, a leader who already has six dashboards and a confident prior simply does not have the cognitive budget to do a clean update on the seventh. The new evidence either gets folded into the existing prior with very low weight (in which case the dashboard did nothing) or it triggers another two-week "alignment" cycle where the team relitigates which numbers to trust. Either way, the marginal dashboard fails to change behavior.
The Decisioning Platform research I have been working through frames this directly: traditional BI sits in the descriptive and diagnostic rungs and produces what the field is now calling the last-mile problem: "the pervasive operational gap between an insightful report and the concrete, timely action required by that insight." That gap is real and it is not closed by adding more reports. It is closed, if at all, by changing what the system gives the human. Not more interpretive raw material. A ranked recommendation, with the reasoning surfaced and the option to override.
I want to make one nuance explicit, because I have watched it bite teams. The argument here is not that dashboards are bad. They are excellent for monitoring, for postmortems, and for the diagnostic work an analyst does before synthesizing a recommendation. The argument is narrower: dashboards are the wrong delivery surface for a recurring decision a leader has to make under time pressure. The descriptive rung still exists. It is just no longer the rung the leader should be standing on when the decision is due.
The seam between information and recommendation is, in my experience, the single most common place where data-rich organizations stall. They have invested heavily in the lower rungs. The marginal return on that investment has gone to zero or negative. And the next investment, the one that would actually change behavior, looks unfamiliar, because it is not another dashboard.
What Recommendation Seeking Actually Looks Like
I want to be precise about what I mean by "recommendation," because the word is overloaded. I do not mean a generic AI assistant that summarizes a dashboard. I do not mean a chatbot wired to a data warehouse. I mean a specific cognitive contract: the system presents the leader with a small set of ranked options, each with a stated rationale, a confidence level, and a default. The leader's job is to confirm, override, or escalate, not to interpret raw data and synthesize an option set from scratch.
The Decisioning Platform literature describes this as a layered architecture sitting between the System of Record (where data is captured) and the System of Engagement (where users interact). The intermediate layer (the System of Intelligence) is where decision logic lives, and its output is not a chart. Its output is an action proposal with four components: data inputs, decision logic, a triggered action, and a feedback loop that measures the outcome and refines the logic over time. That is the architectural shape of a recommendation surface.
In the cloud cost example, the descriptive surface is "here are seven dashboards showing your spend." The recommendation surface is something like:
We recommend migrating workloads X, Y, Z to spot capacity in us-east-2 this week. Estimated savings: $48K/month. Confidence: 0.82. Risk: workload Y has a SLO that may be violated under spot preemption (see attached preemption-rate analysis). Default action: queue migration for Friday window. Override or escalate.
That is a different artifact than a dashboard. It is also a different contract. The team that produced it has done the synthesis, weighed the tradeoffs, and put a stake in the ground. The leader's role has shifted from analyst to reviewer. The decision can be made in five minutes instead of two weeks, because the option set is small and the reasoning is auditable.
Two things about that example are worth pulling out, because they generalize.
First, the recommendation has a default. Behavioral economics work on choice architecture (most accessibly summarized in Thaler and Sunstein's Nudge) has shown repeatedly that default options dominate outcomes in settings where decision-makers face cognitive load. A recommendation without a default is just a multiple-choice question, and a multiple-choice question still requires the leader to spend cognition deciding which option to pick. The default is not a usurpation of the leader's authority. It is a reduction in the cost of doing nothing, which is the relevant baseline against which any active decision is being made.
Second, the recommendation has confidence and reasoning. This matters because of what the EU AI Act and similar regulations are starting to demand of high-stakes automated decision systems: auditable, transparent logic. The Decisioning Platform research I cited earlier calls this the "No Black Box" promise: every decision logged, audited, and explainable to the human user. From a trust perspective, a recommendation surface without reasoning is a liability. From an adoption perspective, it is a non-starter, because leaders will not act on a number they cannot defend in their own meeting.
The technical underpinnings of recommendation surfaces are getting genuinely better, fast. The Decisioning Platform research describes how AI Model Cascade routers can use Bayesian bandit algorithms (specifically Thompson Sampling) to route inference queries to the most cost-effective model that meets a quality threshold for a given task, with reported cost reductions over 40%. That is not a dashboard. That is a recommendation engine making routing decisions in real time, with measurable outcomes feeding back into the logic. The same architectural shape applies in churn-risk workflows (rank the at-risk accounts and propose retention actions), in supply-chain re-routing (rank the at-risk lanes and propose alternates), and in hiring-funnel triage (rank the candidates and propose next-step interview slots).
What is not getting better automatically is the organizational contract that consumes these surfaces. I have watched well-designed recommendation systems get built and then degraded by leaders who insist on "seeing the underlying data" before every action, effectively converting the recommendation surface back into a dashboard and reintroducing the two-week analysis cycle. The technology shift is necessary but not sufficient. The harder shift is in how the leader uses their own time. A leader who has internalized the recommendation contract spends their cognition on the override decisions (the 5-15% of cases where the default is wrong) and lets the defaults run on the rest. A leader still operating under the dashboard contract spends their cognition on every decision, and the throughput of the team is gated by the leader's calendar.
The seam is, in this sense, less about software and more about what the leader is willing to delegate. The software is just what makes the delegation legible and reversible.
What I do not yet know
The argument above presumes that once the recommendation contract is in place, leaders will use it. In practice I have watched well-designed recommendation surfaces get reverted into dashboard-style consumption within a quarter or two. The leader insists on "seeing the underlying data" before every action, the team starts producing memos again to satisfy that ask, and the cycle time creeps back to where it was before.
What I do not have a good model of yet is which leaders stick with the recommendation contract and which ones revert. The pattern is not what I would have guessed. It is not strictly correlated with seniority, technical background, or how data-driven the leader claims to be. The strongest signal I have noticed is whether the leader is comfortable being wrong on a decision in a way that is auditable. Recommendations make wrongness visible, because the option you picked is logged with a stated rationale. Dashboards make wrongness diffuse, because there is no single moment of choice to point back at. Some leaders find auditability of their own decisions energizing. Others find it threatening. The reversion seems to be coming from the second group.
If you have run this experiment in your own organization and noticed a different pattern, I would genuinely like to compare notes. The mechanism behind why one leader internalizes the recommendation contract and another rebuilds the dashboard around it is the kind of thing where a half-dozen real examples will sharpen the picture faster than another framework will.
What's next in the series
→ Part 2: The Trust Gap. Why recommendations don't always become decisions.
→ See the full framework: The Decision Effectiveness Framework.