What I write about: reliable analytics systems that stay explainable

I write about the checks, decisions, and handoffs I use when a KPI moves, a pipeline slips, or two dashboards disagree.

If I cannot point to the query, release step, owner, or failed check behind a claim, I leave it out.

What I cover

• Pipeline checks that catch lateness, row loss, join failures, and broken publishes before the dashboard takes the hit
• Modeling patterns that keep row meaning, metric definitions, and dashboard numbers legible as the warehouse and team grow
• Delivery habits like release checklists, incident notes, ownership boundaries, and debugging order that hold up under pressure

A concrete example

Say Monday revenue drops in an executive dashboard and nobody expected it.

I start with the smallest checks that narrow the failure.

• Confirm the source landed on time.
• Compare row counts and key joins in the model behind the chart.
• Check whether the metric logic or filter changed on purpose.
• Write down the current hypothesis before Slack fills with partial explanations.

That sequence is the first-pass order I use in When a dashboard number changes, I check these four things first.

When those checks pass and two dashboards still disagree, I move to metric definition work.

When the incident is active and other people need updates, I keep a short incident note beside the debugging work.

I want each post to leave behind something I would run again: a check, a note template, a definition card, or a release habit that keeps the next incident explainable.

Tradeoffs

• Breaks when I start writing about tools before I can name the check, contract, or decision rule that matters. Mitigation: anchor the post to the operating artifact first and mention tooling only when it changes the workflow.
• Breaks when the useful answer depends on team size, latency expectations, or ownership structure. Mitigation: say that boundary directly and explain what I would change under those constraints.
• Breaks when the real example is too client-specific to publish cleanly. Mitigation: generalize names and numbers, but keep the failure mode, decision, and mitigation honest.

Close

Next step: Start with my default stack and workflow if you want the operating model behind these notes.

I’m interested in the KPI change, late run, or dashboard disagreement that brought you to these notes.