“I don’t trust it.”
Whether these words are spoken aloud or surface through attitudes and behaviors, trust is a lynchpin of success or a trapdoor to failure in our relationship with data.
Without trust, we fall back on our defaults—whether that’s challenging new ideas or old ones—and cannot create insight because we refuse to incorporate new, external information. To successfully move from data to information to insight, trust is critical.
At the same time, we know that skepticism is just as important in good decision-making. There may be very good reasons why we are cautious of taking charts and dashboards and KPIs at face value.
How can we achieve the right balance of trust and skepticism when we incorporate data into our decisions?
There are multiple reasons we lose and build trust in our data, and there is no silver bullet. That said, the better we get at identifying where and how trust degrades, the better we can get at rebuilding and strengthening it.
Obvious errors in data we interact with on a day-to-day basis will set the stage for mistrust. This can be as simple as noticing incorrect names, missing contact info, unexplained gaps in historical data, or inconsistent numbers from one system to another. These are all common red flags and degrade our trust from a user perspective.
Small variations in a question or how it’s answered can lead to big variations in the outcome. A simple misunderstanding between whether a report uses fiscal or calendar year timeframe can have a huge impact on our understanding of financials, for example.
Whether cleaning up (improving!) historical data, adjusting how it is categorized and structured, or implementing something new, systems are always changing. It’s easy for this work to degrade trust if the changes aren’t clearly communicated and understood, especially when they impact reporting.
The more sophisticated our reporting gets, the more opportunities there are for error. From a simple typo in Excel, to a filter omission in a reporting tool, to a bug in an enterprise data pipeline, errors happen no matter how sophisticated your systems are. Even a well-tested setup is vulnerable to upstream changes (what worked perfectly last year when it was launched might suddenly fail when a data cleanup initiative changes a few key values on thousands of records).
This sounds so simple but it’s harder than it seems! It relies on creating a culture of noticing problems, speaking up, and being willing to put in the time to fix it. There might be a one-time push to clean up historical data, a process change to address the root cause of the issue, and ongoing monitoring to avoid entropy.
Be specific about the questions you want to answer, and document standards in your wiki/knowledge base. For example: does ‘new business’ include existing customers expanding into a new product line? What is the definition of a current, lapsed or re-acquired member? This resource helps maintain consistency across departments and smooths staff turnover. It even benefits a tech staff of one person who can refer back to their own notes when trying to remember how to create that one tricky annual report.
Compare the system to itself over time; this can be as simple as a periodic screenshot of key dashboards. Why is revenue from Q2 last year 10% different from what this same report showed last month? Uh-oh. Maybe an old error was corrected or a new one was introduced, but either way we should figure that out proactively, and before the next board meeting! Comparing reports against themselves builds trust because it shows the system is capable of catching its own errors, and doesn’t rely on a ‘better’ external source of truth (memory, handwritten notes from last meeting, someone’s shadow Excel ledger).
Check your gut for the big picture. “We’ve had a hugely successful website awareness campaign, but our newsletter volume is static. That makes no sense.”
Spot check details. “We know this person’s membership just lapsed, are they showing up on that report?”
Listen to those little questions, and encourage everyone else to do the same. If you feel your trust start to slip, speak up and check it out.
It’s unrealistic and corrosive to put the onus of trustworthy data on a single role or department. The landscape of a healthy technology system is always changing and includes the people who use it on a daily basis, the people who rely on the data inside it, and the technical configuration. Organizations that are the most successful with their tech trust the overall process—and each other—to find and correct issues before they become chronic.
There will always be a need for specific technical fixes to specific data quality problems, but we need to remember that a technical fix isn’t the only component that goes into regaining trust. Human interactions and shared accountability are key components to a resilient system that build trust over time.