Power BI Developer…..almost every role I see nowadays leads with the name Power BI Developer.
Leaving aside the fact that the term “Data Analyst” seems to have completely disappeared from roles where Power BI is to be used (although we will return to that later), Power BI Developer is an incredibly broad term.
There are a great number of aspects to providing insightful, business changing reporting through Power BI, many of which are completed away from the platform, and I’m beginning to think we’re asking far too much of just one person by labelling a job this way. Either that, or we’re looking for the oft impossible to find unicorns.
Power BI Developers are expected to create end-to-end analytical Business Intelligence solutions, call them dashboards if you will. And it should come as no surprise that these solutions are to be housed within Microsoft’s Power BI, a sprawling data analysis platform that allows for data connectivity, transformation, modelling and visualisation, has cloud infrastructure for sharing and many other bits of kit (such as Gateways) that should be owned by IT (whether they are or not is a conversation best saved for another provocative post).
When we begin to factor in the elements of the role which do not involve Power BI it’s not unusual that we’re asking Power BI Developers to:
- Engage with stakeholders and take requirements
- Understand the business, the data required, where to find it and to understand or create logic for the metrics
- Extract, transform and load the data using Power Query, SQL, Python or another language
- Understand the principles of data modelling
- Create, test and optimise a data model
- Build a design wireframe
- Understand the principles and fundamentals of DAX
- Use analytical techniques to provide insight
- Create and format visualisations that drive action
- Build an intuitive and friendly UI/UX
- Understand the intricacies of the Power BI Service and how to share content through it
- Have knowledge of Gateways, Capacities and their impact
- Use the XMLA endpoint to administer Semantic Models, analyse and debug issues, or undertake complex modelling scenarios
- Manage change and scope creep
- Present or communicate findings back to stakeholders
….and there’s probably a fair bit more outside of this.
Moreover, some of these one line bullets take years of experience to master. Take “Understand the principles and fundamentals of DAX” as an example. At the time of writing, I’ve been working with DAX for 6 years, and it’s only in the last 2 years I’ve begun to feel like I truly understand the fundamental concepts and how I can control them. That’s the level of learning that goes behind just one element of the Power BI Developer role.
Throw in the principles of data modelling, SQL or Power Query’s M Code, and some basic visual principles and we’re talking many more years before someone is at a level competent enough to ensure the solutions they create in Power BI provide value to a business, without causing any ripples in its BI infrastructure.
In my opinion, we’re asking people to gather unreasonable amounts of knowledge across too many disciplines just because they apply to one tool, and this can only lead to burnout, feelings of imposter syndrome or too many people that specialise in nothing.
We’re essentially asking people to be iPads.
With no specialists in certain topics (best practices as an example), we’ll be leaving leaving ourselves open to sub-optimal solutions damaging a platform or underdelivering on the analysis, ultimately leading to failure and disappointment.
Someone or something’s going to get hurt.
So, what do I propose we do about this?
Well, much like the seemingly old fashioned terms “Data Analyst” and “Data Engineer” where the differing responsibilities have been divvied up to create two specialisms, I think there’s a good case for splitting the “Power BI Developer” role in two, especially at enterprise level.
There will always be a need for elements of knowledge to cross over, mostly at a theoretical level, but I think similar responsibility splits to the ones that have been applied to Analyst and Engineer can be applied to two different Power BI roles.
Ladies and Gentlemen, if we must shoehorn Power BI into a job title, I present to you the:
“Power BI Analyst” & “Power BI Engineer”.
The table below shows how I imagine the responsibilities listed earlier being split or in fact shared (an important point I shall return to post table):
Now this to me seems a pretty even, fair and productive split of responsibilities. Over the course of a project it would allow two people to collaborate and knowledge share, with each being able to use and focus on getting the best out of their specialist subject areas.
Another bonus to this model, and returning to the subject of sharing, is the way it involves the “Power BI Engineer” earlier in the process. The eagle-eyed amongst you will have noticed that I’ve included them in the stakeholder engagement and requirements taking step. This is an opportunity I see missed far too often, with the analyst usually taking responsibility for this and the engineer hidden away in a cupboard somewhere. The problem with this generalised approach is that the analyst will occasionally take a load of requirements and make promises based on data that doesn’t exist, isn’t currently available, hasn’t been mapped properly or isn’t in the correct format. Following a conversation with the engineering team, where they’re told exactly these things, the Analyst will then have to return to the stakeholder, tail between their legs, and beg for forgiveness. So why don’t we just involve this team upfront, and save the world from this sorry dance.
Once the requirements are taken and outcomes agreed, the development or build phase allows each person to undertake tasks completely aligned to their skillset. The Analyst gets to work on design, undertakes an initial analysis, establishes the impact, value or some insights and tailors the production build towards that, not to mention finessing the UI/UX so that the stakeholders find the output easy to work with and understand. The Engineer will dive into the coding and modelling. In larger scale projects, there’s always a complex modelling or data refresh requirement that’ll definitely be more aligned with the skillset of the Engineer.
Creating an advanced partitioning and refresh strategy is my example this time. I have built such a thing, and as someone that has always leaned more towards the Analyst side of things, I learnt the skills required for this like TMSL coding and the use of the XMLA Endpoint through brute force. It did not come naturally to me, and there are elements of the solution I simply didn’t have the mental capacity to complete, the PowerShell based refresh script being one. My mind nearly exploded when my copied and mildly adapted code threw an error I had no idea how to resolve. Enter the Engineer who picked up PowerShell in no time, fixed my error and finished off the solution. This is but one example of where two heads are better than one.
Finally, lets return to the people aspect. This model will allow people to focus their learning on fewer of Power BI’s ever expanding capabilities, and really hone their skillsets in specific things, leading to more specialists. Two specialists in differing areas, working together, will be able to knowledge share their way to a great level of understanding across all areas. In lots of cases, it’s more than enough to simply know something can be done and by whom, rather than how it’s done.
So, you want to simply swap the word “Data” for “Power BI”?
Well, on the face of it, yes. What I appear to have done is written over 1,000 words that essentially amount to “if we must use Power BI in a job title, can we please change Data Analyst and Data Engineer, to Power BI Analyst and Power BI Engineer”.
But it’s actually way more than that. I’m trying to stop an emerging trend where it’s thought that these roles can be rolled (pun intended) into one and named “Developer”. I think it’s too much, or at least it is when you get to a certain size of company. Developers are expected to learn all of the things across an incredibly broad amount of differing skillsets, and this will only be to the detriment of the people involved, the analysis delivered and the environments or infrastructure housing it all – there are no winners in this situation.
