Executive Summary
Your analytics engineers have built a lovely dbt project, but people in the business still seem to prefer their own spreadsheets.
You're spending a good deal of money on a data stack that isn't changing how people work. Your team risks being seen as a cost centre, and important decisions are still being made in spreadsheets no one can quite trace.
The problem isn't usually in the dbt code itself. It's in the gap between the data warehouse and the person looking at the dashboard. The fix is to think about the structure: putting in a governed Semantic Layer and carefully curating your reports, treating them as a product.
Why good dbt models don't always lead to trusted dashboards
You’ve done everything right. You hired smart analytics engineers. You invested in Snowflake and dbt. Your dbt project is a thing of real craft: modular, tested, and documented. Yet, during the weekly trading meeting, the Head of Sales presents a chart from a spreadsheet because they don't believe the numbers in your Looker dashboard.
This is a scenario I come across quite often in scale-ups. The leadership was sold the idea of the Modern Data Stack, but the reality can feel like an expensive, digital version of the same old chaos. It turns out you haven't created a Single Source of Truth, you've just found a faster way to have the same arguments. The belief that technical excellence in the warehouse will automatically create trust in the business seems to be where things come apart.
The gap between the warehouse and the dashboard
Your dbt models can be perfect, but they exist at a level of abstraction that's quite far from your business users. They live in the BI tool, and there's an unmanaged space between the two. This is where clear business logic can get fuzzy, turning into a hundred slightly different SQL queries written by a dozen different people.
This gap tends to create a few common problems:
In the end, this isn't really a technology problem. It's a failure of architecture, and it's what creates deep Data Trust Issues and gets in the way of proper BI Adoption.
How to fix the problem by curating what users see
As a Head of Data, your most useful tool isn't always approving the next dbt model. Sometimes, it's saying 'no' to the next dashboard request. The fix is often to stop building more things and start curating what you already have. It's about applying some product management thinking to your internal data work.
1. Define metrics in a semantic layer: This, in my view, is the most important step. Whether it's in LookML, Lightdash, or a dedicated metrics store, this is where you define business logic once. The definition of 'Net Revenue' should exist in one place, be version-controlled, and be owned by Finance. This bit of 'political engineering' can stop the debates before they even start.
2. Appoint someone to look after reporting: Your team might be full of engineers who love building data pipelines. It's worth finding someone who can focus on that 'last mile'. Someone who treats the main C-Level dashboard with the same care as your public-facing app. Their job is to consolidate, not create. To reduce 200 dashboards to 20 that are trusted and used daily.
3. Introduce some light governance: This isn't about bureaucracy, it's about guardrails. A simple rule: no metric enters a core dashboard without a clear owner and a definition documented in a shared space like Confluence. This helps stop the spread of 'vanity metrics' and makes sure every number on a main report is defensible. It's also a practical way to ease the Data Engineering Bottleneck that comes from endless requests to validate slightly different numbers.
Why this is more about people than technology
Let's be honest. Doing this can be difficult, not because the technology is complex, but because it involves navigating the organisation. You will have to tell department heads that their pet dashboards are being retired. You might have to get the CRO and CFO in a room to agree on a single ARR Calculation. This isn't always a comfortable meeting.
Your job is to frame this not as taking something away, but as providing 'decision insurance'. A curated, governed dashboard helps the CEO avoid awkward questions in a board meeting. It ensures that when you press 'go' on a multi-million-pound marketing campaign, the data you're using is sound.
Moving from a 'dashboard factory' to a more curated approach is a shift in culture. It means acting less like a service desk and more like an architect for the company's decisions. The work becomes less about writing code and more about building agreement. It's the less glamorous, difficult work that, in my experience, is what actually builds a data-driven culture.