Part 2: Building Data Literate Teams with Tableau – Building the Dream Team

So now that we know data literacy goes beyond the chart, what comes next? We need people for our team to take our organization to the next level. And with that…

Presenting the Dream Team

Often, when we recruit for data roles, our demands map to it someone who can do it all – you know, a full stack data developer or whatever fun title we want to pick.

The job descriptions usually go for miles, but the crux of it is this person should be able to do everything. They should manage databases, write SQL code, create masterpieces in Alteryx, and yes, make rock-solid amazing dashboards.

Congratulations! You selected a unicorn. Unicorns are awesome when you can find them, but being rare creatures, their diets are rather expensive. They also want you to buy them new toys frequently to manage the time that no longer exists.

And therein lies the problem on building a data literate team from an army of one. One not only gets tired, but often has to make concessions. Something tends to suffer, and that might be defining or the steps after it. The inputs get tend to get ignored, either by organizational design or lack of time. You’re usually left with one very tired unicorn.

But wait, there is a better way, and it starts with a lorax!

The Dream Team: Take 2

Somewhere in your organization is someone very pesky about information. They usually find errors, or tell you no when everyone says yes. They champion endlessly for a better way or plead with you to invest more in reporting. Here’s a secret about that person: these “loraxes” are usually excellent as part of a data literate Center of Excellence (CoE). And ideally, you find at least two of them.

Within a CoE, analysts or ambassadors handle what often becomes the front end – the dashboards, but also some of the data source definition. They have insight into the inputs and can work with another person to pull in the appropriate data. This covers the analyst part, but what about the ambassador part?

Ideally, this is the person you send to train your users. They understand the data, can phrase it in business-centric terms, and can help guide where a field from the input lives in the dashboard or data source. This is where that annotation is key.

But they don’t work alone.

Data stewards often work with the backend data. They architect warehouses, data lakes, and help organize the data by preparing it into tidy established data sources. They, too, understand the inputs and compile mapping documentation, either separate or directly in Tableau. Data lineage is hot right now, and with good reason: we’re often working with a myriad of data sources and being able to trace data back is critical.

Data stewards may also be part of IT and support server. They might manage upgrades and keep an eye on performance. They may support dashboard development by providing QA. They’ll also optimize data sources for Ask Data and ensure people ask the right data source appropriate questions.

This is your basic, 2-person team. Ideally, you have more and they may cover smaller parts or overlap in different areas (such as an analyst expanding into data prep). CoEs are best designed like a bespoke suit, and not a one-size-fits all t-shirt (that is NOT unisex BTW).

Including Your Users

There are a number of paradigms on how to manage your users. We can plot these on 2 axes: how the data is exposed and who gets to analyze data. Data guardians do just that: they protect the data and limit who can access it. On the extreme end, only one person may be able to access the data and make sources. You’ll notice how far traditional BI lands on this metric. On the opposite, data stewards work with others to make data (appropriately) accessible, which may include certifying sources of record, but potentially allowing access to other data or creation of ad hoc sources. Think of guardians as saying “none shall pass”, while stewards work to sort out what can potentially be accessible.

On the other axis, we look at who is allowed to connect to said data and analyze it. On the extreme end, we limit creation of dashboards to an elite few. This happens when data is used as software – the word “portal” is often involved and the data (or shaping of data) is often proprietary and sold in some manner. On the other (extreme) end, we have a data democracy, Tableau’s preferred paradigm. This is where that Ambassador comes into play, as they support this user base far differently.

Take a look at how some of these play out as users in our models.

Users in a traditional BI rollout have a small footprint in our model. They’re often working in some way with our inputs, either directly adding data or accountable to something within the data. They may get to access the output and have a small amount of imput in the defining process, but are rely on others to perform the analysis. You often find the overall graphicacy also appears lower in these spaces, as most users end up trying to export the data to do their own lay analysis in Excel.

Compare this to a data democracy:

You’ll notice the footprint is much larger. I’m still keeping my users out of the storage and modelling piece. They have some role in supporting definitions, but ideally, they’re accessing data that has been defined and clarified for them. They’re supported throughout by my analyst/ambassador who can mentor and guide them on matters of accuracy, graphicacy, and effective analysis.

A data democracy relies on an education population. It means training, support, and a ton more management, but it also allows domain experts to quickly understand their data.

Want to learn more?

Fi Gordon is famous for Gamifying her CoE and how analysts level up Tableau fluency and overall graphicacy.

Mark Wu helps fellow data stewards scale their enterprise deployments.