Feb 22

Feb 22 The Goblin Behind the Model

Kurt Buhler

Data Culture & Adoption

WHY EMPATHY IS ESSENTIAL IN AN EFFECTIVE DATA CULTURE

…and how it materializes in discussions about data solutions & feedback.

In this series, we will learn how to effectively assess an existing or ‘inherited’ dataset.
We will learn how to…

Remember the person behind the model

Conduct an efficient analysis with Tabular Editor 3
Analyze the model with VertiPaq Analyzer
Explore the model with Dynamic Management Views (DMVs)
Automate DMVs execution with C# scripts in Tabular Editor

Inheriting a Data Model

Working with a dataset or report that you did not create is challenging.
There is rarely documentation that gives a good overview of the scope, logic and shortcomings of the solution, necessitating deep dives into the model itself in order to understand it. This is particularly true when inheriting problem models that you need to “fix”, perhaps plagued by performance issues, inaccurate calculations, or absent functionality. It’s essential to be thorough in these investigations, but at the same time to also be efficient and objective in the analysis.

In this series, we look at how to handle “model inheritance”, with particular focus on how Tabular Editor 3 makes this very easy & efficient. First, though, we need to approach the problem with the right mentality, and - more importantly - a bit of empathy…

Part 1: Remembering the goblin behind the model

It’s rather common to see discussions of disaster datasets & reports. Screenshots of tables & relationships that could be mistaken for spaghetti art, reports that are colours in a blender, messy code, or just stories and memes from the data-lagoon. Often, though, such tales are not focused on learning from mistakes, but rather basking in the cathartic schadenfreude* that these datasets create, both from the company and the professional who has to fix them. We rarely reflect upon the person behind the creation, or the effect discussions might have on people looking from the outside in…

* Schadenfreude: Pleasure derived from someone else’s misfortune

Communicating criticism - good for a chuckle, but how does it affect others?

“Reporting horror stories” can be amusingly relatable among closed circles of peers & professionals, and it’s in human nature to share these things; we all do it. What we may not realize, however, is that these communications are an unhelpful reflection of the problematic ways in which we vocalize and think about others outside of our visible, niche circles. What’s worse is that it perpetuates a toxic social smog, which appears neither helpful nor welcoming. This is not only true of online communication in our data communities, but also the day-to-day communication that has an impact on the data culture we want to stimulate in our organization. It looms close to other, unhelpful social smog online - for example - the strange undercurrent competition between Python & SQL in some circles, lately, or the perpetual ‘business vs. IT’ us-and-them talk.

We seek to create an inclusive data culture in our organization, yet doing so requires that we lay the brick-and-mortar of a common ground, rather than remain on ivory towers. A big part of this culture is founded on data literacy and critical thinking, where knowledge-sharing opportunities from professionals to others are embraced. By communicating our topic with inaccessible barbs or voicing criticism in an unempathetic, unhelpful way, we project an attitude that inadvertently contributes to gatekeeping - where senior members of a community or group creating barriers for newer, more junior members to join. For us, this means data professionals making it harder for others with lower data skills or data literacy to join the conversation & culture.

The effect of gatekeeping is that it hinders the accessibility and future diversity of a community. When being exposed to this “social smog”, newcomers earlier in their learning path or crossing laterally from other sectors may be deterred from participating by what they perceive as dismissive judgement or high barriers-of-entry. They might avoid participation out of a fear to be criticized or attacked for ignorantly saying or doing something incorrect. They might even feel like they can only join via the dogpile - joining in on the fun of dragging something through the mud. In the long-term, gatekeeping is certainly not a good thing. It limits the introduction of newer, more diverse perspectives and selects for “sameness” of attitudes, perspectives and behaviors. Fresh, diverse perspectives are essential to bring about new ways of thinking, to find innovative solutions to old problems, and to challenge existing dogmas.

However it’s not only the way we communicate which can be problematic. When inheriting a solution authored by someone else, it’s easy to see the things we’d do differently, or the things that are outright incorrect or sub-optimal. That’s fine; peer review is essential for assuring quality of the things we make. However, it’s also easy to extrapolate this judgement to the author, themselves. We can be quick draw conclusions about the person’s competence, knowledge or character based on limited and incomplete information of only the dataset we have open. We might subconsciously have expectations for that person based on our own experience. This bias is referred to as ‘what-you-see-is-all-there-is’ - we form a conclusion about the author based on the limited information we have, rather than the whole picture, which we do not. We forget that hindsight is sharper than foresight, or the circumstance which might have led to the result. Being aware of this bias and reminding ourselves of possible missing context is an exercise in empathy, which can make it easier for us to act & communicate in a helpful way;
to communicate empathetically is to communicate effectively.

Being helpful & empathetic when sharing criticism in a social space.

It’s thus important to be self-aware of the manner in which we conduct & communicate criticism, assessment & peer-review. This isn’t something exclusive to social media - the examples above are light cartoons to illustrate a nuanced and difficult point; we assess peers every day in our professional lives, if we realize it, or not. Criticism must be encouraged, but it must also be constructive and empathetic. It should be helpful. It should have the implicit understanding that not everyone has the same background, knowledge or way of thinking as ourselves. This is particularly important in social circles exposed to the public, such as in online interactions and in conferences. If we want to contribute to a data culture or encourage new, diverse minds to enter our realm, we must create a social environment that welcomes and nurtures them. By focusing on “disaster datasets” or normalizing “shout-into-the-void” social media-style criticism, we risk breathing in the smog that we ourselves would create; it may make us feel better in the short-term, but at what cost? Does it really help, or teach anybody anything?

If you see someone drowning, you don’t shout “learn to swim”

Illustrated with some hypothetical examples of three personas. Click the expand icon to read their story.

Bonk works as a financial analyst. Bonk is comfortable with Excel, but recently, his boss has tasked him with making Power BI reports for their team. Having no background in IT or BI and a lot of pressure to make these reports fast, Bonk downloaded Power BI Desktop and followed some YouTube tutorials. It took some time, but Bonk was able to load his Excel files into Power BI Desktop and transform the data, then start making his reports.
Bonk really likes working in Power BI, and has been trying to learn more about DAX and Power Query. He likes that the tool lets him make powerful transformations with the Power Query UI or DAX quick measures, as he’s not very comfortable with programming. Bonk’s colleagues prefer to keep reporting in Excel, but he is regularly advocating for them to start learning Power BI, too, sharing how much time the data transformations in Power Query have saved him. He’s proud of what he’s made and how much he has learned, on his own, and is excited to learn more.
Bonk’s reports are growing more popular and he needs to add many more Excel files to included data from other teams. However, he starts to have a problem that the dataset is taking over an hour to refresh every day, and often fails with an error. Bonk has no idea where to start to fix the problem, so he seeks help from IT.
Assessment: Bonk gets help from a Power BI developer in the IT team, who goes through the dataset. The IT team member produces a 20-slide summary of everything wrong with the dataset and the risks it creates for the company. Inside the presentation are a lot of terms and acronyms Bonk has never seen before. The BI manager decides to absorb the dataset into the BI team’s centralized reporting, and block the Finance team from using Power BI Desktop, citing undue risk for the company. They are instead given access to reports that they should consume from a Finance App.
The Result: Bonk is frustrated that he lost control of his reports and dataset. He feels embarrassed and dumb for how many things he did wrong, but does not understand how he could have known to do it right. He no longer advocates for Power BI within his team, with whom he resumes Excel-based reporting from data extracts.
Bonk is also no longer interested in learning Power BI after this negative experience, and has become a detractor rather than an advocate for the centralized IT solutions, hurting adoption.
The Problem: The Power BI developer who audited the dataset did a good job - they were thorough, identified all the problems, and documented the results, well. However, they incorrectly portrayed Bonk as an irresponsible data rogue, more concerned about doing things fast than doing them right.
In reality, these comments are unfair. The Power BI developer had unrealistic expectations for what Bonk could have known or taught himself in his own time. These expectations were based on the Power BI Developer’s own experiences and knowledge, rather than that of Bonk. While accountable for his own knowledge, Bonk was so ignorant about the tool & processes that it is both unfair and unrealistic to say that the quality of the data model reflected his competence, intelligence or character.
Instead, the Power BI developer could have been more empathetic to Bonk’s circumstances, and more objective in the way they communicated the assessment. They could have recognized the opportunity to teach Bonk and improve his data literacy, rather than push him further down for ignorantly producing a problematic dataset. Unfortunately, they squandered an opportunity to extend the data literacy of the Finance team, but at the same time, through collaborative knowledge-sharing, to extend the Finance knowledge of the BI team, building bridges necessary for a real data culture to take place.
Bink works in journalism. She started her career working for a print newspaper fifteen years ago, but recently has been working for more online venues. Already for some years, Bink has been incorporating more and more data visualizations in her news stories. She has become increasingly interested in the field of data journalism, even going to the extent of taking night courses to learn R. Internally, Bink’s organization has also started to do more extensive reporting.
The organization has started to adopt Power BI, which Bink has been using to distribute some of her R visuals. She has made a few small datasets, but isn’t very comfortable with the data modelling aspect of the tool. She has no experience with data engineering or modelling, and is used to just transforming flat files in R then making the static visuals. Power BI and Business Intelligence in general seems like a whole new, strange world to Bink, but she’s interested, and feels like it could be helpful for both her career and her organization.
Bink discovers a Power BI user group in her city and plans to attend the next talk, which is all about making good Power BI data models. She hopes that this will be a nice A-Z introduction to the concept, and that it will lead her further about the subject. Instead, when she attends, the talk is full of technical jargon and acronyms that she’s never seen before. The presenter tells a lot of “data model horror stories”, explaining things Bink couldn’t understand but for which the audience laughs. After the talk, many others are taking turns sharing similar horror stories, as the group laughs about “dumpster-fire datasets”.
Bink leaves the meeting feeling like an outsider, not feeling like she learned very much. She feels like looking into Power BI and Business Intelligence in general was maybe a mistake, that she wouldn’t be able to learn it and would just end up creating such “horror story” solutions. When walking home from the user group, she wonders whether the datasets she’s already created are “disasters”, and imagines being the subject of a talk or story, as the laughter of the audience follows her home from the user group.
The Result: Bink feels insecure and unaccepted in the BI space and community. She feels like the barrier-to-entry is too high and it’s not possible or worth the effort for her to try to join.
Bink instead decides to stop experimenting with Power BI. Hearing the stories from professionals about their inherited dataset disasters discouraged her, and inadvertently perpetuated a barrier making it harder for her to enter the space and community. This is a loss not only for Bink, but also for the (Power) BI community and user group, who could have benefitted from Bink’s fresh, diverse perspective and data journalism background. Bringing people from other backgrounds is essential to find new, innovative solutions to old problems, and challenge dogmatic ways of thinking.
The Problem: The environment at the user group was not accessible to persons outside the existing IT/BI community. Assumptions were made that everybody understood the technical terms and acronyms, and that they all had the same experience and background. While it was amusing for the IT professionals to laugh about the dataset horror stories, for Bink, who cannot relate to this experience, it further isolated her, making her feel insecure with her own knowledge & experience.
Instead, the presenter could have made less assumptions about their audience and included a more accessible introduction to the topic. They could have also presented the examples in a more helpful manner, focusing on lessons learned from their experience, rather than co-ruiminating and re-iterating the observed problem, simply because it was relatable and amusing to professionals like themselves.
Stonk works as a support engineer. They have specialized in SAP for the last ~30 years and are in the tail-end of their career. Recently, their organization has undergone some massive changes, including the BI department. The organization has decided to switch from SAP to the Microsoft BI stack, including a migration from SAP Business Warehouse & Business Explorer to Microsoft Power BI. It’s a very difficult migration under aggressive timelines and tight budgets. The business users are extremely unhappy about the migration, because they were told they will not be able to export to Excel, which is how they get their data, today. Stonk and their team are under extreme pressure to deliver. Further, Stonk has had some personal struggles with their health. They don’t have a lot of time outside of working hours to learn, nor a lot of energy during the working hours, themselves. Stonk did not expect to have to learn so many new things this late in their career, and under the circumstances is struggling to learn Power BI.
Stonk is tasked by their manager with re-making a number of reports similar to the SAP Business Explorer views. Stonk starts to pick up Power BI quite quickly, though they are not sure whether they are doing things the ‘right’ way. Stonk merges all the tables into one large table, and produces whole-page matrix or table views that look identical to those the users had seen in their previous reports. Stonk even includes a few visuals (a line chart and a few pie charts) which the users really seem to like. Stonk knows the data, the organization and even many of the users very well. Stonk talks to a lot of the users regularly on teams, and understands when the users are asking about things they used to find in the SAP system, but can’t find in Power BI. However, the users complain that the reports Stonk made take a long time to show data and that it’s hard for them to find things.
In an effort to accelerate the project, Stonk’s manager on-boards a senior Power BI consultant. The consultant works side-by-side with Stonk to audit & further develop the models. The consultant takes a lot of screenshots of Stonk’s DAX and the Power Query steps, and asks a lot to Stonk “why did you do it this way?”. Stonk can tell that the consultant is easily frustrated with the model, and hears the consultant regularly talk about how much of a mess the datasets are, and how ugly the reports can be. The consultant laughs about the pie chart and shared with Stonk a bunch of memes about how stupid pie charts can be. While the consultant finds these amusing, to Stonk, it’s hurtful, because they feel they made a stupid mistake that apparently no one else would make.
The consultant starts to put together their assessment and begins re-making the models from scratch, working mostly alone with other tools, which Stonk is not familiar with. After the BI Director sees the consultant’s assessment, they decide to move Stonk to another project, because Stonk’s datasets and reports are not “following best practices”. Stonk is placed on the ERP support team.
A few months later, Stonk hears that the issues with the business are escalating to the point where the CEO has demanded that Export to Excel be re-enabled for Power BI. However, despite those extreme measures, the beautiful reports created by the consultants are not being used much, and the old SAP systems are still running, in parallel.
The Result: Stonk was removed from the project because of the work they were delivering. Stonk feels like this was both unfair and unrealistic, as they didn’t have the time or resources to invest in learning Power BI, properly, and did the best they could under the circumstances.
The consultant felt that Stonk was not competent and consequentially worked more on their own to be more productive. They did not listen to the experience Stonk had, with both the data and the users, which led to assumptions made and time lost that could have been avoided.
The Problem: The consultant had unrealistic expectations of Stonk, neglecting that they had a background in other technology. The consultant saw the quality of the results being produced by Stonk, perceiving them as a liability to the project and - even if the consultant didn’t realize it - perceiving Stonk as incompetent. This created a bias where the consultant didn’t consider Stonk’s experience and added value.
While the consultant was tasked chiefly with accelerating the project, they unwittingly had an opportunity to grow the data culture around Power BI, leveraging Stonk’s experience and network to influence users, as well. Instead, the consultant’s knowledge stayed with them, and while they solved a lot of technical problems, the bigger problems of data literacy and adoption remained, or even grew after Stonk left the project.
Similarly, Stonk’s Manager had unrealistic expectations that Stonk could have upskilled in that timeframe, given their situation.
Instead, the consultant could have realized the opportunity presented to help Stonk learn, either passively or actively, and understood the impact that their communication had on those around them. While not responsible for Stonk’s learning, the consultant could have chosen to try to invest in knowledge sharing between themselves & Stonk. Ultimately, this investment could have paid itself forward with the information Stonk could convey about the users and the data, helping the consultant design and build a better solution, or facilitating connection with the users to promote adoption. Stonk’s perspective coming from a different technology could have also brought new ways of thinking about technical problems that experts in the Microsoft BI stack did not have.

Empathy is essential

When a hand-me-down dataset is open on our screen, we peek upon the labor of another. It’s only natural that we may feel frustrated, confused or even amused by what we see. But ultimately, we are taking part in a peer-review exercise and an opportunity to exchange knowledge. It’s therefore not only important to manage the dataset, but also our own internal biases, and our communication about findings, feedback & changes.

By doing so, we can contribute to a healthier data culture not only in our company, but in our wider community & sector; one that is inclusive of not just people like us, but any aspiring data goblin.

NEXT UP: SCHEDULED FOR MARCH 1, 2022 PUBLICATION

In the next article, we look at how Tabular Editor 3 makes model investigations easy. TE3 has a number of tools to quickly explore and analyze the model for common trouble-areas, starting with a deep (deep, deep…) dive into the wonderful VertiPaq Analyzer integrated into TE3, and how to best use it.