Beyond the Dashboard

Or: how I learned to stop worrying and love Excel

While in one corner of the internet, the programming subreddits feel the impending doom of generative AI, on another, quieter corner, a slack notification pops up, dragging our hero out from their deep work.

“How do I export the data to Excel?”

Our hero sighs, having heard this question multiple times a day, every single day, since they started their data journey. They muster up their strength and respond, attaching a screenshot with an arrow pointing where to click. The stakeholder is happy with the prompt answer, and our hero goes back to looking for a missing comma.

---

I’m sure this situation will strike a chord with data practitioners sandwiched between analytics teams and stakeholders. For years I tried to fight Excel, provide users with more and more flexibility in dashboards and reports, and train them to build their own. Many of those initiatives were hugely successful, and many failed miserably. But no matter how much I tried, I never managed to beat Excel at its own game. Sooner or later, the dreaded question would pop up.

Self-service analytics is deemed to be this holy grail that all teams strive towards. If we can empower our users, we say, we’ll have more time to do work that significantly moves the needle. We’ll receive less tickets, think more deeply about problems, and build better data models.

Despite that, I’ve often fought with both teams and data governance practices that, though they meant well, explicitly prevented people from exporting the underlying dataset in a dashboard. Despite touting self-service as this ultimate goal, I saw an unwillingness to embrace tools that their users already knew.

“Self-service” is notoriously hard to pin down because there is no one definition that’s applicable to all users.

For me and most other engineers, getting access to unstructured data, loosely documented, living in between file systems and APIs, will already mean we can self-serve and extract insights, even if it takes a while.

On the other end of the spectrum, I’ve had users whose technical abilities only went as far as selecting from drop-down filters in dashboards.

And in between those extremes lies the vast majority of users. No matter their department, technical proficiency, or scope of their work, what unites them is that they know and have worked with Excel from the day they stepped foot in the first corporate office.

If our goal as a data team is to empower users, I say we’re doing ourselves a disservice by not embracing the dreaded Excel export. Yes, we should work to remove Excel bridges in data processing, we should write code that’s tested, with business logic that’s well documented and doesn’t live in someone’s head, we should do our best to take the data from the sources as far as we can, exposing it cleanly and securely to as many users as possible.

And we absolutely should train our users, we absolutely should build models that are flexible enough to support a wide range of use cases.

But we should also be realistic and recognize that the person who asks the question is usually the one who’s best equipped to answer it, and we should cater to them. If they want to wrangle our model further in Excel, I say we should encourage it and meet our users where they are.