Why Data Engineers Practice Explaining Dashboard Aloud

How to explain a dashboard out loud:

1. Start with the goal
   "This dashboard helps the sales team
   track revenue and pipeline health."

2. Give the high-level sources
   "It pulls from Salesforce (CRM),
   Stripe (payments), and our data
   warehouse (BigQuery)."

3. Explain the key metrics
   "Revenue = sum of closed-won deals.
   Pipeline = open opportunities weighted
   by probability."

4. Show the impact
   "The sales team uses it daily to track
   $5M in monthly pipeline and close
   20% more deals."

Practice tip: Record yourself. Listen for:
- Filler words ("um", "uh", "like")
- Jargon you didn't explain
- Places where you lost the thread
- Did you explain "why" or just "what"?

Stakeholder Summary Template:

The Goal:
[1-2 sentences on business goal]

The Sources:
- CRM: ___
- Payments: ___
- Product: ___
- Other: ___

The Metrics:
- Revenue: ___
- Pipeline: ___
- Churn: ___
- Conversion: ___

The Impact:
- Revenue tracked: $___
- Users: ___
- Decisions supported: ___

The Ask:
[What you need from the stakeholder]

The Refresh:
[How often data updates]

Why practice aloud:
- You catch vague claims
- You fill in missing details
- You build confidence
- You get faster

Walk the Data Flow (explain aloud):

Step 1 — State the goal:
"I want to calculate daily revenue
from Stripe and Salesforce."

Step 2 — Walk through the data:
"Stripe sends charge events to S3.
Airflow loads them into BigQuery.
dbt models join charges with deals.
The dashboard reads from the mart."

Step 3 — Explain the metric:
"Revenue = sum of successful charges,
excluding refunds, grouped by day."

Step 4 — State what you expect:
"I expect revenue to match Stripe's
monthly report."

Step 5 — State what happened:
"Dashboard shows $480K, but Stripe
shows $500K. A $20K gap."

Step 6 — Find the issue:
"We're missing failed charges that
later succeeded. And one day's data
wasn't loaded (Airflow failure)."

Step 7 — Fix and re-explain:
"I'll include retry charges, add
Airflow alerts for failed loads, and
reconcile against Stripe's report."

Why this works:
- Forces you to slow down
- Exposes hidden assumptions
- Finds bugs faster

Debugging Template:

Bug Report:
- Summary: ___
- Dashboard: ___
- Source: ___
- Refresh: ___

What you expected:
[What should happen]

What happened:
[What actually happened]

Hypothesis:
[What you think is wrong]

Root cause:
[Why it happened]

Fix:
[What you did to fix it]

Prevention:
[How to prevent this in the future]

Practice tip: Write this out, then read it aloud.
You'll catch gaps in your own reasoning.

Common data engineering bugs:
- Missing daily partition
- Wrong join key (fanout)
- Double-counting
- Late-arriving data
- Timezone mismatch
- Duplicates in source
- Nulls filtered out
- Wrong date range
- Stale materializations
- Schema drift
- Missing incremental data
- Incorrect dedup logic
- Silent pipeline failures
- Bad test coverage
- No reconciliation

Metric Definition Template:

Metric: ___
Owner: ___
Dashboard: ___

Definition:
- What it measures: ___
- Formula: ___
- Source tables: ___
- Filters applied: ___
- Time granularity: ___

Edge cases:
- Refunds: ___
- Trials: ___
- Cancellations: ___
- Duplicates: ___
- Late data: ___

Refresh:
- Frequency: ___
- Latency: ___
- SLA: ___

Owner sign-off: ___

Why practice aloud:
- Walk through each definition
- Ask "does this match your mental model?"
- Fix gaps before building

Alignment Meeting Script:

1. Goal (5 min)
   "We're building a dashboard for the
   sales team to track pipeline."

2. Metrics (15 min)
   - Revenue: closed-won deals
   - Pipeline: open opportunities × probability
   - Win rate: closed-won / total closed
   - Average deal size: revenue / # deals

3. Edge cases (10 min)
   - Refunds: deducted from revenue
   - Trials: not counted until paid
   - Multi-currency: converted to USD
   - Duplicates: deduped by deal ID

4. Refresh (5 min)
   - Daily at 6am
   - 1-day latency for late data

5. Questions (10 min)
   - What decisions will this support?
   - What would make it useful?
   - What would make it useless?

6. Sign-off (5 min)
   - Stakeholder approves definitions
   - We document and build

Why practice aloud:
- You surface disagreements early
- You align on definitions
- You avoid rework later

Model Review Script (explain aloud):

1. Context
   "We're building a sales dashboard
   for 50 reps tracking $5M pipeline."

2. Grain
   "Fact table grain = one row per
   opportunity per day."

3. Dimensions
   - Date
   - Rep
   - Region
   - Product
   - Stage

4. Facts
   - Deal amount
   - Probability
   - Expected revenue
   - Days in stage

5. Trade-offs
   - Pro: flexible, easy to slice
   - Con: larger fact table
   - Mitigation: partition by date

6. Outcome
   - Dashboard refreshes daily
   - Query time: <5s
   - Supports 50 reps
   - Drives weekly pipeline reviews

Practice tip: Explain the trade-offs out loud.
If you can't defend a model, reconsider it.

Star Schema Template:

Fact Table: fact_opportunities
- opportunity_id (PK)
- date_id (FK)
- rep_id (FK)
- region_id (FK)
- product_id (FK)
- stage_id (FK)
- amount
- probability
- expected_revenue
- days_in_stage

Dimensions:
- dim_date (date_id, date, week, month, quarter, year)
- dim_rep (rep_id, name, team, manager)
- dim_region (region_id, name, country)
- dim_product (product_id, name, category)
- dim_stage (stage_id, name, order)

Why star schema:
- Simple to query
- Fast joins
- Works well with BI tools
- Easy to extend

Alternatives:
- Snowflake (more normalized, slower joins)
- Data vault (complex, audit-focused)
- One big table (fast but inflexible)

Practice tip:
Read this out loud before the design review.
You'll catch gaps in your reasoning.