Should I Hire a Tableau Developer? Answer These Three Questions First

---

Tableau is a popular tool. It's cost-effective, easy-to-learn, and makes data viz and reporting look sexy.

More and more companies are investing in Tableau as well. From 2015 until its purchase by Salesforce, Tableau's revenue grew approximately 77%.

It also has a huge following among data professionals. Tableau User Groups – once small niche events – are filled with individuals who not only see Tableau as a job skill, but an outright hobby.

This excitement and growing talent base has led many employers to ask themselves – should I hire a tableau developer?

Well, just like most questions in data science, the answer is a solid “it depends.” You need to answer three key questions before you invest in a tableau developer.

Question #1: Is Your Team Ready for Role Specialization?

I write in my upcoming book, How to Manage a Successful Data Team, that many companies don't consider work volume before determining roles. They'll hire too many specialists when they really need more generalists.

A generalist is someone who is the “jack-of-all-trades” but “master-of-none.” They do little web analytics, database development, and Tableau development, but they won't excel in one area. They'll usually have a generic job title, such as analyst or BI developer.

A specialist includes roles such as web analyst, data engineer, database developer, and tableau developer. As you can imagine, the specialists will be really good at their skill set, but weak in other areas.

Many companies early in their data analytics journey hire too many specialists or the wrong kinds of specialists. That’s particularly true of tableau developers.

For example, a team may be early in their data analytics practice. They don't have any tracking or databases built. Their end goal is to build automated dashboards. So they decide to hire a web tracking developer, a database developer, and a tableau developer at the beginning.

The problem is that tableau development can't start until the other two roles finish their work first. Until the tableau developer has the web tracking system built and the data is extracted to a database, there's not much they can do.

A tableau developer's salary ranges anywhere from $60k to 90k a year. So that's a huge waste of money to pay someone to wait on standby.

In this scenario, I suggest cross training your existing employees on Tableau. It'll be cheaper and more efficient than creating a separate role. Once your team's volume increases and you have weekly requests for Tableau dashboards, you can create a specialized role.

The other option is to hire a tableau contractor or freelancer. Someone who can build your dashboards only when you’re ready for them.

Question #2: Do You Have Good Data Quality?

Many executives don't realize how many data quality issues they must fix before they invest in Tableau. That's because their existing reports are manually compiled, often in PowerPoint and Excel spreadsheets. The analysts who build these manual reports cleanse the data quality issues before any executive or stakeholder ever sees them, which means the executives don't even know they exist.

These data quality issues become a challenge to fix when you automate these reports using Tableau. Whenever you build an automated report, the data quality issues are automated with it. That means the analyst can no longer fix the data quality issues with a scalable solution. This issue will become even larger as more data funnels into the dashboards.

This often leads to a backlash against the automated Tableau dashboards. Since many key stakeholders start to notice data quality issues in their reporting, they blame Tableau and the reporting team. That’s ironic because the data quality issues usually begin way earlier in the data journey, but they're only noticed in the reports since those are the most visible platform to stakeholders.

There's little the tableau developer can do to fix these issues. Most data quality issues are caused by operational failures. That means the data is ruined before it even reaches the dashboard. There's only so many case statements a tableau developer can write before you lose the benefits of Tableau.

For that reason, you must fix any processes that impact data quality before automating reports with Tableau. Otherwise, it's a waste of effort once the stakeholders catch on to the inaccuracies.

Question #3: Are You Using Tableau As a Substitute For Real Analysis?

The last big question you should ask yourself is whether you’re using Tableau for the right purposes. More specifically, are you using it for report automation or as a substitute for real analysis?

Almost every sane stakeholder out there will tell you that they want insights from their data. Sadly, there’s a limit to what Tableau can deliver here. Tableau does free up the analysts time by automating redundant KPI reports, but it does not replace other analysis tools, such as R and Excel.

Unfortunately, this benefit is often lost on companies that invest in Tableau. They'll focus too much on building a dashboard to answer every possible business question a stakeholder may ask.

I call this the “reporting trap” and you can read about how to escape it here.

What companies really need to do is automate simpler reports with Tableau. They can then devote time to good old fashioned analysis projects – one with a real business question or a hypothesis to test.

However, don't assume a tableau specialist can deliver these traditional analysis projects. The tools and skills of a data analyst (or scientist) include statistics, R or Python, SQL, Excel, and some presentation skills. Many tableau specialists simply don't have these skills.

Don't get me wrong, I think Tableau is a handy add-on skill for data analysts. Analysts can use the data visualizations in Tableau to tell a story to the stakeholder and help make insights more understandable, but it's not the most important skill for a data analyst.