A growing organisation rarely has a visibility problem. Sales, finance, operations and service all provide metrics, dashboards and status reports. Yet some executive meetings end with the same deferral: the figures need to be explained again, reconciled or broken down further. In the meantime, actions remain unresolved, risks have no visible owner and teams wait for direction.
The consequence is more than a slower meeting. When important decisions are made too late, waiting times lengthen, exceptions are improvised and the CEO becomes a substitute for missing decision rights. The answer is neither less data nor the next dashboard. It is a closed leadership loop: a signal must be linked to context, a clear threshold, a decision-maker, an action and feedback.
This article sets out how leadership teams can build that loop. It argues for less parallel searching and fewer disputes over interpretation and for more clearly defined decisions.
The Fassbender Signal to Decision Loop is a practical decision architecture that links a relevant signal to shared context, a threshold, clear accountability, a binding action and verifiable feedback. It is derived from evidence and consulting practice, not a scientifically validated universal standard.
A dashboard shows something, but it decides nothing
A dashboard can make a deviation visible. It does not automatically answer whether the situation is commercially relevant, which definition applies, whether the data are sufficiently current, who decides or what happens next. This is precisely where apparent ambiguity arises.
Research does not justify a simple claim such as: “More data make every leadership team slower.” A meta-analysis of 117 studies reports negative associations between information overload and performance and positive associations with information avoidance, stress, exhaustion and burnout. These are correlations in broadly defined samples, not measurements of real CEO teams and not a threshold for metrics or reports.1
Interruptions also require precise interpretation. In a controlled experiment, they impaired performance relative to a control group when they occurred during the evaluation and selection of complex options. This does not mean that every email or follow-up question is harmful. It is, however, a sound reason not to overload complex trade-offs with parallel status requests.2
A dashboard experiment links information format, timeliness and completeness indirectly to perceived decision quality. It tested neither the number of dashboards nor the speed of real corporate decisions.3 Visibility is necessary, but it is not sufficient for decision capability.
Five failure patterns that slow decisions
In my experience, the bottleneck is rarely a missing chart. More often, signals arrive in the leadership meeting without a clear purpose. The team then discusses data instead of making a decision.
| Failure pattern | What becomes visible in the meeting | Structural cause | Management response |
|---|---|---|---|
| Metric without a decision question | The team sees a deviation without knowing whether it needs to inform, decide or investigate. | Reporting and the decision agenda are not separated. | State the specific decision question for every prioritised signal. |
| Multiple truths | Sales, finance and operations explain the same metric differently. | The definition, reporting date, source or data ownership has not been clarified. | Approve a context card with the business definition, origin, owner and data-quality limit. |
| Thresholds only emerge in conflict | Every deviation is renegotiated; escalation depends on who speaks most loudly. | Tolerances, risk and the exception route were not determined in advance. | Align decision thresholds with the business model, risk, data latency and operating cycle. |
| Collective accountability | Many people are involved, but no one reaches a decision or starts delivery. | The decision-maker, recommendation owner and delivery owner are conflated. | Assign roles and the escalation route visibly for the specific decision. |
| Decision without feedback | Minutes record a decision, but its effect is never reviewed. | Action, measurement owner and the next review are not part of the decision. | Close every prioritised decision with a follow-up and an adjustment or stop criterion. |
For decision-critical metrics in particular, context is not merely a documentation requirement for specialists. For supervised institutions, the European Central Bank expects, among other things, central business definitions, metadata, clear data ownership and current data lineage. This finding comes from regulated risk and financial reporting; it is therefore not a prevalence statement about mid-sized businesses. As a design principle, it remains relevant: without traceable meaning and origin, a number remains open to challenge.5
The UK Government Data Quality Framework expresses the same idea more generally. Timeliness is not the same as real time. It must accurately represent the period in question and provide an appropriate delay between collection and availability for the intended use; shared definitions and metadata should reduce ambiguity.6 A daily figure may be necessary to manage a short-term capacity situation, yet for a strategic portfolio decision it can create more false precision than value.
The Fassbender Signal to Decision Loop
The loop translates these requirements into a lean leadership routine. It does not replace organisation-specific analysis or the judgement of a leadership team. Its purpose is narrower: to close the gap between a visible deviation and accountable action.
| Component | Leadership question | Minimum content | What happens without it |
|---|---|---|---|
| 1. Signal | What has changed relative to the target, plan or expected development? | Metric or event, direction, magnitude and reference period. | The team sees activity, but no prioritised deviation. |
| 2. Context | What does the signal mean commercially and how reliable is it? | Definition, calculation logic, source, owner, reporting date, known quality limit and affected assumptions. | The meeting disputes the figures rather than the decision. |
| 3. Threshold | Which condition triggers which type of decision? | Decision question, trigger or tolerance, risk and time horizon, evidence required and exception route. | Every deviation is escalated politically or ad hoc. |
| 4. Owner | Who decides, who recommends, who provides input and who delivers? | Decision-maker, recommendation owner, input providers, delivery owner, forum and escalation route. | Responsibility is spread around without anyone being accountable. |
| 5. Action | What will be changed, stopped, approved or examined further and by when? | Decision, action package, deadline, resource or risk decision and Decision Log. | Discussion is mistaken for progress. |
| 6. Feedback | How will the team recognise impact or flawed assumptions and when will it adjust? | Verifiable hypothesis or target value, measurement owner, review date and adjust/stop criterion. | Decisions create no institutional learning loop. |
The evidence supports individual components, not the superiority of a finished overall model. A study of 135 Norwegian public-sector organisations found positive associations between strategic planning, the design of performance-measurement systems and the purposeful use of performance information. Transferability to private companies is limited; the study itself identifies underuse, overuse and information overload as risks.7 Taken together with the framework of Kaplan and Norton, this supports a consulting inference: information becomes relevant to management only when it is tied to expected outcomes, review routines, follow-on actions, accountability and subsequent adjustment.8
A clear roles matrix alone is not enough. In an unweighted, self-reported McKinsey survey of 1,259 participants, respondents were 6.8 times more likely to be in an organisation defined as a “decision-making winner” when decisions were made at the right level. For cross-functional decisions, effective stakeholder coordination and a focus of decision forums on critical decisions were associated with a 4.5 times greater likelihood.4 These relationships are neither causal evidence nor a forecast of the effect of a governance initiative. They do, however, reinforce an important judgement: cross-functional decisions require more than formal responsibilities, they require focused coordination and a place where decisions are actually made.
Three review formats, three different jobs
Not every number belongs in the same meeting. Teams that mix operational exceptions, delivery progress and strategic assumptions create long sessions with little clarity. I recommend separating the three formats visibly.
| Format | Core question | Typical inputs | Expected output |
|---|---|---|---|
| Operational review | Where is a current deviation preventing execution and what immediate action is required? | Capacity, quality, deadlines, escalations and acute risks. | A specific resolution, a delivery owner and a short-term control point. |
| Strategy review | Is execution of the chosen strategy on track; where and why are problems occurring; what corrective action is required and who owns it? | Prioritised outcomes, strategic initiatives, deviations and causes. | A corrective decision with an owner, resource or risk implications and a review date. |
| Strategy test | Which uncertain assumption about the market, offering, customer or business model must be tested before it becomes fixed management logic? | Hypothesis, counter-hypothesis, evidence to be tested and decision date. | Confirmation, adjustment or rejection of an assumption, not an operational status report. |
Kaplan and Norton explicitly distinguish operational reviews, strategy reviews and strategy tests by their purpose. The strategy review in particular asks about progress, causes of problems, corrective action and accountability; the framework does not prescribe a blanket review frequency. It should fit the pace of new data and the operating cycle.8 This protects the leadership team from two errors: deriving strategy from a daily figure and leaving acute operational blockers unresolved until the next quarterly meeting.
Measurement discipline: measure the process, not an invented success story
In the first 90 days, the team should initially observe the completeness of the decision loop. These measures are not universal performance targets and do not replace an economic baseline. They make visible where leadership itself is creating friction.
| Measure | Practical definition | What it makes visible | Important limit |
|---|---|---|---|
| Decision Latency | Time from meeting a relevant signal condition to a documented decision or a reasoned decision not to act. | Waiting points, unnecessary forums and unresolved escalations. | Review separately by decision type; a strategic decision must not be assessed as if it were an operational exception. |
| Decision-to-Action Time | Time from a documented decision to the start of the agreed action. | Whether decisions actually turn into work. | “Start” and the action must be defined unambiguously for the respective loop. |
| Proportion with a clear Owner and follow-up | Share of prioritised submissions with a decision-maker, delivery owner and scheduled impact review. | Gaps between decision, accountability and learning. | Measures process completeness, not business success. |
| Definition conflicts | Recorded cases in which a metric’s definition, source, reporting date or calculation logic is disputed during the decision process. | Data and trust gaps that block decisions. | Document conflicts rather than prematurely labelling them as data errors. |
| Rework | Repetition of analysis, submission, approval or action because context, the decision or requirements were unclear. | Avoidable coordination work. | Examine the cause; repetition can be right when it reflects deliberate learning. |
There is no credible external baseline or target figure here for any of these measures. Comparison starts with the organisation’s own starting point. The goal is not to simulate a “fast” organisation, but to manage material decisions in a traceable way.
AI is an amplifier, not the decision-maker
AI becomes productive only once the loop is in place. It can condense signals, detect anomalies, structure scenarios and prepare decision papers. It cannot, however, replace accountability, thresholds, commercial context, monitoring or an effective override.
AI-supported signals therefore require an extended context card in the leadership routine: system or model version, use boundary, testing basis, known failure modes, subject-matter reviewer, override and incident contact. The NIST AI Risk Management Framework calls for documented roles, responsibilities and communication pathways for AI risks; it locates risk decisions in development and deployment with executive leadership. The framework also calls for documented tests under deployment-like conditions and monitoring in operation.9
For high-risk AI within the relevant scope of the EU AI Act, natural persons must be able to oversee and interpret outputs effectively and, where necessary, disregard, override, reverse them or safely interrupt operation. Providers must establish documented post-market monitoring.10 These requirements do not apply indiscriminately to every internal tool. They nevertheless make one point clear: a good AI decision paper does not anonymise accountability.
A robust AI Operating System brings these levels together: Strategy & Value, Processes & Decisions, Data & Knowledge, Technology & Integration, Governance & Evaluation and People & Operating Model. It is not additional software layered on top of the dashboard, but the operating logic through which decisions, data and technology work together.