Sweat the Small Stuff: Risk of Calamity as a Governance Metric

Years ago a friend gave me a copy of Richard Carlson’s Don’t Sweat the Small Stuff… and It’s All Small Stuff. For personal wellbeing, Carlson has a point. Stressing over a rude driver won’t get you anywhere, and losing it in the supermarket checkout because the cashier just went on break as you got to the top of the line won’t win you any friends.

In data governance, though, the small stuff is often the stuff that matters. A billing error, a missed retention deadline, a customer record that doesn’t match across three systems. None of them is a crisis by itself, so none of them wins budget when it’s judged against a return-on-investment calculation. Nobody sweats them, but they can add up quietly into fines, refund programmes and headlines.

What happens when the small stuff grows up?

Even organisations that do sweat the small stuff have usually sized their processes for a known frequency. Take data subject access requests. Most organisations cope with a steady trickle. If we add Generative AI tools that let anyone draft and submit a seemingly legally sound request in thirty seconds or less that takes 30 minutes or more to decipher what the requester is actually looking for, and still needs to be dealt with within 30 days in to the mix, the small stuff starts to scale up. Nothing about an individual request has changed. The volume has. A process that was “under control” at fifty a month becomes a calamity at five hundred. It’s like going bankrupt. It can happen gradually, and then all at once.

So what should we measure?

Next to ROI, I’d suggest leaders ask about Risk of Calamity (ROC):

1. What small, recurring data failures are we tolerating today?
2. What is their cumulative cost if nobody is watching?
3. What happens if they happen ten or a hundred times more often?
4. Which controls break first under that load?
5. What would the impact be if that data was to be ingested into Generative AI processes (or is being generated by AI processes)?
6. What is it costing, per small issue or incident, today in down time, rework time, or customer appeasement and apology time/money to fix the issue every single time?

This is a proxy metric I used over 20 years ago in my telco days when looking at billing errors. It helped drive a data governance and data quality programme that focussed on timely (automated) identification of issues based on rigorous analysis of the processes that developed products, created the bill code data for products on bills, managed the provision, update, and removal of services from accounts, and put the focus on prevention of defect in design while enabling the automation of remediation as part of detective and corrective controls.

The ROC that I tracked was how many people would be required to manually review and correct incorrect billing accounts if the volume of incidents grew without preventative and automated corrective controls. When my presentation to the Audit Committee summarised the ROC with a clip from the movie Outbreak (the scene where Donald Sutherland shows the map of America turning red illustrating a virus spread), the message seems to have gotten through: investing in upstream governance and control, automation of detection and remediation (as much as we could) using appropriate tools, and ensuring we paid attention to small issues (triage analysis, risk assessment) in case they were symptoms of larger problems, were all recognised as important tasks for my team worth investing in.

Carlson’s advice might make you calmer. For data governance leaders, peace of mind often comes from sweating the small stuff before it turns into the big stuff.