Dashboard rot as org attention grave markers

technical-culture Mar 31, 2026

Many years go, I was asked to do a big "find every dashboard for our large org (vaguely under a big VP with thousands of people under them)" because anyone can "make a dashboard" if they barely knew a lick of SQL at the time. We wanted to get a very rough sense of "where are people getting information to make decisions".

After days, possibly weeks of searching, scanning docs for links, asking more senior folk what resources they used, I started building a list. Also, thanks to the power of searching, had found all sorts of older artifacts, reports, docs, even homepages for teams that don't even exist any more. You can find a lot of links to dashboards in such places.

The majority of the dashboards I found, maybe as much as half, were completely dead, partially broken, or otherwise unusable by the time I went to check on them.

This is probably not a surprise to anyone who's been working with dashboards for any significant period of time. In fact, one of the tongue-in-cheek "tips and tricks" that many practitioners have for large breaking data schema migrations like this is that after reasonable warning and guidance is given to everyone using a table, all the stragglers who don't migrate off can be left to "come find us once things break". Very often no one even notices the dashboards breaking.

The immediate and obvious conclusion to the fact that when half of an organization's dashboards break and literally no one notices is that no one is actually looking at those dashboards. That part is obvious and not all that interesting. The interesting bits are the conclusions that various people may come to afterwards.

If the obvious truth is that no one is looking at a huge pile of dashboards, then why did anyone even make the dashboard to begin with? For some folks, this line of questioning yields a seemingly obvious answer – we shouldn't have bothered making so many dashboards because most of them aren't going to provide any lasting value. This is where we get a lot of the received wisdom to push back harder on dashboard requests, to resist adding one more dashboard to the pile. It also means there's less maintenance overhead from any dashboard you make that accidentally gets used more than once.

For the longest time, I just more or less ran with this view of the world. Teams would come request a fancy dashboard to "keep an eye on things" and I'd push back hard to get them to focus on the honestly handful of durable metrics that actually mattered to their work. In the end, they'd get something tight and to the point, and I wouldn't have to maintain a massive dashboard that everyone was going to ignore. In the overall scheme of things, it was roughly the correct balance of doing things to keep teams moving along without overloading the limited attention me and my teammates had to dedicate towards maintenance. Given our workload, we had to optimize for our own capacity.

As time went on, we managed to get a better grip on the volume of work coming down and could take better stock of the whole teams and dashboard situation. The biggest factor was when we started encouraging teams to build and maintain their own dashboards, but with our guidance as to what the correct metric definitions and queries are. Essentially, we would furnish teams with the knowledge of HOW to count things "in the approved way" for their specific use cases, and then they could build their own dashboards off for their own purposes without our extended handholding.

But now that I have more time to digest what is going on from a distance, I'm asking myself what are the dynamics that go behind this constant dashboard churn anyways? None of the people who are requesting this work are doing it out of some desire to do create waste. It was fulfilling a need at a specific point in time, but the problem is that "point in time" is really short.

About the only thing that makes sense to explain what is going on is the notion of "attention" at an organizational level.

Dashboards act as data viewports into a system. It lets teams keep an eye on how their system is running, are users adopting things, are they buying, where are they getting stuck, etc. As data scientists and quantitative UX researchers, we're fighting tooth and nail to make sure that the views provided by these dashboards is truthful and accurate. We also know that if we make a dashboard, we effectively sign up to keep maintaining it for as long as anyone keeps using it. But the fact is that almost everyone stops using it extremely soon. And the only reason that is true is because "priorities have moved on" at team level.

One thing I've always found interesting (or peculiar) about "Strategic Planning" exercises across many companies of many sizes is that they're surprisingly "scale free". The CEO will have something like 3-7 strategic goals they want to accomplish. Those get farmed out to various divisions, who in turn chop up those big goals into more concrete goals and create their own 3-7 more narrow interpretations of the strategic goals that they're going to commit to. These narrower goals filter down through middle managers who are charged with executing one or more of those initiatives, by generating their own set of 3-7 goals. While through this process the number of distinct goals expands with each layer due to varying interpretations and local additions, the absolute numbers handled by a given person always stays in that tight range. Apparently humans just don't have the capacity, both mental and also temporal, to handle more things at once.

Go through these exercises enough times and you very quickly realize that everyone always overcommits their time. They say they're going to work on projects 1-7 but then a few weeks in, projects 8-10 pop up out of nowhere and everything has to be reprioritized. Effectively, everyone's attention is fully booked going into a planning phase, and then only gets overloaded as it progresses. Which means, unless a project's ongoing situation is made a very high priority, no one has the attention bandwidth left over to look at an old dashboard because everyone's supposed to be working on the next project now.

And UX teams have recognized this pattern for a long time now. There have been efforts to push teams to pay attention to not just the metrics when things launch, but also to use metrics to check if the launch actually landed with the customer. The effectiveness of that approach is rather mixed because, again, organizational attention is a limited resource that can get eaten up immediately by the next shiny object. (Oh look, ✨ AI ✨)!

Regardless of whether those efforts work, or not. Attention eventually wanes, projects sunset, and no one is going to remember to shut that stuff down. All those dashboards that were spun up, shared around in a handful of meetings, fall unused. The hope is that aside from using up some disk space somewhere, they're not actively touching data and crunching numbers, endlessly burning energy for a potential viewer that won't come. Better dashboarding systems have caching/pre-loading mechanisms in place to handle that specific case. Otherwise, having breaking table changes might actually be a blessing in disguise, stopping endless waste from going on forever.

So all these broken dashboards are essentially archaeological records of past projects, past goals, past initiatives. Perhaps interesting material for understanding organizational behavior from an academic standpoint, but otherwise useless clutter for the rest of us.

Does this insight really tell me anything useful that I can directly apply to my job now? I'm not sure.

Somewhat interestingly, this whole line of thinking is apparently valid enough that it actually has an academic grounding, via an "attention-based view" of organizations. The biggest citation I could see seems to be "Towards an Attention-Based View of the Firm" from 1997 (JSTOR, paywalled, pdf link I found) by William Ocasio. The paper seeks to lay out a whole theory of how decisions are made within an organization by decision makers and everything sorta fans out from their ability to pay attention to issues that need handling. Things start from the executives but get passed down through the layers of management down. It's about 20 pages of text but quite dense – enough that I can't quite process it at 1AM.

But either way, it's a useful concept to have in your back pocket. And I think it sometimes helps explain the utter chaos and apparently incoherent moves of an organization that seems to lurch from one initiative to another. Not that knowing what's going on can easily stop it from happening.

Subscribe!

Standing offer: If you created something and would like me to review or share it w/ the data community — just email me by replying to the newsletter emails.

Guest posts: If you’re interested in writing something, a data-related post to either show off work, share an experience, or want help coming up with a topic, please contact me. You don’t need any special credentials or credibility to do so.

"Data People Writing Stuff" webring: Welcomes anyone with a personal site/blog/newsletter/book/etc that is relevant to the data community.

I’m Randy Au, Quantitative UX researcher, former data analyst, and general-purpose data and tech nerd. Counting Stuff is a weekly newsletter about the less-than-sexy aspects of data science, UX research and tech. With some excursions into other fun topics.

All photos/drawings used are taken/created by Randy unless otherwise credited.

randyau.com — homepage, contact info, etc.

All Tuesday posts to Counting Stuff are always free. The newsletter is self hosted. Support from subscribers is what makes everything possible. If you love the content, consider doing any of the following ways to support the newsletter:

Consider a paid subscription – the self-hosted server/email infra is 100% funded via subscriptions, get access to the subscriber's area in the top nav of the site too
Send a one time tip (feel free to change the amount)
Share posts you like with other people!
Join the Approaching Significance Discord — where data folk hang out and can talk a bit about data, and a bit about everything else. Randy moderates the discord. We keep a chill vibe.
Get merch! If shirts and stickers are more your style — There’s a survivorship bias shirt!