All posts

· 3 min read · ai, decision-support, leadership

From data to decisions

After a talk on machine learning from data to decisions: why a recommendation is only useful with its reasoning beside it, and how leaders actually act on briefs.

Last week I gave a talk titled "Machine learning, from data to decisions." The title is the whole argument. Most organizations are drowning in data and starving for decisions, and the gap between the two is not a bigger model. It is a brief a leader can act on.

What a decision actually needs

Picture the person who has to decide. A division head with fifteen minutes between meetings, three dashboards open, and a report from last month that nobody trusts. They do not need more charts. They need four things:

  1. What is happening, in one sentence, with the number that matters.
  2. Why the system thinks so, in plain language, with the signals it used.
  3. What it recommends, as a specific action with an owner.
  4. What would change its mind, so they know when to revisit.

A recommendation without the second item is an order from a machine. Leaders do not take orders from machines, and they should not. A recommendation with its reasoning beside it is a colleague's memo. That, they can act on, argue with, or overrule with a reason.

Early warning beats late analysis

The most valuable output of a decision-support system is not the quarterly analysis. It is the signal that arrives two weeks before the problem, when a small action still fixes it. That means the system has to watch continuously, compare against a baseline, and speak up only when the pattern is real.

The design question is not "can we detect it." It is "how do we present it so the person believes it early enough to act." The answer, again, is reasoning next to the alert, and a short history of how often that kind of alert turned out to be right.

Explainable by construction

There is a lot of talk about explainable AI as a technical property. In practice, explainability is a product decision made at the start. If the system stores the signals it used, the rule or model that fired, and the confidence it assigned, then explaining is a matter of showing. If it does not store them, no amount of later work will make it trustworthy.

This is the pattern behind the Qompass decision-support work: a unified view of internal and external information, early-warning analysis, and recommendations that carry their reasoning with them into executive and departmental dashboards. The technical components matter. The reason leaders use it is that every suggestion can be interrogated.

A test you can run tomorrow

Take the last automated recommendation your organization received. Ask whoever received it three questions: did you act on it, why or why not, and could you tell where it came from. If the answer to the third question is no, the first two do not matter. Fix the third.

For founders building in this space

Do not sell prediction. Sell the brief. Show the decision-maker a screen with the situation, the reasoning, the action, and the owner, and let them tell you what is missing. What is missing is your roadmap, and it will not be a better model.

Where the baseline comes from

None of this works without a baseline, and most organizations do not have one. The first job of a decision-support system is often not to recommend anything. It is to watch quietly for a few weeks, establish what normal looks like for each signal, and show that history to the people who will later receive alerts. When the first early warning arrives, they can see it against the pattern. An alert without a visible baseline is just a red badge, and people learn to ignore red badges within a month.

Data becomes a decision when the reasoning travels with the recommendation and reaches the person who can act.

Bring me the problem. I’ll bring the plan.

Thirty minutes. Bring the last time it went wrong. You leave with a straight answer.

Tell me the problemMore posts

Taking new projects · Remote · US-hours overlap