Hire Tableau Developers

Tableau earns its place where analysts need to explore rather than read, and where the visual grammar of the tool genuinely helps someone find a pattern they were not looking for. Its weakness is the same as its strength - workbooks multiply, extracts drift, and nobody can say which version the board saw last quarter.

Almost every wrong number in a Tableau workbook is an order-of-operations problem, not an arithmetic one. Filters, level-of-detail expressions and table calculations are applied in a fixed sequence, and a calculation that looks correct in isolation produces a different answer depending on where in that sequence it lands.

The two calculation families, and the one people get backwards

Level-of-detail expressions are computed in the database, at a granularity you specify, before the view aggregates anything. Table calculations are computed afterwards, on the result that came back, and they depend on how the view is laid out.

The consequence that surprises people every time: a fixed level-of-detail expression is not affected by an ordinary dimension filter. Someone filters to one region, the number does not move, and the report is declared broken. It is behaving exactly as specified — the filter has to be added to context to apply before the expression is evaluated.

Getting this right is the difference between a workbook that survives being filtered by people who did not build it and one that quietly misinforms them.

What actually makes a dashboard slow

Rarely the visualisation. Four causes cover most of it: too many marks for the question being asked; filters set to show only relevant values, which each fire their own query; custom SQL that prevents the tool from optimising anything around it; and a data source built by joining wide tables together so every query drags columns nobody displays.

The method matters more than the list. Run the performance recorder, take the slowest query it names, run that query directly against the database, and decide whether the fix belongs in the workbook or upstream. The most reliable Tableau performance fix is to stop doing the work in Tableau — push aggregation, joins and heavy calculations into a view or a model in the warehouse and let the tool visualise something already shaped for it.

Extracts, and the governance problem they create

Extracts are a genuine performance feature and the main reason estates lose track of themselves. A workbook with its own extract is a private copy of the data, on its own refresh schedule, with its own definitions — and it will diverge from the certified source without anything alerting anyone.

The pattern that works is a small number of published, certified data sources that workbooks connect to, rather than every workbook bringing its own. Consolidating an estate down to that is unglamorous work and it is usually the highest-value thing a good Tableau developer does in their first quarter.

Where Tableau is the wrong choice

Where the requirement is a fixed, pixel-precise operational document — a statement, an invoice, a regulatory return. This is an exploration tool being asked to be a report writer, and it is bad at it in ways that consume weeks.

Where the audience will only ever read one number. Where the licensing cost per reader outweighs the value of interactivity for a large, occasional audience. And where the underlying data is not modelled: the tool will let you blend your way past that for a while, and blending is a workaround being used as an architecture.

On migrating between BI tools

We maintain a small utility that reads a Tableau workbook’s definition and emits the equivalent structure for another vendor’s tool, and the most useful thing it taught us is where automation ends. Connections, fields and layout translate mechanically. Calculations do not: level-of-detail and table calculations have equivalents elsewhere, but which equivalent is correct depends on the target model, so each one needs a person.

Budget a BI migration as a modelling project with a conversion step in the middle, not as a conversion project. The estates that go badly are the ones that assumed the reverse.

What we interview for

Ask about performance and about consolidation. What made a slow dashboard slow and how they proved it, how they reduced two hundred workbooks to twenty, and when they pushed logic back into the database rather than solving it with a table calculation. Developers with production experience answer in query plans and extract sizes. The rest show you a portfolio.

Then the diagnostic: a user filters the dashboard and one number does not change. What are the three things you check, and in what order.