Please Don't Treat Power BI As A Pane Of Glass

Introduction

In cricket you have someone who delivers the ball ("bowler"), someone who hits the ball ("batter") and someone who can do both well ("all-rounder").

Cricket teams are usually made up of 11 players consisting of a number of batters to score runs, a number of bowlers to get the opposition batters out and one or two all-rounders who can contribute in either way as the team requires. In other words teams are strongest when specialists perform their roles and the all-rounders are used flexibly in whatever way is needed.

The Current Approach

This is how I believe a good data team should operate too. But too often teams expect everyone to be full stack and be equally comfortable in both the back end and front end worlds.

This works well in a software development team as there is overlap in the skills, languages and approach. But I would argue that, in a data team, the gap between front end and back end is wider.

Often the visualisation layer is treated as a window pane over the database or datawarehouse. And so it is believed that most, if not all, of the work must be done in the backend in SQL and then presented in the visualisation layer. This may be true if using Tableau or Qlik which don't have a semantic model but this approach really takes away the power from Power BI.

I would suggest the skills that make you a good back end developer or data engineer: the ability to create ETL pipelines, think linearly and move data in a rigid repetitive style are complementary but distinct to the skills that make you a very good Power BI developer. The backend engineer optimises for data integrity and performance and the front-end craftsperson optimises for user understanding and decision-making speed.

What Power BI Mastery Looks Like to Most

In many organisations, Power BI is often seen as a visualisation layer on top of a SQL database. This perspective, while not entirely wrong, underestimates the power of the semantic model and the flexibility of the tool. Many organisations believe that any complex logic and calculation should be moved upstream to SQL. And then Power BI is about creating visuals using drag-and-drop to highlight these calculations.

It's easy to underestimate the semantic model if you're used to having SQL-first tools like Tableau or Qlik. Following best practice especially when it comes to naming conventions and reuse is also extremely important in the backend but not necessarily so or at least not in the same form in the front end.

Don't get me wrong all of these things are important however they are thoughts from people who originated in the SQL world. The visualisation layer is often more flexible and forgiving than a strict SQL-first approach allows for. The trick is knowing what is available and knowing when to follow best practice and when not.

What My Growth Looked Like Instead

My journey was different. I started with Microsoft Excel. One of the most flexible pieces of software ever!! You start with an empty grid which is metaphorically a blank piece of paper. And it's up to you how you populate it and create your work: Excel formulae? Pivot Tables? Power Query? VBA? This taught me that there are multiple ways to solve a problem and which one I used depended on the type of problem I was solving.

Through experience, I built a good understanding of the advantages and disadvantages of each approach. This allowed me to ask good questions to stakeholders ahead of time so I would know which approach would be most suitable for the task at hand.

Alongside this Excel upbringing, like everybody else I have used systems and apps that were clunky, unintuitive or just plain slow. These things matter to me and I bring this with me in my approach:

• Is it obvious what the user should do here?
• Do the pages of the report and the visualisations flow from one to another?
• Does it look good and do user elements like buttons and slicers react as the user would expect?
• Does everything update quickly when changed?

To achieve this sometimes rules need to be bent. And I'm now not afraid to be pragmatic rather than dogmatic about it.

1) Custom Visual

For example, I once needed to show performance vs target in a clear, intuitive way. The standard visuals weren’t cutting it: too clunky, too confusing for the audience, too dull.

So instead I built a unit dial chart in Deneb (Vega). It broke the “use native visuals first” best-practice rule, but it massively improved usability. The users instantly got it and that’s what mattered.

2) Writing DAX

My DAX writing starts from a position of what is this metric supposed to show? How would I, as the end user, interpret what this is showing me?

I then write it in pseudo-code so I understand, in English, what it should be. This then makes the writing of the actual calculation that bit easier.

3) Calculated Column

If I need a calculated column, I will use one. I will think long and hard but if I can't find another way, a calculated column is the way forward.

The semantic model allows for flexibility and creativity. This ability to be less rigid means that problems can be solved quicker by using a more creative solution.

4) Calculated Table

Another case was when we needed to understand subscription behaviour over time. Rather than building complex upstream SQL pipelines, I created a calculated DAX table — a “subscription runner” that generated a row for every active day across all subscriptions. That unlocked all sorts of time-based metrics we couldn’t easily do otherwise, and it was delivered in a fraction of the time.

What I've Gained From This Approach

First and foremost I have confidence that the problem can be solved. I might not have a well-thought out solution in the moment but through my experience I will have a couple of approaches that I can delve deeper into.

Put The End User First

The feedback loop in Power BI is fast. This means I can try out several potential solutions quickly. If the result is wrong or the visual loads slowly or I spot another issue, I go back to the drawing board and think of a better solution. This approach is naturally iterative and because I hold myself accountable, I won't rest until a solution is found that I, as the end user, would be happy with.

The Power of a Proof of Concept

I find building proofs of concept and sketching out possible solutions strengthens the team and influences decision-making. Rather than talking in circles about what might or might not be possible or useful to see, putting a PoC in front of the decision-makers is far more powerful.

This helps the stakeholders understand much more clearly what is coming and why. And so they feel invested in the report when it finally lands and are therefore more likely to use it.

Flexibility

The flexibility that Power BI provides gives me a sense of craftsmanship. I could use Power Query for this, I could use DAX, I could use a native or a custom visual. I could use a trick to create that effect in the canvas. I could use this colour scheme or this one. So many different options at my fingertips and I love it!

Summary

I wouldn't pick a team of 11 batters. Equally I wouldn't select 11 all-rounders or bowlers. A strong team is made up of people with a different mix of skills who are given the latitude to flourish in their chosen discipline.

To me, the skills required to be good at SQL data engineering are complementary but different to the skills required to be good at Power BI developing. One requires a certain discipline and rigidity while the other is all about creativity and flexibility. And yet still lots of organisations push for "full stack".

I get it, some of this is coverage. The whole "what if someone gets hit by a bus?" and there is merit in that. However to me, coverage can very easily lead to mediocrity: People doing work they don't find fulfilling and so don't excel at just in case their colleague gets hit by a bus.

And, let's be honest, how many of our colleagues have been hit by a bus?

Whereas the opposite approach: allowing people to flourish in the part of the stack that they resonate in leads to excellence. Excellence for the team, excellence for the product and excellence for the individual.

• Specialists deliver higher quality in quicker time with less bugs.
• Specialists raise the bar and knowledge spreads through the team by osmosis.
• Round pegs in round holes leads to a happier workforce and therefore less churn.

The goal shouldn't be team coverage. The goal should be creating a brilliant product that users can trust and enjoy working with. And that only comes when specialists are freed to do their best work.