Back in January I shared a video that wasn’t technically about data culture, but which I believed was a near-perfect analogy for the evolution of a data culture. Now I’d like to share another one. It’s a short and thoughtful six minute video that I hope you’ll take the time to watch.
Consider this question from the video: “How much freedom is too much? How much is not enough?” Then consider the answer: it depends.
I strongly believe that pain is a fundamental precursor to significant change. If there is no pain, there is no motivation to change. Only when the pain of not changing exceeds the perceived pain of going through the change will most people and organizations consider giving up the status quo. There are occasional exceptions, but in my experience these are very rare.
Bermuda changed, because the pain of not changing was too great. They realized that the traditional, centralized approach would not work for them, so they developed a distributed, decentralized approach that would work.
This change meant that individuals needed to do some of the things that most of us would expect the a government agency to do. This change meant that individuals gave up some freedom that most of us have always taken for granted.
This change also kept those individuals from dying.
If you skipped over the video and just read to this point, please go back up and watch it now. Go. Listen to the words about Bermuda, and think about how your organization uses data. Think about how hard change is – who accepts it, and who pushes back.
Evan Hadfield, the young man behind the Rare Earth channel on YouTube, touches on a lot of the nuance and balance and conflict that makes culture change so difficult. A lot of his videos touch on painful historical topics which he explores and questions, but often without answers to those questions. I love it, and watch every video he releases. If you like this blog for more than just the data stuff, odds are you’ll love it too.
 For them it was about water management. For you it might be about data. Work with me here.
 If you have a homeowners association that mandates and restricts the exterior of your home, you may be in the exception on this one.
 I first discovered the channel when YouTube recommended this video. I ignored it for weeks, but when I finally gave in and watched it the first time I was instantly hooked.
Love the analogy. My personal favorite analogy regards old family photos. If no one takes the time to write on the back of the photo the who/what/where/when/why (i.e. the metadata), that photo will get thrown away.
Not everyone agreed that this was a great analogy. Khürt Williams in particular called out the inherent value of some data independent of any metadata to give it context.
No one throws away old family photos because they lack who/what/where/when/why. In fact, I would argue that with family photos the metadata lives in the minds of the people in the photograph or some family member you haven’t yet spoken to.
Somethings have value way beyond their metadata.
These comments got me thinking, and made me ask myself: when does memory die?
I’ve seen many variations on this quote, but I don’t know who said it first:
You only live as long as the last person who remembers you.
This may be a Russian proverb or it may be a quote from Westworld, but I believe the principle applies as much to business data as it does to family photos, despite the obvious differences between the two.
Looking at the family photos context first I can clearly recall times in my life, in those dark days following a funeral or a divorce, when family photos were discarded and the lack of metadata was a contributing factor. The photos of close relatives were kept, but those of more distant relatives were at risk.
When you’re asking “should I keep this photo?” and the next question is “who are these people?” the answer to the second question is going to influence the answer to the first.
As a specific example, I’d like to share a photo that hangs above the one-handed swords in my hallway.
This photo was in the home of my wife’s grandmother, who passed away almost 20 years ago. We found it when we were cleaning out her house after her funeral; it was in the attic, not on display, and no one knew who this young man might be. A few relatives thought that he was a cousin or second cousin of my wife’s late grandmother who went to the great war and never returned – but no one was certain. There was writing on the paper backing the frame, but it was faded and smudged by the years, and by the time we discovered the photo the words were illegible.
By the time we discovered the data, the metadata was no longer usable, and any subject matter expert who could have shared the deeper context of the data had long since moved on.
And once you phrase it like that, it starts to sound familiar again.
In far too many business contexts the metadata lives only in the minds of the people who create and work with the data. It’s tribal knowledge – just like unlabeled family photographs. But as people move on to new jobs and the business changes over time, that tribal knowledge is lost. Even though the data may still be the same, and may still be valuable, when the people move on the tribal knowledge leaves with them. At this point it will either be organically rediscovered and recreated, or the data will stagnate because no one remembers anymore why it was important. Or, as is the case with the photo above, the data may be used and applied to a different purpose.
Tribal knowledge is a lousy metadata solution, no matter the context. Because tribal knowledge is inherently transitory and lossy, we should strive to capture metadata in a more systematic way, and to keep the metadata as close to the data as possible.
Because eventually memory will die. And some things are too important to forget.
 My favorite variation may be from Manowar, who remind us that only courage and heroism linger after death… but it would be a stretch even for me to incorporate this into the body of the post. This is why we have footnotes.
 I call out the fact that these are the one-handed swords because the two-handed swords hang in a different hallway, and there isn’t enough room for a photo above them.
My family is a foster family for cats and kittens from the cat shelter where we’ve adopted some of our own cats. Usually a litter will stay with us for a month or two, but it depends on the kittens themselves, and on external factors.
While the kittens are with us, it’s our responsibility to help them grow, both physically and socially. The experts at the shelter are always available if we need help, but for the most part we have the knowledge and tools we need to be successful. In many cases we’re their first real exposure to humans, and we can prepare them to be loving and playful members of a family. Just not ourfamily.
Once the kittens are ready to be adopted, we take them to the shelter, where they will be carefully matched with their forever family. This last part is important – it’s hard enough to let go, and knowing that each of them will find a good home is what makes it possible.
It’s really the best of both worlds – kind of like managed self-service BI with Power BI.
Not unlike fostering kittens, managed self-service BI can be the best of both worlds. As an analyst working in Power BI, you can often pick up projects when the scope is still small and manageable, and when you can have fun playing around with the data and seeing what it’s likely to become.
I’m emphasizing the “managed” in managed self-service BI, because it’s best to not be completely on your own. Having someone backing you up, someone with the expertise and resources to get you through challenging spots with a helping hand, is just as important with BI as it is with kittens. An author on his own may make avoidable mistakes with long-term consequences, but a center of excellence or community of practice can provide training up front, and assistance along the way so the finished self-service solution is ready to grow up – and growing up is an important goal.
Just as my family includes our adult cats, that analyst working in Power BI has a day job. If we kept each litter of kittens we foster, things would soon become messy and unmanageable. If an analyst retained ownership of every Power BI solution he developed, he would struggle to stay on top of his core priorities.
Being able to hand off a self-service solution to a central BI team is what gives this story a happy ending. The BI team can give the analyst’s work the long-term home it deserves, and the analyst can get back to his job… while also keeping an eye open for the next self-service BI challenge to come along and steal his heart.
If you’re interested in learning more about the shelter where we volunteer, please visit the Meow Cat Rescue web site. Please also consider donating while you’re there – the global pandemic is making it harder for their awesome staff and volunteers to do what they do, and kitten season is upon us. If you appreciate the BI Polar blog and its companion YouTube channel, there’s no better way to say thank you than to donate to Meow. Even a small donation will help.
 I hope you saw that one coming
 This footage of Tiny attacking my head didn’t fit into the Power Kittens video, but I shared it on Twitter because it was just too cute to not share.
Every recipe I’ve made from this cookbook has produced fantasticresults. It’s one of those go-to cookbooks where I know that anything I try will be good. And yet, I almost never seek it out when I want to cook, except for the recipes I already know. The reason is metadata.
It doesn’t matter how good your data is – without effective and available metadata, your investment in quality data will be undermined.
Let’s look at the recipe for saag paneer. Say those words out loud (“saag paneer”) and images of that rich, vibrant green sauce will start running through your mind.
I found this recipe easily because I have a bookmark. But let’s say I didn’t – it should still be easy to find, because cookbooks have indexes, and indexes are the perfect tool for finding recipes. Let’s find the recipe for saag paneer.
Literally the only place the phrase “saag paneer” exists in this book is below the recipe header. This means that the only way to find the saag paneer recipe is to flip through the book page by page, or to know the specific and arbitrary phrase the author uses to describe the recipe for Western readers. This is why my copy of the book looks like this:
This systemic problem is exacerbated by the book’s complete lack of photos; there’s also no way to skim through the book and quickly visually identify recipes of relevant interest. The reader is forced to carefully evaluate each recipe in turn, looking at ingredients and processes to decide if the recipe is worth making.
At this point you may be asking what this has to do with metadata or you may see the connection already.
The reason I immediately thought of metadata may be related to a BI effort I’m working on. Without going into too much detail, I have built a small Power BI app that presents information from a program I run and makes that information available to other members of my extended team.
I’m currently at the point where my app needs to include data from other sources in order to increase its value. Fortunately, that data already exists, and to make it even easier to work with, it is available as a set of Power BI dataflows. I was able to email the owner to get access and to learn which dataflows to look in, and I was off. But not for very far, or for very long.
Very quickly I was back where this post started: I was faced with the high-quality data I needed, and I lacked the metadata to efficiently use it. I needed to manually evaluate each dataflow and each entity to understand its contents and context and to decide if it was right for me. I made some early progress, but because of the lack of metadata the effort will likely take days not hours, and this means it probably won’t get done this month or next.
Let that sink in: because of a lack of effective metadata, quality curated data is going unused, and business insights are being delayed by weeks or months.
Just like these fantastic recipes sitting on my shelf, largely unused and unmade because a fantastic cookbook lacks a usable index, these fantastic dataflows are going largely unused, at least by me. All because metadata was treated as a “nice to have” rather than as a fundamental high-priority requirement.
Does your data have the metadata it needs, in a format and location that serves the needs of your users? How do you know? Remember that last picture of all the bookmarks?
These bookmarks are a symptom of the underlying metadata problem. Bookmarks aren’t a problem themselves, but if you’re paying attention you can see that they’ve been implemented as a workaround to a problem that might not otherwise be apparent. If you’re familiar with the concept of “code smells”, you probably see where I’m going.
When your data lacks useful metadata to enable its effective use, people will start to take actions because of this lack. Things like emailing you to ask questions. Things like building their own ad hoc data dictionaries. Things like using alternate or derivative sources instead of using your authoritative data source – like the recipe link I shared above.
The more of these actions you identify, the more urgency you should feel about closing the metadata gap. Not every data source is a werewolf, but every data source requires metadata to be effectively and efficiently used.
 Remember this picture. There will be a quiz later.
 You may also be asking if there’s anything in life that doesn’t make me think about metadata. This is a fair question.
 I knew the owner’s email because I had bookmarked it earlier.
 To be fair, my full schedule is also contributing to this delay – I’m not trying to say that the lack of metadata is independently costing months. But it is a key factor: my schedule could accommodate two or three hours for this work, but it doesn’t have room for two or three days until the end of April.
I live 2.6 miles (4.2 km) from the epicenter of the coronavirus outbreak in Washington state. You know, the nursing home that’s been in the news, where over 10 people have died, and dozens more are infected.
As you can imagine, this has started me thinking about self-service BI.
When the news started to come out covering the US outbreak, there was something I immediately noticed: authoritative information was very difficult to find. Here’s a quote from that last link.
This escalation “raises our level of concern about the immediate threat of COVID-19 for certain communities,” Dr. Nancy Messonnier, director of the CDC’s National Center for Immunization and Respiratory Diseases, said in the briefing. Still, the risk to the general public not in these areas is considered to be low, she said.
That’s great, but what about the general public in these areas?
What about me and my family?
When most of what I saw on Twitter was people making jokes about Jira tickets, I was trying to figure out what was going on, and what I needed to do. What actions should I take to stay safe? What actions were unnecessary or unhelpful?
Before I could answer these questions, I needed to find sources of information. This was surprisingly difficult.
Specifically, I needed to find sources of information that I could trust. There was already a surge in misinformation, some of it presumably well-intentioned, and some from deliberately malicious actors. I needed to explore, validate, confirm, cross-check, act, and repeat. And I was doing this while everyone around me seemed to be treating the emerging pandemic as a joke or a curiosity.
I did this work and made my decisions because I was a highly-motivated stakeholder, while others in otherwise similar positions were farther away from the problem, and were naturally less motivated at the time.
And this is what got me thinking about self-service BI.
In many organizations, self-service BI tools like Power BI will spread virally. A highly-motivated business user will find a tool, find some data, explore, iterate, refine, and repeat. They will work with untrusted – and sometimes untrustworthy – data sources to find the information they need to use, and to make the decisions they need to make. And they do it before people in similar positions are motivated enough to act.
But before long, scraping together whatever data is available isn’t enough anymore. As the number of users relying on the insights being produced increases – even if the insights are being produced by a self-service BI solution – the need for trusted data increases as well.
Where an individual might successfully use disparate unmanaged sources successfully, a population needs a trusted source of truth.
At some point a central authority needs to step up, to make available the data that can serve as that single source of truth. This is easier said than done, but it must be done. And this isn’t even the hard part.
The hard part is getting everyone to stop using the unofficial and untrusted sources that they’ve been using to make decisions, and to use the trusted source instead. This is difficult because these users are invested in their current sources, and believe that they are good enough. They may not be ideal, but they work, right? They got me this far, so why should I have to stop using them just because someone says so?
This brings me back to those malicious actors mentioned earlier. Why would someone deliberately share false information about public health issues when lies could potentially cost people their lives? They would do it when the lies would help forward an agenda they value more than they value other people’s lives.
In most business situations, lives aren’t at stake, but people still have their own agendas. I’ve often seen situations where the lack of a single source of truth allows stakeholders to present their own numbers, skewed to make their efforts look more successful than they actually are. Some people don’t want to have to rebuild their reports – but some people want to use falsified numbers so they can get a promotion, or a bonus, or a raise.
Regardless of the reason for using untrusted sources, their use is damaging and should be reduced and eliminated. This is true of business data and analytics, and it is true of the current global health crisis. In both arenas, let’s all be part of the solution, not part of the problem.
 Before you ask, yes, my family and I are healthy and well. I’ve been working from home for over a week now, which is a nice silver lining; I have a small but comfortable home office, and can avoid the obnoxious Seattle-area commute.
 This article is the best single source I know of. It’s not authoritative source for the subject, but it is aggregating and citing authoritative sources and presenting their information in a form closer to the solution domain than to the problem domain.
 This is why I’ve been practicing social media distancing.
 This is the where the “personal pandemic parable” part of the blog post ends. From here on it’s all about SSBI. If you’re actually curious, I erred on the side of caution and started working from home and avoiding crowds before it was recommended or mandated. I still don’t know if all of the actions I’ve taken were necessary, but I’m glad I took them and I hope you all stay safe as well.
 As anyone who has ever implemented a single source of truth for any non-trivial data domain can attest.
 You can enjoy the lyrics even if Kreator’s awesome music isn’t to your taste.
I’m running behind on my own YouTube publishing duties, but that doesn’t keep me from watching the occasional data culture YouTube video produced by others.
Like this one:
Ok… you may be confused. You may believe this video is not actually about data culture. This is an easy mistake to make, and you can be forgiven for making it, but the content of the video make its true subject very clear:
A new technology is introduced that changes the way people work and live. This new technology replaces existing and established technologies; it lets people do what they used to do in a new way – easier, faster, and further. It also lets people do things they couldn’t do before, and opens up new horizons of possibility.
The technology also brings risk and challenge. Some of this is because of the new capabilities, and some is because of the collision between the new way and the old way of doing things. The old way and the new way aren’t completely compatible, but they use shared resources and sometimes things go wrong.
At the root of these challenges is users moving faster than any relevant authorities. Increasing numbers of people are seeing the value of the new technology, assuming the inherent risk, and embracing its capabilities while hoping for the best.
Different groups see the rising costs and devise solutions for these challenges. Some solutions are tactical, some are strategic. And eventually some champions emerge to push for the creation of standard solutions. Or standards plural, because there always seems to be more than one of those darned things.
Not everyone buys into the standards at first, but over time the standards are refined and… actually standardized.
This process doesn’t slow down the technology adoption. The process and the standards instead provide the necessary shape and structure for adoption to take place as safely as possible.
With the passage of time, users take for granted the safety standards as much as they take for granted the capabilities of the technology… and can’t imagine using one without the other.
For the life of me I can’t imagine why they kept doubling down on the “lane markings” analogy, but I’m actually happy they did. This approach may get more people paying attention – I can’t find any other data culture videos on YouTube with 488K views…
 Part of this is because my wife has been out of town, and my increased parental responsibilities have reduced the free time I would normally spend filming and editing… but it’s mainly because I’m finding that talking coherently about data culture is harder for me than writing about data culture. I’ll get better, I assume. I hope.
 In this case, I watched while I was folding laundry. As one does.
 Yes, pun intended. No, I’m not sorry.
 Either through knowledge or through ignorance.
Every time I cook or bake something, I think about how the tasks and patterns present in making food have strong and significant parallels with building BI solutions. At some point in the future I’m likely to write a “data mis en place” blog post, but for today I decided to take a more visual approach, starting with one of my favorite holiday recipes.
Check it out:
(Please forgive my clickbaitey title and thumbnail image. I was struggling to think of a meaningful title and image, and decided to have a little fun with this one.)
I won’t repeat all of the information from the video here, but I will share a view of what’s involved in making this self-service BI treat.
When visualized like this, the parallels between data development and reuse are probably a bit more obvious. Please take a look at the video, and see what others jump out at you.
And please let me know what you think. Seriously.
 And other types of software, but mainly BI these days.
 I published this recipe almost exactly a year ago. The timing isn’t intentional, but it’s interesting to me to see this pattern emerging as well…
I talk about data culture a lot, and in my presentations I often emphasize how the most important success factor when adopting a tool like Power BI is the culture of the organization, not the tool itself.
In my day job I get to talk to leaders from large companies around the world, and to see how they’re adopting and using Power BI, Azure. Before today I didn’t think of Moby Dick – I thought of Leo Tolstoy’s classic Anna Karenina, which starts with this classic line:
All happy families are alike; each unhappy family is unhappy in its own way.
Although the details vary, large companies that have successfully adopted managed self-service BI at scale have cultures with important aspects in common:
Leaders empower business users to work with data
Leaders trust business users to use data to make better decisions
IT supports business users with platforms and tools and with curated data sources
Business users work with the tools from IT and the guidance from leaders, and work within the guardrails and guidelines given to them for this use
Business and IT collaborate to deliver responsive solutions and mature/stable solutions, with clearly defined responsibilities between them
Companies that are successful with managed self-service BI do these things. Companies that are not successful do not. The details vary, but the pattern holds up again and again.
How do these roles and responsibilities relate to culture?
In many ways a culture is defined by the behaviors it rewards, the behaviors it allows, and the behaviors it punishes. A culture isn’t what you say – it’s what you do.
In the context of BI, having a culture with shared goals that enable business and IT to work together with the support from the company leaders is the key. If you have this culture, you can be successful with any tool. Some tools may be more helpful than others, and the culture will enable the selection of better tools over time, but the tool is not the most important factor. The culture – not the tool – inevitably determines success.
This is not to say that BI tools should not improve to be a bigger part of the solution. But to paraphrase Caitie… maybe you should let that white whale swim past.
 But definitely not only Power BI.
 He says unironically, before writing many more words.
In the late 1300s and early 1400s, Fiore de’i Liberi was a knight, a diplomat, and a fencing master. He also wrote one of the most comprehensive treatises on medieval combat, his Flower of Battle, of which four copies survive in museums and private collections today. Fiore started – or was a significant evolutionary step in – one of the most important and long-lasting traditions in armed and unarmed combat.
In addition to detailed instruction on fighting with dagger, longsword, spear, and other weapons, Fiore’s manuscript included a preface with information about the virtues that any fencer would need to be successful in combat.
In the image above, Fiore pictures the seven blows of the sword, and his four virtues, each represented by a different animal:
This Master with these swords signifies the seven blows of the sword. And the four animals signify four virtues, that is prudence, celerity, fortitude, and audacity. And whoever wants to be good in this art should have part in these virtues.
Fiore then goes on to describe each virtue in turn:
Prudence No creature sees better than me, the Lynx.
And I always set things in order with compass and measure.
Celerity I, the tiger, am so swift to run and to wheel
That even the bolt from the sky cannot overtake me.
Audacity None carries a more ardent heart than me, the lion,
But to everyone I make an invitation to battle.
Fortitude I am the elephant and I carry a castle as cargo,
And I do not kneel nor lose my footing.
Step back and read this again: “And whoever wants to be good in this art should have part in these virtues.”
That’s right – Fiore was documenting best practices, 600+ years ago. And although I suspect that Fiore wasn’t thinking about business intelligence projects at the time, I do believe that these virtues are just as relevant to the slicing and dicing we’re still doing today. Let me explain.
Prudence – “…I always set things in order with compass and measure“: A successful BI practitioner knows what needs to be done before a project can begin, and when additional work is required before they can get started. Initiating a project requires careful setup and planning, and moving before the prerequisites for success are in place can be disastrous.
Celerity – “I… am so swift to run and to wheel that even the bolt from the sky cannot overtake me“: Business requirements change day to day and hour to hour. To succeed, a BI practitioner must be prepared to move quickly and decisively, engaging without delay when an opportunity presents itself – and also be prepared to change direction as the needs of the project change.
Audacity – “…to everyone I make an invitation to battle“: Any project declined presents an opening for another practitioner, another team, another tool, and this is likely to reduce opportunities over time. Saying yes to difficult projects – and succeeding in their execution – is necessary to ensure that future projects don’t pass you by.
Fortitude – “And I do not kneel nor lose my footing“: When Fiore speaks of fortitude, he does not speak of the strength that comes from big muscles. He speaks of the strength that comes from structure, and balance. His “elephant with a castle on its back” is a perfect metaphor for a BI solution delivered quickly and confidently because of the solid and stable platform on which it is built. Success doesn’t come from the extra effort put in when delivering a solution – it comes from the care and planning that went into the overall data estate.
You may look at these virtues and see contradiction – how can you have prudence and audacity and celerity? The answer for BI is the same answer that it is for the sword: practice, training, and preparation. In both situations, whether you’re battling with an armed foe or battling with a difficult client, you need to apply the right virtues at the right times, and to understand both the big picture and the day to day steps that produce larger successes. In both situations you’re also facing complex and dynamic challenges where you need to quickly take advantage of opportunities as they arise, and create opportunities when they don’t appear on their own. Fortunately, as BI practitioners we can rely on the strengths of our teams – it’s not always a solo battle.
You may also look at these virtues and see Matthew stretching to make the most tenuous of analogies work, just because he loves swords as much as he loves BI. While this may be true, I do honestly believe that these virtues do apply here. Over the past 20-25 years I have seen many projects succeed because these virtues were embodied by the people and teams involved, and I’ve seen many projects fail where these virtues were absent. This isn’t the only way to look at success factors… but at the moment it’s my favorite.
In closing, I’d like to mention that this post marks one year since I started this blog. In the past year I’ve published almost 90 posts, and have had roughly 50,000 visitors and 100,000 page views. Here’s hoping that by applying Fiore’s virtues I’ll be able to make the next year even more productive and more successful than the year that has passed.
Thanks to all of you who read what I write, and who provide feedback here and on Twitter – I couldn’t do it without you.
 Fencer in this context meaning someone who fights with swords or other edged weapons, not the Olympic-style sport of fencing that a modern reader might picture when reading the word.
 Although it may not be obvious to the modern reader, the animal at the bottom is an elephant with a tower or castle on its back. I suspect that Fiore never actually saw an elephant.
 In case these terms don’t immediately have meaning, prudence == wisdom, celerity == speed, audacity == daring, and fortitude == strength.
 See what I did there?
 I assume that Fiore’s use of the term “measure” here is pure coincidence.
 If you’ve worked on a high-stakes, high-visibility BI project where requirements changed during implementation, or where not all stakeholders were fully committed to the project goals, this will probably feel very familiar.
I’ve long been a fan of the tech new site Ars Technica. They have consistently good writing, and they cover interesting topics that sit at the intersection of technology and life, including art, politics, and more.
When Ars published this article earlier this week, it caught my eye – but not necessarily for the reason you might think.
This story immediately got me thinking about how falling asleep at the wheel is a surprisingly good analogy for self-service BI, and for shadow data in general. The parallels are highlighted in the screen shot above.
Initial reaction: People are using a specific tool in a way we do not want them to use it, and this is definitely not ideal.
Upon deeper inspection: People are already using many tools in this bad way, and were it not for the capabilities of this particular tool the consequences would likely be much worse.
If you’re falling asleep at the wheel, it’s good to have a car that will prevent you from injuring or killing yourself or others. It’s best to simply not fall asleep at the wheel at all, but that has been sadly shown to be an unattainable goal.
If you’re building a business intelligence solution without involvement from your central analytics or data team, it’s good to have a tool that will help prevent you from misusing organizational data assets and harming your business. It’s best to simply not “go rogue” and build data without the awareness of your central team at all, but that has been sadly shown to be an unattainable goal.
Although this analogy probably doesn’t hold up to close inspection as well as the two-edge sword analogy, it’s still worth emphasizing. I talk with a lot of enterprise Power BI customers, and I’ve had many conversations where someone from IT talks about their desire to “lock down” some key self-service feature or set of features, not fully realizing the unintended consequences that this approach might have.
I don’t want to suggest that this is inherently bad – administrative controls are necessary, and each organization needs to choose the balance that works best for their goals, priorities, and resources. But turning off self-service features can be like turning off Autopilot in a Tesla. Keeping users from using a feature is not going to prevent them from achieving the goal that the feature enables. Instead, it will drive users into using other features and other tools, often with even more damaging consequences.
Here’s a key quote from that Ars Technica article:
We should be crystal clear about one point here: the problem of drivers falling asleep isn’t limited to Tesla vehicles. To the contrary, government statistics show that drowsy driving leads to hundreds—perhaps even thousands—of deaths every year. Indeed, this kind of thing is so common that it isn’t considered national news—which is why most of us seldom hear about these incidents.
In an ideal world, everyone will always be awake and alert when driving, but that isn’t the world we live in. In an ideal world, every organization will have all of the data professionals necessary to engage with every business user in need. We don’t live in that world either.
There’s always room for improvement. Tools like Power BI are getting better with each release. Organizations keep maturing and building more successful data cultures to use those tools. But until we live in an ideal world, we each need to understand the direct and indirect consequences of our choices…
 For example, any time I see stories in the non-technical press related to hacking or electronic voting, I visit Ars Technica for a deeper and more informed perspective. Like this one.
 Please let me explicitly state that I am in no way minimizing or downplaying the risks of distracted, intoxicated, or impaired driving. I have zero tolerance for these behaviors, and recognize the very real dangers they present. But I also couldn’t let this keep me from sharing the analogy…
 As a member of the Power BI CAT team I would obviously be delighted if everyone used Power BI, but we also don’t live in that world. No matter what self-service BI tool you’ve chosen, these lessons will still apply – only the details will differ.