Dashboard Sprawl
Examining the reasons behind why dashboard sprawl happens
Maybe it’s just the people / communities I follow, but wherever I look (Substack / LinkedIn / Reddit), this post by Ergest Xheblati pops up. In it, he documents the efforts of Abhi Sivasailam in cleaning up the “dashboard sprawl” at Flexport, the global logistics company now run again by Ryan Petersen (if you are a fan of corporate drama, you can read up about Dave Clark’s entry and exit from Flexport; OK I’m digressing now).
According to Xheblati, this is why dashboard sprawl happens:
IF managers prefer to rely on their intuition to make effective decisions AND they assume they need a lot of detail to build intuition about their domain AND they never feel like they ever get a full picture of their domain THEN they will have more and more questions. At the same time, there’s tremendous pressure on them to use data analysis to make decisions.
IF the data team has no way to prioritize all these requests THEN they consider every request as important. Combined with the undesirable effect from above, this leads to more and more dashboards being created, more and more charts being crammed into these dashboards. It eventually leads to more confusion and less clarity.
Now, as those of you who read this blog regularly know, I’ve been conducting interviews over the last month and a half to understand better how companies use dashboards. And those have thrown up a whole bunch of more reasons on why “sprawl” happens. Based on these interviews, and my own experience, here are some more reasons on why dashboard sprawl happens:
There is a desire from analytics teams to put their work “in production”. Once you have done a piece of analysis, you want to be prepared the next time this kind of an analysis is asked for. So you build a dashboard with your analysis, to pre-empt such requests in the future (I’ve done this a few times).
And then you find that when the request comes in the future, there is a new nuance to take care of because of which the old dashboard doesn’t work anyway. And in all likelihood, you’ll either add a new dashboard, or more features to your old oneRelated to this, you find some new pattern, and then want to make sure that you don’t miss that pattern the next time it occurs. And so you quickly build a dashboard to notice this pattern. I’ve personally not done this but observed several teams who do.
The business can change. The way you track metrics change. So you build dashboards to track the new metrics. For a while you don’t bother with the old dashboard tracking the old metrics. And then you try to get rid of that old dashboard, and find “one engineer in Nebraska” who is using it, because of which you can’t deprecate it.
We should make a new version of this XKCD to describe this kind of dashboard sprawl.
When leadership changes happens, the way you track the business can change. Sometimes when someone comes in from another organisation, they’ll want to see the metrics in the same way that they used to there. And so you create more dashboards, and for reasons detailed above, you don’t get rid of the old one.
Related to this, tools start getting associated with the leaders who introduce them. And so, when one leader leaves, people stop using their tools, and build new ones for the new leader.
Leaders of data teams, like all other good leaders, want to build their own empires. More dashboards means more to do. And more reason to grow your team. :P
Unless they have been built cleverly, dashboards can be come slow quickly. This is because more data than is required gets queried, and this adds to the loading time. And when one dashboard gets slow, teams decide to “refactor”, and build a new (and improved) dashboard to replace the old one. Except that the old dashboard never goes away.
You can have a “dashboard of dashboards”. For example, each department has its own dashboard tracking its metrics, and then there is a central dashboard linked to all these dashboards to give one simple view.
Some organisations have “exception dashboards”. Conventional dashboards are good at presenting information as things stand now. However, when there is something unusual, it’s easy to miss that signal in the usual dashboards. And so you go for an additional “exception dashboard”.
One interviewee said this about one of his clients, “now, they have 50 dashboards. And then there is a 51st dashboard to track the usage of the other 50 dashboards” (that deserved to be highlighted)
I’ll stop here. This list is not exhaustive by any means.
What other reasons have YOU seen for dashboard sprawl happening, and how do you think it can be avoided?
Sharing