Being trusted with a number

The asymmetry that governs the job

One wrong number presented in a leadership meeting costs more trust than ten correct ones build. That is unfair and it is how people work: a correct number is invisible, and a wrong one is a story told for a year.

The response is not anxiety. It is a routine: a fixed sequence you run before anything leaves your hands, so that checking is not a decision you have to make while tired.

The checking list

1. Row counts before and after every join. Write them down. If the count changed and you did not expect it to, stop and find out why. This single habit prevents the most expensive class of error in analytics.

2. Reconcile against a second source. The finance export, the admin panel, last month’s report, the count in the source system. Your number does not have to match exactly; you have to be able to explain the gap.

3. Look at five actual rows. Beginners never do this and it catches an astonishing share of bugs: the duplicated record, the test account, the row where the customer name is asdf.

4. Check the boundaries. Earliest and latest date. Minimum and maximum of every numeric column. Count of nulls per column. A max order value of 9,999,999 or a date in 1970 is a data problem announcing itself.

5. Ask what this number would look like if you were wrong in the most likely way. If you suspect a fan-out, what would revenue look like if every order were counted three times? If it looks like that, you have your answer.

Two bugs worth knowing by name

Fan-out, from the SQL lesson: joining to a one-to-many table before aggregating a one-side column multiplies it. Row counts catch it.

The daylight-saving gap. A job scheduled inside the hour when the clocks change (between 01:00 and 03:00 local time in Europe and North America) can be skipped at the spring change or run twice at the autumn one, depending on the scheduler, because local time is not monotonic: the clock moves forward in spring and backward in autumn. The symptom is one missing day in March and one doubled day in October or November. Schedule in UTC; convert for display only.

Presenting a number with its uncertainty

The fear is that caveats make you sound unreliable. Done properly they do the opposite:

“Orders were 14,200 last month, up nine per cent. Two things to know: the Nigeria channel is missing three days because of the migration, so the true figure is slightly higher. And I have excluded test accounts, which the old report did not: that alone accounts for about two points of the change.”

That is a person who has checked. The version without caveats is either luckier or less careful, and everybody in the room eventually finds out which.

“I do not know yet”

A complete and professional answer, with a time attached: ”I do not know yet. I will have it by four.” It builds far more trust than a confident guess that turns out wrong, and it is available to you at any experience level.

The failure mode is the guess given to avoid looking uncertain in a meeting, which then travels into a slide, which then travels into a decision.

When you get it wrong

You will. The recovery is mechanical:

1. Say so immediately, in the same channel where the wrong number was given.
2. Give the corrected figure.
3. One sentence on the cause. Not a paragraph of apology.
4. One sentence on what stops it recurring.

Do not bury it, do not wait for the next meeting, and do not hope nobody noticed. Fast correction is the behaviour that makes people comfortable relying on you, because it means they will hear about problems from you first.

Automating the checks

The free path is a script with assertions, and it covers most of what expensive tooling does:

assert df["order_id"].is_unique, "duplicate order ids"
assert df["amount"].min() >= 0, "negative amounts present"
assert before == after, f"join changed row count: {before} -> {after}"

dbt has tests built in and is free and open source. Great Expectations and Soda Core are free libraries for the same job. The paid observability products (Monte Carlo and similar) buy you automated anomaly detection across many tables, which matters at scale and not on your first pipeline. Job adverts name them; start with the assertions.

The limitation

No amount of checking survives a source system changing without telling you. A field renamed, a new status value, a supplier changing their export format: your assertions pass on old assumptions until the day they do not.

That is why monitoring counts over time matters more than any one-off check. A row count that has been 40,000 daily for a year and is 12,000 this morning is worth an alert, and setting that up is usually a day of work that pays for itself the first time.