Having been part of the recent layoff, I’ve found myself interviewing extensively with a wide array of companies--for various types of data roles. I’ve been quite lucky with the responses and level of interest I’ve received from various companies. In doing so, I’ve been asked a lot of similar questions and often found myself talking about some of my philosophies (read: opinions) on data teams, communication, and general data culture within an organization. Effectively, it all boils down to one philosophy you’ll see repeated throughout: keep it simple.
There is a consistent interest at companies to “form a data culture” within the company and to be “data driven” throughout the organization. If I had a dollar for everytime a heard a company talk about wanting to be data driven in interviews, I may not even need a job! “Data driven” has become a buzz-word bordering on cliche if you ask me - but it is an important company value to get right.
The common challenge companies run into here is they hire a stellar data team, build out all their data infrastructure and pipelines, and use some combination of the shiny new data tools, but adoption outside of the core data team ends up being limited.
I believe the reasons that data isn’t permeated through the company is often misunderstood. My experience says it tends to fall around these 2 ideas:
There is not sufficient training on data structure and data tools throughout the organization. Many of these tools will be new to users not familiar with data stacks, and it’s only natural for folks to be intimidated by something new.
You are thinking of your data and BI tool as an output that the rest of the company will simply use or ingest, when in fact you need to be thinking about the data as a stand alone product with a positive user experience.
Training
For most companies today, the primary way that the business will (hopefully) interact with the data is through the chosen BI tool. (I say hopefully, because it’s still very common to see the business using an array of spreadsheets to track and interact with data.) With that in mind, it’s important to remember that many non-data folks have never interacted with a Tableau or Looker-type of tool before. It’s only natural that they’re going to be intimidated by a new tool, especially when you don’t know where to start. Training may not be the sexiest part of a data job, but it may be one of the most important.
In every company I’ve worked at, I’ve been surrounded by smart people, and if you’re like me, sometimes smart people worry about asking a dumb question. They may be embarrassed to admit they don’t even know how to start. That’s why I’ve found it’s so important to truly start with the fundamentals when trying to get adoption of a BI tool throughout a company. Once someone understands the basics of the tools, they tend to be more willing to branch out and start experimenting with capabilities on their own.
During a previous role, I ended up creating a structured, internal training for Looker (our BI tool) and running regular training sessions, primarily for new hires. In the training sessions, I took the principles laid out above and constantly strove to be approachable and encourage as many questions as possible. I wanted the training to be hands-on to the point that everyone had made at least a basic visual or table from the tool.
In addition to the tools themselves, I spent time going over the structure of common tables that business users would likely be accessing. Even if someone has never heard of a primary key before, it’s an easy enough concept to explain, so they understand what level of granularity exists within a table.
The last important item to cover is definitions of data fields. This sounds so fundamental, but I have seen cases time and time again, at every level of an organization, where there is not a mutual understanding of key terms. If you don’t have some form of data dictionary or terms glossary at your company, this really highlights the need for one. Having somewhere to point to the mutually agreed-upon definitions will save a lot of headache. And this doesn’t need to be a fancy tool; it could be a Wiki/Confluence page on the company intranet, or even just a Google Sheet that can be referenced.
My last thought on data training is this: the demand for training within an organization can be an important indicator for how well the data culture is permeating. In other words, if there is no internal demand for trainings, or if there are no questions being asked about the tools, this is a potential red flag that the adoption of data throughout the company is low. Trust me, if people are using your tools, there will inevitably be questions.
Data Product vs. Data Output
Data teams have a wide spectrum of work and responsibilities; from selecting the database and tools to use, to managing data flow from internal and external sources, to building out the tables themselves that will be the basis for analytics and reports. Despite all of this work, the rest of the company really only sees a small part of that - the data output, usually in the form of dashboards.
The error that’s made is one around the mindset. The way I often see data treated is akin to leaving out food for your dog: you put your output in a bowl and wait for the rest of the company to come consume it. This works for your dog, because let’s face it, dogs love food and they’re seemingly always hungry. But the same hunger doesn’t always exist for data to be consumed consistently throughout an organization. Data isn’t just an output, it’s a product!
Instead, you should think of your data product as fine dining in a restaurant. Your company has paid a lot to be there, between all the expensive data tools and the (well earned) salaries of the data personnel at your company. Therefore you can’t just leave the data out, thrown carelessly into a bowl to be consumed. You need to spend time on the presentation of data. The ambiance needs to be right. It needs to be easy to find the data and a pleasure to consume it.
Okay, perhaps I’ve stretched the dog food/restaurant analogy a bit far, but hopefully you get the point! If you’re not taking the extra effort to make sure your BI site is clean, folder structures / files are easy to find, naming conventions are intuitive, and the structure of the tables and dashboards are easily digestible, then there’s a good chance that the rest of the company won’t fully adopt and utilize all of the work the data team has done along the way. In a nutshell, you’ve done all the hard ground work to build and organize the data at your company, so take the last step and make sure your data product is easy to use and gives stakeholders a positive experience.