Executive Summary
You're hiring expensive people for commercial roles, but they struggle to use your data tools. This often creates a bottleneck for your analytics team.
The risk is that you waste money on the new hire, your BI tools don't get used, and your data team ends up pulling CSVs instead of doing more valuable work.
The fix is to stop testing for proficiency with a specific tool, like Excel. Instead, interview for a trait I call 'process curiosity'. It's a change to how you hire, not just another technical test.
Why testing for Excel skills doesn't work
Let's be honest. Your current way of assessing data literacy in non-technical hires probably isn't working. You ask a candidate if they're proficient in Excel or Google Sheets. They say yes. You might even give them a spreadsheet test, asking them to do a VLOOKUP or build a pivot table. They pass. You hire them.
Six weeks later, they are sending Slack messages to the data team asking, "Can you just pull this into a CSV for me?" You have spent a good deal of money on a modern data stack, yet your new Head of Sales seems allergic to the dashboard you built for them. You haven't hired a data-literate person; you've hired someone who can follow a recipe.
In my experience, this is a common problem in scale-ups around the Series B to D stage. The business invests six figures in Looker, Tableau, or Power BI, but the commercial teams, hired for their contacts and confidence, don't use it. This isn't a user problem; it's a hiring problem. The problem, as I see it, is the reliance on Excel as a stand-in for analytical skill.
The problem with hiring for confidence over curiosity
The ability to use a spreadsheet shows that someone can follow a known process. It reveals very little about their ability to think critically when the process is new or the numbers look odd. What tends to happen is that you just end up automating a messy process, and hiring people who don't question it only makes things worse.
This can create a dependency. The commercial team doesn't trust the data because they don't understand the system that produces it. From what I've seen, this lack of Data Trust is one of the main reasons BI projects don't succeed. It's why your expensive dashboards gather dust. It's not a training issue; it's that you're hiring people who see data as an output, not an ingredient.
A hire in a key commercial role who isn't curious about data will cost you more than their salary. They can undermine your efforts to build a healthy Data Culture by asking for manual workarounds and encouraging distrust in the very systems you've built to help them.
A different way to interview
To fix this, you need to change the interview process. Stop asking about tools. Start testing for a certain mindset. The goal is to hire people who can contribute to a culture of Self-serve Analytics, not just consume reports. Here are three questions to replace the 'Excel test'.
#### Question 1: Ask them to map out a simple process
Give the candidate a simple, non-data-related business process on a whiteboard. For example: "A customer buys a product online, it's shipped from a warehouse, and they later return it. Can you draw me the steps? What information is created at each stage? Where could it go wrong?"
You are not testing for operational genius. You are testing for their ability to think in systems. Do they ask clarifying questions? Do they identify potential failure points? A data-literate person is naturally curious about the mechanics of the business. They want to know how the sausage is made.
#### Question 2: Ask them what's missing from a dashboard
Show them a simple, clean dashboard. It could be for a fictitious company. Say, "This is the sales dashboard for last month. What would you want to know that isn't on this page? What questions can't you answer?"
A less useful answer is, "It looks good," or "I'd want to export this." A more useful answer is, "I can see what we sold, but not who we sold it to. Can we see this by customer segment? I see revenue, but what about profit margin? How does this compare to the same period last year?" They are probing the data, looking for the blind spots. This is the core of critical thinking with data.
#### Question 3: Ask them to explain a metric they've used
Ask them: "Tell me about a Key Performance Indicator you relied on in your last role. Explain it to me as if I know nothing about your industry. Why was it important? How was it calculated? What were its flaws?"
This question can be very revealing. It tests their ability to communicate complex ideas simply. It shows if they just consumed a number or if they truly understood its construction and its limitations. Someone who can explain the nuance of a metric like 'Customer Lifetime Value' is far more valuable than someone who can just find it on a spreadsheet. This is a good sign that they'll contribute to successful BI Adoption.
A note on the practicalities
Implementing this isn't always easy. Your hiring managers are under pressure to fill roles quickly. They might tell you this slows things down. It helps to frame this as de-risking. The cost of a 30-minute extension to an interview is small compared to the 12-month cost of a bad hire who drains your data team and makes poor, data-blind decisions.
The long-term benefit
By changing your approach to hiring from 'tool proficiency' to 'process curiosity,' you build a different kind of organisation. You build a commercial team that is a partner to the data team, not a customer. They find insights on their own, they challenge assumptions, and they help you build a stronger, more resilient business. You stop buying tools and start building a culture.