
Guides
Part of 8 things about business intelligence worth your time
Business intelligence mistakes: most happen around the team, not in it
Business intelligence mistakes made around a data team rather than by it: truth programs, metrics tied to pay, and re-platforming instead of deciding.
The mistakes below are not made by data teams. They are made around them, by the executives who fund the work, the managers who consume it, and the committees that decide what counts as official. A capable team can be rendered useless by every one of them.
Each entry describes a move that is reasonable on its face, what it actually costs, and the smaller thing to do instead.
What to take away
- Most damage to an intelligence function is done by its sponsors, not its staff.
- Almost every one of these is a large project standing in for a small decision nobody wants to make.
- The cheap fix is nearly always to settle one contested number rather than to reorganize, re-platform, or re-scope.
1. Commissioning a single source of truth
It sounds like the right ambition and it funds well. In practice it becomes a multi quarter program to inventory everything, which produces a catalog rather than an agreement.
Truth program vs one number at a time
Multi-quarter program
- Time to value
- A year or more
- Output
- Catalog
- Same numbers still disagree
- Yes
- Requires giving up a version
- Never asked
- Scale
- One big program
One number at a time
- Time to value
- Immediate
- Output
- Agreement
- Same numbers still disagree
- No
- Requires giving up a version
- Explicit decision
- Scale
- Ten small fixes
The cost is time. A year in, the same two numbers still disagree in the same meeting, because nobody was ever asked to give up their version. Truth is not a technical property; it is a decision about whose calculation wins.
The fix is to take the single number that causes the most arguments, name an owner, write the definition, and switch everything to it. Then do the next one. Ten of those beats one program.
2. Attaching a metric to pay before it has been stress tested
Once a number affects compensation, it stops being a measurement and becomes a target that intelligent people will move. Campbell's law states the general form: the more an indicator is used to make decisions, the more it will be distorted and the more it will distort what it was measuring.
Stress test a metric before pay
- Pick candidate metric
- Run unattached for a few review cycles
- Watch how people behave around it
- Name the guardrail measure
- Only then attach to pay
You will not notice immediately, because the number improves. What degrades is the thing the number was standing in for: a response time falls because tickets get closed and reopened, a pipeline figure rises because opportunities get created earlier.
The fix is to run any candidate metric for at least a few review cycles unattached, watch how people behave around it, and name the guardrail measure that would show it being gamed.
3. Re-platforming to solve a definitions problem
New tooling is visible, budgetable, and satisfying. Definitional disagreement is none of those.
Re-platform vs settle definitions first
Re-platform now
- Visibility
- High
- Budgetable
- Yes
- Ambiguity carried over
- Intact
- Rebuild time
- A year
- Two systems disagree
- Yes
- Credibility
- Less
Settle definitions first
- Visibility
- Low
- Budgetable
- No
- Ambiguity carried over
- Resolved
- Rebuild time
- None
- Two systems disagree
- No
- Credibility
- Intact
But a migration carries every ambiguity across intact, adds a year of rebuilding, and produces a period during which two systems disagree for reasons nobody can untangle. Teams emerge from it with the same arguments and less credibility.
The fix is to settle the definitions on the system you already have. If the platform is genuinely the constraint, that becomes obvious once the definitions are clean, and the migration is then a small technical project rather than an act of faith.
4. Letting the reporting tool hold the definitions
Every modern reporting tool can define calculations inside itself. It is convenient, so the definition of a core business concept ends up living in a visualization layer.
Two things follow. Anything that does not read through that tool, a notebook, a data science model, an operational system, cannot see the definition and reimplements it. And when the tool is eventually replaced, the definitions are hostages.
The fix is to define governed concepts upstream, in the modeled data, and let every tool read the same one. A shared semantic layer is the usual name for the place those definitions live.
One set of books, kept in one place, with a rule about who may write in it: the idea long predates any of the tooling, and it is still what the first and fourth mistakes are both about.
5. Refreshing faster than anyone decides
Someone asks for real time, nobody wants to say no, and a nightly pipeline becomes an hourly one.
Set refresh from decision cadence
Does the decision happen in minutes?
send an alert, not a faster dashboard
set refresh to the decision cadence and show last updated time
The cost is not only compute. Frequent refresh makes numbers move under readers, which means every conversation starts with reconciling two screenshots taken at different times. It also makes failure louder and more frequent without making anything more actionable.
The fix is to set refresh from the decision cadence, and to write the last updated time on the page so nobody has to guess. If a decision genuinely happens in minutes, the right answer is an alert, not a faster dashboard.
6. Keeping a separate number for leadership
A leadership deck gets its own calculation, usually because someone wanted it adjusted, simplified, or shown net of something.
One calculation vs separate leadership number
Separate leadership number
- Instruments
- Different
- Adjustments
- Baked in
- Divergence found
- Worst moment
- Board vs teams
- Different numbers
One calculation
- Instruments
- Same
- Adjustments
- Visible lines
- Divergence found
- Before it matters
- Board vs teams
- Same number
From then on, the operating teams and the board are steering by different instruments. The divergence is discovered at the worst possible moment, in a room where the cost of being wrong is highest.
The fix is one calculation, with the adjustments shown as visible lines rather than baked in. If leadership needs a different view, give them a different presentation of the same number.
7. Treating access as a substitute for modeling
Granting people access to raw tables feels like enabling self service and costs nothing to approve.
Raw tables vs modeled data access
Access to raw tables
- Cost to approve
- Nothing
- Answers produced
- Private, inconsistent
- Exclusions known
- No
- Data team time
- Adjudicating
- Self service
- Unfunded mandate
Access to modeled data
- Cost to approve
- Some curation
- Answers produced
- Shared, documented
- Exclusions known
- Yes
- Data team time
- Building
- Self service
- Genuine
What follows is a set of private, mutually inconsistent answers built by people who did not know about the exclusions, the late arriving rows, or the two tables that look interchangeable and are not. The data team then spends its time adjudicating rather than building.
The fix is to widen access to modeled, documented data and to keep raw tables narrow. Access to something curated is genuine self service; access to everything is an unfunded mandate.
8. Never changing a definition, or changing it silently
Both failures come from the same avoidance. A definition that can never change slowly stops describing the business. A definition that changes without announcement makes every historical comparison quietly wrong.
The fix is a stated rule: definitions can change, changes are announced before they land, the charts are annotated on the date, and someone decides explicitly whether history is restated or the change applies forward only.
9. Measuring the team by throughput
Tickets closed and dashboards delivered are easy to count, so they become the score.
A team measured this way will produce many small artifacts, because that is what the score rewards, and will never take on the work that removes whole categories of request. The queue stays exactly as long as it was.
The fix is to count what stopped: requests that no longer arrive, spreadsheets retired, meetings that now start from the same screen. Those are observable, and they point the team at work that compounds.
Which of these to fix first
Take the two that are currently costing you meetings. In most companies that is the contested number from the first entry and the private leadership figure from the sixth, because both surface publicly and repeatedly. The rest can be sequenced behind them.
Related reading on this site
The economics of the function these mistakes damage are covered in business intelligence. For the guardrail pairing that makes the second mistake survivable, see metric shapes and their traps.
For the equivalent errors made while a data function is being set up rather than run, see the setup phase mistakes. Ownership and change control for definitions are the subject of data governance, and the skeptical reading that keeps the third mistake from being funded is in how to read a platform case study.
Common questions
Our leadership genuinely wants a single source of truth. How do we redirect that?
Agree with the goal and change the unit of delivery. Offer to settle three named numbers this quarter, with owners and written definitions. It is the same ambition, sized so it finishes.
Is a metric in a bonus plan always wrong?
No, but it should be one you have watched behave for a while, paired with a guardrail, and reviewed on a schedule. The mistake is speed, not the idea.
We already re-platformed and still have the same arguments. Now what?
Then the platform was not the constraint, which you now know for certain. Start settling definitions, and use the migration as the evidence that tooling was never the issue.
How do we say no to a real time request?
Ask what decision gets made within the hour, and who is on the hook to make it. If there is a real answer, build an alert for that specific case. If there is not, the question answers itself in the requester's own words.







