When my friend Abhi Sivasailam joined Flexport they had somewhere north of ~2700 dashboards. After he was done, they had about ~60. That’s a 97% reduction of dashboard sprawl! Read on to learn how he did it.
This week’s issue of the newsletter is dedicated to Abhi and his ample generosity (and friendship) in sharing what he’s learned. He’s currently working on next generation, bleeding-edge data tools in Levers Labs.
The problem
Before we look at the solution, let’s first analyze the problem.
In my career in data, I’ve done it all. Data engineering (primarily), data analysis, data science, data automation, etc. I’ve enjoyed them all except one. Nothing was more frustrating than when I was a data analyst.
I’d build a dashboard, release it and think I was done, but people kept asking for more views, more sliders, more breakdowns and more filters.
I’d spend days working on an analysis, find some insights, present my findings only to be asked even more questions, go back answer those questions and get 10 more.
That’s why I gave up and went back to what I enjoyed most, data engineering.
But these questions kept nagging me:
- Why do managers, executives, etc. keep asking for more and more dashboards?
- Why do they always want more sliders, more filters, more breakdowns?
- Why do dashboards feel like a never ending quest? Why are they never done?
- Why is it that despite all these new, modern data tools the problems still remain?
It’s taken me years to finally arrive at a mostly-satisfying answer, and despite it being incomplete I’ll share it with you.
Here’s a partial diagram from my analytics Current Reality Tree analysis. (That’s a subject for another post by the way, but this branch of the tree explains my thinking)
Here’s how to read it:
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.
Analysis and mental models
The word “analysis” comes from Greek and means roughly to pull apart, to shake loose. By focusing exclusively on analysis, we keep fragmenting reality into smaller and smaller elements. Dashboards are nothing more than a highly fragmented view of reality.
The fragmentation ends up creating gaps in our understanding of the world, in our mental models of our domain. Normally we wouldn’t care. Most of us are happy with a shallow understanding of any single domain.
However managers and executives are responsible for their domains. This means not only do they need to make effective decisions, but also that they need to be able to answer any questions from their managers.
If they make ineffective or wrong decisions, their reputations and careers are on the line. Not to mention that they are often heavily incentivized to reach certain results. Under such heavy pressure, the gaps created by continuous fragmentation will constantly trigger more questions.
As you can imagine, this leads to a never ending barrage of requests to the data team. And what does the data team provide? More analysis, more dashboards, more charts, more buttons, sliders and checkboxes which leads to more and more fractionation and more and more gaps.
A vicious cycle.
Dashboard trees
Abhi’s first insight when he joined Flexport was that metrics are the key primitive. If you can define and agree upon an organizations’s key metrics, you can start to get a handle on the problem.
His second insight was that in order to facilitate the construction of rich mental models that enable intuitive decision making, dashboards needed to be organized hierarchically and structured as a cascading tree with multiple levels.
Here’s what that looks like (click to zoom in)
Abhi’s definition of a dashboard tree says:
“The dashboard tree is a bounded and cascading set of dashboards that define and relate key input and output metrics for the business.”
The keys here are highlighted.
bounded means we’re not allowing dashboard sprawl
cascading means there’s a hierarchical order that helps build context
relating key inputs and outputs means there’s a logical relationship among them
The structure of the dashboards reveals how the business works. At the top (L0) you have the overall Goal of the business (such as increase MRR/ARR).
At the next level (L1) you have Critical Success Factors (CSFs) such as Acquisition, Customer Lifecycle, Product Experience and Summary Financials.
Below that (L2) you have Necessary Conditions (NCs) for each of those CSFs. For example for Acquisition you have Pipeline Creation and Pipeline Conversion. Below that (L3) you have even more nested Necessary Conditions (NCs) that enable the levels above them. For example under Pipeline Creation you have Demand Generation and Lead Development.
A typical dashboard tree doesn’t go beyond L3/L4 at the most.
The beauty of the dashboard tree is that it reveals knowledge through structure, so over time it becomes a living document for how the business works. It shows how value flows in the organization.
For Flexport, the dashboard tree ended up becoming the SSOT (single source of truth) for the entire business. It enabled everyone to have a cohesive view of the business while facilitating synthesis and filling those gaps in mental models.
By limiting the number of dashboards and the number of metrics inside each dashboard to 15-25 they dramatically reduced dashboard sprawl by 97%.
So what goes inside each dashboard? How are they structured?
For that you’ll have to wait for the next issue.
If you enjoyed this newsletter leave a like and maybe a comment on the post. If you want to be private, feel free to reply directly. I read all my emails.
Until then.
The dashboard tree ideas is neat, but I think the bigger idea is the fusion of ToC ideas with the different dashboard levels, i.e goal, then CSFs then NCs. Very cool.
It sounds like there might be a homomorphism, although that might not be exactly the right concept, between the mental model of how the business works and/or a current reality tree. Need to think about this some more.
When I was trying to build dashboards it was obvious when you were mixing metrics at different levels and it doesn't feel right. It’s very much like programming - try to avoid mixing layers where possible.
This is very interesting and unique content, although I don't focus on that part, my fellow team does but this approach is great.