The most expensive meeting in your company
Every organization has a version of it: two teams present the same metric with two different values, and the room debates whose number is real. Nobody lied. Nobody miscounted. The dashboards diverged for reasons that are completely knowable - and completely fixable, once someone with authority decides to fix them. That someone is you. This is the flagship session of the leader track, because it is the one BI problem that only leadership can solve.
Why two dashboards disagree 13 min live
Here is the anatomy of the classic fight. Sales reports $2.1M because their dashboard counts every order the moment it is booked, cancelled or not. Finance reports $1.8M because theirs counts only recognized revenue on completed orders, refreshed from last night's close. Same warehouse, same month, two defensible queries. The disagreement lives in the definitions, not the data.
LiveThe four divergence points6 min▶
When two dashboards disagree, the gap almost always enters at one of exactly four places. Learn these and you can chair the "whose number is right" meeting in five minutes instead of forty:
- Different filters. Are cancelled orders in or out? Refunds? Test accounts? Internal orders? Each yes/no silently moves the number.
- Different definitions. Booked revenue vs recognized revenue. Active customer as "ordered this month" vs "has a live subscription". Same word, different formula.
- Different joins. One query joins orders to order items, another joins through subscriptions - and rows quietly duplicate or drop along the way.
- Different refresh times. Sales refreshed at 2pm, finance at midnight. On a fast-moving day, that alone explains a real gap.
The forty-minute audit. A leadership team we know ran the same "whose churn number is right" argument monthly for a year. The eventual answer: one dashboard counted paused subscriptions as churned, the other did not. Four hours of analyst time to diagnose, one sentence to fix - once someone wrote the definition down and made it official.
Self-studyAnatomy of a metric definition4 min read▶
A metric is not a name - it is a small contract with six clauses. If any clause is unwritten, two teams will fill it in differently. Here is the full anatomy, using Daybreak's "revenue" as the example:
| Field | What it pins down | Daybreak "revenue" example |
|---|---|---|
| Name | The one official label | Net product revenue |
| Formula | The exact math | sum of quantity x unit price per order item |
| Grain | What one row means | order item, rolled up by order date |
| Filters | What is in and out | excludes cancelled orders and test accounts |
| Owner | Who arbitrates changes | VP Finance |
| Refresh | How fresh it is | nightly at 2am, complete through yesterday |
Six short rows. Most metric fights in most companies trace back to one of these rows never having been written down.
The semantic layer: define once, agree everywhere 15 min live
You could fix metric drift with discipline: memos, reminders, heroic analysts checking each other's SQL. It will not hold. The durable fix is structural: encode the business definitions once, in a layer that sits between the warehouse and every chart, so that no dashboard computes "revenue" on its own. The industry calls this a semantic layer - a governed dictionary that every tool is forced to read from.
LiveThe same idea in every vendor6 min▶
Vendors brand this layer differently, and the branding hides how converged the industry actually is. Strip the names and all three are the same move: a governed metadata layer between warehouse and consumption, centralizing business definitions so every tool computes the same numbers.
| Vendor | What they call it | Who edits it |
|---|---|---|
| Microsoft Power BI | Semantic model - a star schema plus measures plus business terminology, positioned as the single source of truth. Renamed from "dataset" in November 2023, precisely to signal it carries meaning, not just data. | BI developers, in the model layer |
| Looker | LookML - a language defining dimensions, measures, views, and models. Looker generates the SQL from it, so business users explore freely and never write a query. | The data team, in versioned LookML files |
| dbt Semantic Layer | MetricFlow - metrics defined once in YAML on top of semantic models. The pitch is literally "define once, use everywhere", and any downstream tool can request the metric. | Analytics engineers, in the dbt project |
Self-studyWhat it costs - the honest trade-offs4 min read▶
A semantic layer is not free, and pretending otherwise is how these initiatives die in month three. Budget for three real costs:
- Modeling time up front. Someone has to interview the business, reconcile the competing definitions, and encode the winners. For a mid-size company's top 20 metrics, that is weeks of skilled work, not days.
- A gatekeeping function. Once definitions are governed, changing one requires a request and a review. That is the point - but teams used to editing their own dashboard formulas will feel slowed down, and will say so.
- A slower first chart. Ad-hoc tools let anyone chart anything in minutes. Through a semantic layer, a brand-new metric must be defined before it can be charted. You are trading speed on the first chart for trust on every chart after it.
The trade is worth it for the numbers the company steers by. It is overkill for one-off explorations - which is exactly why Part 3 separates certified content from ad-hoc content instead of governing everything.
Metric governance for leaders 6 min live
The technology in Part 2 needs an organizational spine, and it is small enough to write on an index card: every key metric gets an owner, a written definition, and a certified home. The owner arbitrates disputes and approves changes. The definition is the six-field contract from Part 1. The certified home is the one dashboard where the official number lives - marked as certified, so everyone can tell it apart from the ad-hoc charts teams spin up for their own exploration. Ad-hoc content stays legal and fast; it just cannot masquerade as the official number. Then a light ritual keeps it alive: a quarterly metrics review where owners walk through changes, retire dead metrics, and settle open disputes.
LiveYour metric charter4 min▶
This is the whole program. If you enact nothing else from this course, enact this checklist:
- List the load-bearing metrics. The 5 to 15 numbers that appear in board decks and steer real decisions. Not fifty - the ones people fight about.
- Name one owner per metric. A person, not a committee. Ties go to whoever answers for the number when it is wrong.
- Write the six-field definition. Name, formula, grain, filters, owner, refresh. One page for all of them.
- Certify one home per metric. One dashboard is the official source; it gets the certified mark. Everything else is clearly ad-hoc.
- Schedule the metrics review. Quarterly, 45 minutes, owners present. Definition changes happen here and nowhere else.
Watch definitions matter ★ 12 min · follow along
Daybreak, our coffee-subscription company, has one warehouse and one innocent-looking question: what is our revenue? Watch how one definitional choice - do cancelled orders count? - moves the company's headline number. No code; just pick and read.
Look at revenue by order status. The box below splits Daybreak's revenue by status. Some of that money sits on cancelled orders. Should "revenue" include it? Sales-style booked revenue says yes; finance-style recognized revenue says no. There is no math answer - it is a definition decision.
Now look at the single company number. The KPI box below shows total revenue as one figure. Whichever choice a team makes in step 1 silently moves this number - and this is the number that opens the board deck.
Press Show SQL on both boxes. Read the generated query. The definition IS the query: a one-line filter on status is the entire difference between the $2.1M meeting and the $1.8M meeting. Whoever controls that line controls the truth.
This is what a semantic layer would freeze. In a governed setup, the status filter lives in the definitions layer, written once by the metric owner. Neither sales nor finance could produce a different "revenue" without visibly requesting a definition change. The forty-minute meeting becomes structurally impossible.
Your turn: draft a definition card ★ 8 min · pen and paper
Pick the metric your organization fights about most - revenue, churn, active users, pipeline, headcount, utilization. Draft its six-field definition card right now, in the session. Incomplete is fine; the blanks you cannot fill are the most valuable output.
Name the fight. Which metric triggered the last "whose number is right" moment you personally sat through? Write its official name - or the two competing names, which is itself a finding.
Fill the six fields. Name, formula (in words, not code), grain, filters (what is in and out - be specific about cancellations, refunds, test data), owner, refresh. Prompt yourself: could a new analyst rebuild this number from my card alone?
Circle the blanks. Every field you could not fill is a divergence point waiting to fire. If you could not name an owner, you have found the root cause - a number nobody owns is a number everyone redefines.
Try it yourself - this week ◐ 20-30 min total
- List your organization's 5 load-bearing metrics - the ones that appear in board decks and settle arguments. Ruthlessly exclude everything else.
- For each, find the owner. Ask around: "if this number is wrong, who answers for it?" Where the honest answer is "nobody", write exactly that - an unowned metric is your finding, not your failure.
- Draft one full six-field definition card (Demo 2 format) for your most-fought-over metric and float it past one person from a different function. Their edits show you the divergence in the wild.
- Bring to a4: your worst two-dashboards-disagree story - what the meeting cost, and which of the four divergence points caused it. Session a4 turns that pain into a commissioning process.
Official sources covered
No commercial platform teaches semantic-layer governance to leaders - the vendors each document their own layer for practitioners. This session unifies those documents into the leader view. This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Sales shows $2.1M, finance shows $1.8M, and both queries ran correctly on the same warehouse. The most likely cause is...
Correct queries with different results almost always diverge at one of four points: filters, definitions, joins, or refresh timing. It is a definitions problem, not a fraud or infrastructure problem - which is why the fix is a written definition, not an investigation.
2 · What does a semantic layer actually store?
The semantic layer holds meaning, not data: what "revenue" is, which orders count, what one row means. Power BI semantic models, LookML, and dbt MetricFlow are all this same governed dictionary - define once, agree everywhere.
3 · Your organization wants "one version of the truth". The right first step is...
Tools automate agreements; they cannot create them. Until a named owner and a written definition exist, any platform will faithfully compute several versions of the truth. Governance first, technology second - and locking everything down just drives teams back to spreadsheets.