A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
When a dashboard is slow, wrong, or impossible to change, the tool almost never turns out to be the cause.
The cause is usually one wide flat table. Somebody exported data, joined everything into a single sheet, and imported it. It worked at first. Then filters started behaving oddly, totals stopped matching detail rows, and the file grew until refresh took twenty minutes. Every fix makes the next one harder, because the structure the engine is designed for was never there.
Power BI and Tableau are both built around a dimensional model — facts in the middle, dimensions around them, relationships defined once. Given that, they are fast and the calculations are simple. Given a flat table, you spend your life writing expressions that undo the shape of your own data.
Which is why "we need someone who knows Power BI" is the wrong brief. Plenty of people know Power BI. The question is whether they can model, and that is a different skill people rarely advertise.
Almost every BI complaint we are asked to solve turns out to be a modelling problem.
Star schemas, relationship cardinality, and why one wide flat table causes most of the problems people blame on the tool.
Filter context in Power BI, level-of-detail expressions in Tableau. The hardest part of either tool and the best discriminator.
Import versus live connection, incremental refresh, and calculations that hold up against production data rather than a sample.
Row-level security that works with your relationships instead of against them. Frequently retrofitted badly and hard to correct later.
Whether they will tell a stakeholder that a request is a question rather than a dashboard. Sprawl is a discipline problem.
A live conversation in English, every time. This role sits directly with business users and translation is most of the job.
Bad BI does not fail loudly. It gets quietly abandoned, and everybody goes back to spreadsheets.
The usual sequence starts with a report that is nearly right. A total is slightly off, so somebody exports it to Excel and corrects it by hand. That export becomes the version circulated to the leadership team. Now the dashboard exists, is maintained, and is not the source of truth — and the maintenance cost continues while the value has already gone.
Performance failures arrive on the same path. A model without a proper star schema forces calculations to do work at query time that the engine could have done once. On a developer machine with a sample it is instant. Against production volume, a page takes thirty seconds, users stop opening it, and the request that comes back is for a simpler dashboard rather than a faster model — so the wrong thing gets fixed.
Then there is sprawl. Without governance, every request becomes a new report. Two years on there are four hundred, nobody knows which are current, several contradict each other, and the number of them is itself the reason nobody trusts any. Cleaning that up is a political exercise as much as a technical one, because every obsolete report has somebody who asked for it.
Underneath all three is the same root: business logic living inside individual reports instead of in a shared model, so no two reports can be guaranteed to agree.
BI Developer (2–4 years). Builds reports against an existing model. Comfortable with visuals, filters and straightforward measures. Needs a model designed for them.
Senior BI Developer (4–7 years). Designs the model. Star schemas, relationship cardinality, row-level security, refresh strategy, and calculations that perform at volume rather than only produce the right answer.
BI Lead (7+ years). Owns the platform and its governance — workspace structure, certification, what gets retired — and works with the business on which questions are worth a dashboard at all.
Rebuilding a slow or distrusted report set. Usually a modelling job wearing a reporting brief.
New reporting on an existing warehouse. The straightforward case, and much easier when the modelling layer is already owned. See analytics engineers.
Migration between tools. Tableau to Power BI most often. The visuals are the easy half; the calculations and security model are not.
Governance and cleanup. Reducing four hundred reports to the thirty that matter. Slow, valuable, and rarely anybody internal wants to own it.
Embedded analytics. Reporting inside your own product, which brings security and multi-tenancy questions that standard internal BI does not.
Week one. They look at the model before the visuals, and they ask who actually opens each report. Usage statistics usually reveal that a small handful carry all the value and the rest are maintained out of habit. Expect a blunt account of the model structure and whether it is fit for what is being asked of it.
Weeks two to four. One report rebuilt properly on a corrected model, with a measurable improvement in refresh or render time, and calculations that are readable by the next person. Expect them to push back on at least one request as better answered by a different report that already exists.
The warning sign is a developer who only takes requests. BI attracts a queue of small asks, and it is possible to stay busy indefinitely servicing them while the underlying model gets worse. Somebody who never says "this belongs upstream" is managing a backlog rather than building anything durable.
Screening on visual polish. A portfolio of attractive dashboards tells you somebody has design sense. It says nothing about whether their model survives volume, or whether their calculations are correct in every filter context — which is where BI actually goes wrong.
Expecting BI to fix data quality. A dashboard reflects what is underneath it. If the warehouse is inconsistent, the report will be too, and the developer will be blamed for a problem one layer up. Fix the modelling layer, or hire for both and be clear about which is which.
Underestimating the calculation language. DAX in particular is genuinely difficult — filter context is not something you pick up in a fortnight, and expressions that look correct produce wrong totals in specific slicer combinations. Test a candidate on it. It is the most reliable discriminator in Power BI hiring.
Approving every report request. Most requests are a question, not a dashboard. Some deserve a one-off answer; some are already covered by something that exists. A BI function that builds everything asked of it produces sprawl nobody can navigate within two years.
Rates depend on platform, seniority, and engagement length. Tell us the role and we will give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.