Executive Summary
You’ve spent a good deal of money on a BI tool and formal training, but your teams still export everything to Excel and trust their own spreadsheets more than your dashboards.
It’s not just about the wasted licence fees. It slows down decisions, leads to conflicting reports, and demoralises a data team that ends up acting as a helpdesk for a tool nobody is using.
The answer isn't another generic training course. It's a change in approach. Stop teaching tools with dummy data and start building solutions to real problems, together, using the team's own messy data. This way, people build both trust in the data and the skills to use it.
Why classroom training with dummy data falls short
It’s a familiar scene for many Heads of Data. You spend a lot of money on a tool like Looker or Power BI. You hire good engineers to build a data warehouse. Then, to get people to use it, you buy a two-day training course for the commercial teams. The trainer walks them through the 'Superstore' dataset, everyone gets a certificate, and for a week or so, all seems well.
Then the email arrives: "Hi, can you just export the underlying data for this dashboard to a CSV for me?"
This isn't the user's fault. In my experience, it’s a flaw in the approach. We've come to think that data literacy is a skill acquired in a classroom, but it isn't. It's a behaviour learned through relevance and trust. Generic training often fails because it has no context. The marketing team doesn't care about fictional sales in a fictional superstore; they care about why their campaign CPA is broken right now.
Why people go back to their spreadsheets
I’ve seen this happen at a number of scale-ups. They have a great Modern Data Stack, but very few people are using it. The problem usually isn't the technology. You've likely moved to the cloud and hired good engineers. But if the underlying processes are messy, you may have just found a way to automate that mess.
The main problem is that classroom training teaches people which buttons to press, but it doesn't build their confidence. When someone sees a number in a dashboard that they can't trace back to their own work, they will almost always go back to the spreadsheet they know and control. This is why poor BI Adoption is really a trust issue, not a tool or skill issue. You haven't connected the data to their day-to-day work.
A different approach: treating training as a product
To fix this, it helps to think less like a teacher and more like a product manager. If your 'product' is better decision-making, your users are the commercial teams. The training, then, is the onboarding for that product, and it needs to be relevant from the very first minute.
I've used this approach to train over 100 people in various business teams, and the key seems to be quite simple: use their own data, their own reports, and their own problems.
First, understand their current workflow
Instead of starting with a finished dashboard, I find it's better to start by asking the Marketing Manager, "Show me the Google Sheet you can't live without." Sit with them and map out how they currently answer their most important questions. You'll often find complex, manual steps that are holding everything together.
This discovery work is the foundation. It shows you respect their current process and it reveals the actual business logic you'll need to build on. This is the first step towards building a proper Data Culture, one based on curiosity rather than compliance.
Next, rebuild it together with their real data
Once you understand their workflow, you rebuild it with them in the BI tool. Not a sanitised version, but the real thing. Use the same campaign names, the same product codes, the same messy data they deal with every day. When they see a number in Looker and can say, "I know that number, that was from the bank holiday sale," the tool stops being an abstract bit of software and becomes something genuinely useful.
This is where paying close attention to Dashboard UX is essential. If the tool is even slightly harder to use than their spreadsheet, they'll go back to what they know. The goal is to make the governed, automated way the easiest way.
Finally, find and empower a champion in each team
The goal isn't to train everyone. That's not practical. The goal is to find the 'data-curious' person in each department and help them become the local expert. This is usually the person who already builds the complex spreadsheets, the one everyone goes to for numbers.
Invest your time in this person. By empowering them, you create a support system that can grow. They become the first port of call, translating business questions into data questions for their colleagues. In my experience, this is a much more sustainable way to achieve proper Self-serve Analytics.
Acknowledging the challenges
Let's be honest, this approach isn't a quick fix. It doesn't look efficient on paper, and you certainly can't train 50 people in a week this way. It asks the data team to develop skills in communication and understanding business processes, which can be a change.
You might also find that department heads are reluctant to give up their spreadsheets, as it can feel like a loss of control. This is a challenge of persuasion, not technology. You have to show that this new way is not just more accurate, but ultimately easier and faster for their team.
But the payoff can be significant. Your team stops being a helpdesk that just sends out CSV files. The queue of ad-hoc requests gets smaller, the questions you get from the business get better, and you finally start to see a return on that expensive BI tool. You move from patching reports to helping the business make better decisions.