Coming to the PASS Data Community Summit in November: The Hitchhiker’s Guide to Adopting Power BI in Your Organization

At the 2022 PASS Community Data Summit this November, I’m thrilled to be co-presenting a full-day pre-conference session with the one and only Melissa Coates [blog | Twitter | LinkedIn]. We’ll be presenting our all-day session live and in-person in Seattle on Tuesday,  November 15, 2022.

What’s the Session?

The Hitchhiker’s Guide to Adopting Power BI in Your Organization

What’s the Session About?

The Power BI Adoption Roadmap is a collection of best practices and suggestions for getting more value from your data and your investment in Power BI. The Power BI Adoption Roadmap is freely available to everyone — but not everyone is really ready to start their journey without a guide. Melissa and I will be your guides…while you’re hitchhiking…on the road…to reach the right destination…using the roadmap. (You get it now, right?!?)

We’ll do an end-to-end tour of the Power BI Adoption Roadmap. During the session we’ll certainly talk about all of the key areas (like data culture, executive sponsorship, content ownership and management, content delivery scope, center of excellence, mentoring and user enablement, community of practice, user support, data governance, and system oversight).

Smart Power BI architecture decisions are important – but there’s so much more to a successful Power BI implementation than just the tools and technology. It’s the non-technical barriers, related to people and processes, that are often the most challenging. Self-service BI also presents constant challenges related to balancing control and oversight with freedom and flexibility. Implementing Power BI is a journey, and it takes time. Our goal is to give you plenty of ideas for how you can get more value from your data by using Power BI in the best ways.

We promise this won’t be a boring day merely regurgitating what you can read online. We’ll share lessons learned from customers, what works, what to watch out for, and why. There will be ample opportunity for Q&A, so you can get your questions answered and hear what challenges that other organizations are facing. This will be a highly informative and enjoyable day for you to attend either in-person or virtually.

Who is the Target Audience?

To get the most from this pre-conference session: You need to be familiar with the Power BI Adoption Roadmap and the Power BI Implementation Planning guidance. You should have professional experience working with Power BI (or other modern self-service BI tools), preferably at a scope larger than a specific team. Although deep technical knowledge about Power BI itself isn’t required, but the more you know about Power BI and its use, the more you’ll walk away with from this session.

We hope to see you there! More details and to register: link to the PASS Data Community web site.

Who wrote this blog post?

It was Melissa.

She wrote it and emailed it to me and I shamelessly[1] stole it, which may be why there haven’t been any footnotes[2]. I even stole the banner image[3].


[1] With her permission, of course.
[2] Until these ones.
[3] Yes, Jeff. Stealing from Melissa is a Principal-level behavior.

Join me in London for SQLBits – March 8 through March 12

In less than two months I’ll be making my first work trip in over two years, flying to London to present, meet with customers, and learn exciting things at the 2022 SQLBits conference. If you can, you should register today and join me.

Here’s what I expect my week to look like:

  • Wednesday March 9, 09:00 to 17:00: I’ll be back on stage for The Day After Dashboard in a Day pre-conference learning day, co-presenting with Patrick LeBlanc, Alex Powers, and Lars Andersen.
  • Thursday March 10, 14:10 to 15:00: I’ll be joining SQLBits organizer and MVP Simon Sabin for the Maximising everyone’s super powers panel discussion on mental health.
  • Thursday March 10, 18:15 to 19:05: Prathy K from the London Power BI User Group has organized an evening “ask me anything” open Q&A session with a bunch of folks from the Power BI CAT team, which sounds like a perfect way to end the day. You can register for this evening meetup here.
  • Friday March 11, 13:40 to 14:00: I finally get to present on Roche’s Maxim of Data Transformation for a live, in-person audience, and I get 20 minutes to do it!
  • Friday March 11, 14:10 to 15:00: The BI Power Hour returns after a two-year pandemic hiatus, guaranteeing laughs and excitement[1] in a demo- and joke-filled exploration of how not to use Microsoft data technologies in the workplace. I’ll be joined by an international star-studded cast from the Power BI CAT team and the Microsoft data community, and I expect this session to be the can’t miss event of the decade.[2]
  • Saturday March 12, 08:00 to 08:50: I kick off the final day of the conference with Unleashing your personal superpower, an honest and sometimes-painful look at how to succeed in tech, despite your brain’s best efforts to stop you. I’m very excited to have this important session scheduled on the free-to-the-public day of the conference.

When I’m not on stage, I’m hoping to spend as much time as possible at the Microsoft product booth and the community zone. Conferences like SQLBits are an opportunity to have interesting conversations that can be an awkward fit for virtual channels, and I plan to get the most from my week as possible.

Update February 10: I’m planning to be in the community zone on Thursday afternoon immediately following the mental health panel discussion so we can keep that conversation going. I’m also planning to be back on Friday morning at 10:10 to talk about non-traditional career paths. If either of these conversations sounds interesting to you, you should plan on joining me.

Update February 12: My Saturday session has been moved from the end of the day to the beginning of the day. With this change, I can now have more time to hang out in the community zone on Saturday to continue the discussion.

If you’re in the London area – or if you can get there – and if attending an in-person event matches your personal risk profile, I hope you’ll register today and come say hi during the event. I’ll be the purple-haired guy with the mask on.

If you can’t come to London, I hope you’ll still register and attend. Most sessions are hybrid with virtual attendees welcome and included.


[1] Not guaranteeing that you will laugh or be excited. I’m just thinking about me here.

[2] Thinking back on the decade in question, this isn’t as high a bar as it might otherwise seem.

Simplifying the solution domain

My recent posts have focused on the importance of understanding both the problem domain and solution domain in which you’re working, the value of operating in both the problem domain and the solution domain, and some specific resources and techniques for solution-oriented practitioners to increase their fluency in understanding the problem domain. A lot of the message I’ve been trying to get across in these posts can be summarized as “the problem domain is really important, and we need to get better at appreciating and understanding the problems we work to solve.”

This message is predicated on two basic assumptions:

  1. You, the reader, are a technical professional of some sort[1], and you need to deliver technical solutions to people with problems
  2. The people who have problems can’t solve those problems on their own

Let’s look more closely at that second assumption, because it’s becoming increasingly less valid, and less true. And let’s look at it through the lens of… furniture.

Close your eyes and imagine for a moment that you need a table. Let’s say you need a bedside table. What do you do?

As you read through this list you were probably evaluating each option against your own requirements and preferences. Odds are you’ve chosen one or more options at some point in your life. Odds are the criteria you used to decide which options are viable or preferable have changed as your circumstances, skills, and budget have changed.

I couldn’t find Ikea instructions for a bedside table, but honestly I didn’t try very hard

Of course, the decision doesn’t need to be about a bedside table. It could be about a dining room table, or a bed, or a full set of kitchen cabinets. Each option will have different but similar choices, and you’ll likely use different criteria to evaluate and select the choice that’s right for you.

This is also true if the choice is about business intelligence solutions, which may not technically be considered furniture[2]. Close your eyes once more and imagine for a moment that you need a report, which may or may not include a table.  What do you do?

  • You could use an existing report
  • You could start with an existing report and customize it
  • You could start with an existing dataset use it to build a new report
  • You could start with an existing dataset, customize it using a composite model, and use it to build a new report
  • You could work with a center of excellence or BI team to create a dataset, customize a dataset, create a report, or customize a report to meet your needs
  • You could locate or create data sources and build a custom BI solution end-to-end, maybe getting some help along the way if you don’t already have the tools and expertise required for the project

The parallels are easy to see, and they hold up surprisingly well to closer inspection. Just as ready-to-build options make it possible for someone with no woodworking or cabinetry skills[3] to self-serve their own furniture, DIY BI tools[4] like Power BI make it increasingly easy for someone with no data preparation or data modeling skills to build their own BI solutions.

To step away from the furniture analogy, tools like Power BI simplify the solution domain and make it easy for problem domain experts to solve their own problems without needing to become true experts in the solution domain.

Any finance or supply chain professional can use Power BI Desktop to build reports that do what they need, without needing to ask for help. Their reports may not be the most beautiful or best optimized[5],  but maybe they don’t need to be. Maybe “good enough” is actually good enough. Just as it might make more sense to buy a $40 Ikea bedside table instead of spending hundreds or thousands of dollars on something fancier, it might make sense to stack a few milk cartons on top of each other and call it good, at least until you can save up for something better[6]. There is no one size that fits all.

If you are a Power BI professional, it may be difficult to think of the “boards and cinderblocks bookshelf” approach as acceptable, but in most circumstances it’s not up to you to decide. The tools for DIY BI are widely and freely available, and people will use them if they present the most attractive and accessible option to solve their problems. You can’t stop them from building DIY solutions, but you can help them build better ones.

This is where having an effective and engaged center of excellence comes in. Whether you think in terms of problem and solution domains, or in terms of enabling DIY through readily available tools and guidance[7], you can help make “good enough” better by meeting your problem domain experts where they are. They have the tools they need to get started building their own solutions, but they probably need your expertise and assistance to achieve their full potential.

You should help them.


[1] Probably a Power BI practitioner, but who knows?

[2] I have repeatedly seen Power BI referred to as a “platform” which is basically the same thing as a table, so I’m going to withhold judgment on this one.

[3] Someone like me! I married a carpenter and have never found the motivation to develop these skills myself.

[4] DIY BI has a ring to it that SSBI doesn’t have. Why don’t we start using DIY BI instead. DBIY? D(B)IY? D(BI)Y? Hmmm…

[5] They may indeed be the Power BI versions of my DIY home improvement projects.

[6] Please raise your hand if you too had bookshelves made of random boards and cinderblocks when you were in college, and were also happy with the results.

[7] This is the second place in this post where I’ve shared a link to this Marketplace story. If you run a Power BI COE for your organization, do yourself a favor and listen to the story – it will inspire you to think about your COE in different ways.

Understanding the problem domain

If you’re reading a Power BI-focused blog[1] you’re probably someone who builds solutions. As a BI and data practitioner, you may build reports, datasets, dataflows, databases, or any number of technical artifacts that together represent a solution domain. You have a toolset at your disposal, and you invest your valuable time and energy into refining the skills needed to use those tools.

But what if you’re holding the right tools, while using them to implement the wrong solution? This could happen if you’re holding a hammer and building a chair when what’s really needed is a table, but it could also happen if you’re using Power BI to build a solution that deliver what its users need to make their jobs easier.

Action doesn’t equate with value, and time spent solving a problem you don’t meaningfully understand is often time wasted. So how do you, as a Power BI author, meaningfully understand problems in domains like finance, supply chain, HR, or patient care if you lack personal experience in those domains?

Asking good questions is a great start.

If you want to deliver a fix for a problem someone has reported, asking targeted closed-ended questions to narrow down the scope of the problem can be valuable. What is the error message, when did it start happening, what are the steps to reproduce the problem, does it happen all the time, does it happen on other computers, does it happen for other users… that sort of thing.

This type of question is often great if you need to deliver a fix, but what about when you need to deliver a product? What if you need to deliver a Power BI app that will help a group of people be more productive completing a complex set busines processes?[2]

Asking good questions is still a great start, but you need to ask different questions.

While focused, detailed, targeted questions can be very effective for scoping down a tactical problem to deliver a fix, they tend to not be great for understanding a broader problem domain. Ask closed-ended questions when you want to deliver a fix; ask open-ended questions when you want to understand the problem.

What does your current process look like, where are the places where you struggle, what are the triggers that would cause you to begin the process, why do you do it that way, who works with the output you produce, and what do they do with it… that sort of thing.

If you’re used to asking the first sort of question, the second sort may not be obviously useful. What would you do with these answers? How can you act on them?

The short answer is “it’s complicated” and the longer answer is “read The Customer-Driven Playbook by Travis Lowdermilk and Jessica Rich.”

This amazing book presents a “hypothesis progression framework” that includes tools for learning about customers and their problems before building a solution to those problems. This framework is broken down into four phases:

At the risk of oversimplifying 250 pages of expert guidance, the framework looks something like this:

  • Who is my customer, what does she do, what motivates her, and what problems does she have?
  • What is the scope of my customer’s problem, how does it affect her, and what is its impact?
  • How well the concept you’ve come up with to solve to solve the problem actually fit with your customer’s needs, does its value proposition motivate her to learn more, and how will the limitations of the concept reduce its value?
  • How well does the product or feature you’ve built to implement the validated concept actually solve the customer’s problem it was built to solve?

Each of these phases is presented with best practices for asking the right types of questions of the right people in the right way, with guidance for formulating the right questions, asking them in structured experiments so you can better trust the answers you get, and then making sense of what you’ve heard. That sensemaking process is where your deep expertise in the solution domain will help you the most, as you look closely and mindfully at what you you’ve heard and decide how to act… but most of the process is about learning the details and nuances of the problem, not about solving it.

Albert Einstein once said “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” Think about that.

In my experience most technical professionals don’t value and appreciate the importance of the problem domain, and instead focus their energies on solutions to problems they don’t fully understand. We can do better, as individuals and as teams and as an industry, and The Customer-Driven Playbook is an excellent place to start. I hope you’ll read it, and I hope you’ll let me know how it changes the way you approach problems and solutions.


[1] Does BI Polar count as a Power BI-focused blog? These days it feels like I’m posting more about ancillary topics and less about Power BI itself.

[2] For that matter, what if you need to deliver a complex commercial software product like Power BI?

Between the problem domain and the solution domain

In a recent post I mused about problem domains and solution domains, how they’re context-dependent, and how interesting things tend to happen at the intersection of a problem domain and a solution domain.

In this post I’m going to talk more about that intersection, and I’m going to start by putting it into a personal context: my job. For the past[1] few years I’ve been a member of the Power BI customer advisory team (Power BI CAT) at Microsoft. After spending almost a decade as a PM shipping data products and services, moving out of a feature role was strange, but I quickly realized this was the perfect place for me to work, and to shine, mainly because I was literally livin’ on the edge[2]… between the problem domain and the solution domain.

Early in 2021, we realized that the CAT team had grown significantly enough during the pandemic that we should organize a virtual “offsite” meeting for the team. There were more and more team members who had never met each other[4], and we wanted to invest in a sense of shared purpose and team identity.

To this end, some of the more tenured members of the team put together an agenda to cover the most important topics. I built a single slide to show “this is who we are, and this is what we do” to share my perspective and spark conversation. This is that slide:

The Power BI CAT team recognizes that the customer is the authoritative expert on the problem domain. They live it day in and day out, and their reality working with Power BI is their lived truth. We can work to understand it, and we can work to make their experience better, but they’re the experts. They get the final say.

We also recognize that the Power BI product team is the authoritative expert on the solution domain. The product team ultimately decides what features and capabilities to ship, how to scope them, and how to prioritize them[5]. They also decide the implementation of each feature – the product team writes the code, which is about as authoritative a perspective as you can get.

The CAT team stands in the middle, with one foot planted firmly in the problem domain and another firmly in the solution domain. This is a key reason why we’re able to be so impactful with such a relatively small number of team members. Although we are not the authoritative experts on either side[6], we are well-informed participants with a deep understanding of both sides. Customers often have a meaningful understanding of the solution domain and product team members typically have a meaningful understanding of the problem domain; the CAT team’s position gives us a unique perspective and advantage.

One of our team’s core function is to “build better customers.” Please keep in mind this is my personal phrases, not anything official, but I believe it effectively describes what we do. The CAT team works with some of the biggest customers in the world – enterprise customers who are pushing the limits of what Power BI and the Azure data platform do. Sometimes these customers need help, because no one has previously done what they’re trying to do. With our team’s expertise and our deep connections with the product team we can help them achieve their goals to be successful today – and as part of the same engagements we help the product team improve Power BI so that the next time a big customer is trying to do that same difficult thing, they don’t need to ask for help.

A key aspect of this function is scale. If we work with one customer to help one customer, we’ve missed a vital opportunity. To increase our team’s impact we’re continually looking for opportunities to work with one customer and help every customer. This scaling might take the form of community engagement via blogs or YouTube, or Microsoft Learn courses on commonly-needed topics like DAX and effective report design, or the Power BI guidance documentation or the Power BI Adoption Roadmap…. the list goes on and on. The team culture encourages members to ask themselves “does it scale” and to look for ways to make the answer be “yes” as often as possible.

The team’s other core function is to “build better product.” As we help customers in our ongoing engagements we’re learning from them, and we take what we learn back to the product team in a variety of structured and unstructured ways. One of my favorite books, The Customer-Driven Playbook[7]describes this process as “sensemaking”:

Sensemaking is a process that ensures we organize the data we collect, identify patterns and meaningful insights, and refine them into a story that compels others to action.

I absolutely love this quote, because for me it elegantly captures the core of what I try to do every day. Members of the CAT team are typically technical professional with significant personal experience, and we bring that to our jobs. What we don’t bring is an agenda. We’re careful in our work with the product team to curate what we learn from customers, and to represent both the “what” and the “why” of their goals and challenges, with the goal to compel the product team to take action to address the customers’ needs[8].

(yawn)

If you’ve made it this far, you may be asking what this has to do with you. Why should you care what’s going on behind the scenes at Microsoft, even if you use Power BI?

You should care because the role of the Power BI CAT team – standing with one foot planted firmly in the problem domain and another firmly in the solution domain – is a success pattern that you can and should generalize in your efforts to build a data culture. Your center of excellence fulfils role similar to that of the CAT team, sitting between the internal customers who are trying to use data to solve business problems and the teams responsible for building and maintaining data systems and tools in your organization.

The details will be different, because the details are always different – but the pattern can be applied wherever there is a group of people with solutions that are relevant for different groups of people with problems.

Last month I had a chance to work with MVP Chris Wagner, an analytics architect who leads a data enablement and community team at Rockwell Automation. As part of a presentation that he and I delivered for Rockwell’s BI community, Chris presented this slide:

He stole my slide! And I could not be happier to see it.

Chris recognized that my mental model for the Power BI CAT team aligned closely with his mental model for how technical community works at Rockwell… and as they say, plagiarism is the highest form of flattery.  If your job or your team has you standing on the border between the problem domain and the solution domain, you should feel free to steal my slide too.


[1] Checks watch… oh my goodness it’s been almost four years. Anyway…

[2] Eat your heart out[3], Aerosmith.

[3] Also apparently Dio.

[4] I’m pretty sure the team has nearly doubled in size since then, so maybe it’s time to have another offsite. I wish we could do this in person again. Please get vaccinated if you’re able to get vaccinated, so you will be part of the solution instead of being part of the problem.

[5] If you’re interested in somewhat dated but still wonderful and relevant insights into how the Power BI product team makes these decisions, please watch this 2019 presentation from Will Thompson.

[6] I’m always skeptical when someone describes himself as an “expert” on anything other than their own lived experiences, because the more I learn about a subject the more I realize how little my knowledge encompasses the subject as a whole.

[7] You should read this book. If you’ve already read it, you should probably read it again because you’ll learning something new each time you do.

[8] Although no modern cloud service or commercial software product will every be “done” I believe there is strong evidence to say that we’ve been pretty successful so far. Over the past few years I’ve had scores of customers tell me that “we know that if something we need isn’t in Power BI today, it will be there next month, or six months from now.” The real credit for this earned trust goes to the product team, but it feels pretty nice to be part of that story.

Problem Domain, Solution Domain

I’ve been thinking about problem domains and solution domains a lot lately. I’ve posted on this topic before, but the more I think about it, the more I think I should explore it more. Starting now.

Image of interlocking puzzle piece hearts from https://pixabay.com/illustrations/puzzle-heart-love-two-hearts-1721619/
When the right problems meet the right solutions, it can be magical

Let’s begin by defining our terms.[1]

A problem domain is a subject area where people work.

If you’re a business intelligence or data professional, the problem domains of interest are often a business function like finance, supply chain or HR. The problem domain experts[2] are typically people who are work in one of these fields, and who might come to you looking for solutions, or for help building solutions.

A solution domain is also a subject area where people work.

If you’re a business intelligence or data professional, the solution domains of interest are often some combination of data visualization, data modeling, data transformation, and so on. They may also be DAX, Power Query, Power BI, or another specific set of tools and technologies.  The solution domain experts[3] are typically people who build data and BI applications and systems to solve problems in other problem domains.

On the other hand, if you’re a member of the Power BI product team[4], the solution domain you’re working in is commercial software development – and the problem domain of interest is building, deploying, monitoring, and/or administering Power BI solutions. Everything is relative, and whether a given subject area is a problem domain or a solution domain is a function of the context in which it is being evaluated.

Let’s pause to let that sink in for a minute. None of the information above is particularly new, and it may not seem profound at first glance, but these two terms are some of the most foundational concepts of building a data culture.

A successful and mature data culture is the product of the right people doing the right things with the right data as part of the right processes.[5] This means that a successful and mature data culture involves solution domain experts and problem domain experts having healthy partnerships and mutual respect… which is also a foundational concept that sounds simple until you look at it more closely.

If you think about the traditional relationship between business and IT, “partnership” probably isn’t the first word that leaps to mind. All too often this relationship is characterized by conflict and a lack of mutual respect that is in part a function of misaligned priorities. Like many entrenched conflicts it is also partly a function of history and  the mistrust produced by historical wrongs – actual or perceived.

Most interesting things – interesting conversations, interesting projects, interesting jobs and careers – exist at the intersection of the problem domain and the solution domain. Interesting things happen at the edges where one thing ends and another thing begins. This is where complexity is found, because multiple domains are involved and making sense requires experts in each domain.

Unfortunately this is also where things tend to go wrong. Too often things fall into the cracks between the problem domain and the solution domain. Experts in one domain don’t value the other part of the picture, or they don’t see it as their job, or they assume that someone else will figure that part out… or maybe it’s none of these things, and they just lack the vocabulary and the context to close that gap.

Please take a moment to think honestly and critically about the problem domains and solution domains in which you operate, and your relationships with the folks in other domains with whom you interact. This is all I have for today, and although I don’t know exactly where I’m going down this path, I know I’m not done – and I know a little introspection can go a long way.


[1] These are my personal definitions that I’m making up as I write this post. You’ll find other definitions if you’re willing to go looking, and although those definitions will align broadly with these, they will have different emphasis and context and nuance because they’re not mine.

[2] The subject matter experts in a given problem domain.

[3] The subject matter experts in a given solution domain.

[4] Or another team building commercial tools for data and analytics.

[5] And the state in which these things are the norm and the exception.

Rebranding Data Governance

To successfully implement managed self-service business intelligence at any non-trivial scale, you need data governance. To build and nurture a successful data culture, data governance is an essential part of the success.

Despite this fact, and despite the obvious value that data governance can provide, data governance has a bad reputation. Many people – likely including the leaders you need to be your ally if you’re working to build a data culture in your organization – have had negative experiences with data governance in the past, and now react negatively when the topic of data governance is raised.

They now treat data governance as a four-letter word.

Stakeholders’ past experiences can make your job much more difficult as you attempt to work with them to enable managed self-service within an organization. Governance is what they need. Governance is what you want to help them achieve. When you say “governance” you’re thinking about erecting guardrails rather than roadblocks, about making it easier for people to do the right things when working with the right data… but that’s not what they hear.

The label shouldn’t really matter – but it does.

Data governance, and building a data culture in general, is as much about people as it is about processes and technology, and that means effective communication is key. Effective communication requires a shared vocabulary, and a shared understanding of the meaning of key words.

It may be time to think about rebranding. Not unlike how a corporation with a reputation for all the wrong things might change its name in an effort to leave all those negative connotations behind without really changing its ways, maybe we need to rebrand data governance… at least some of the time.

My idea when starting to write this post was to propose “Data Culture Enablement” as the more friendly label, but as I was searching around for related content[1], I found that Dan Sutherland of EY proposed something simpler: Data Enablement.

Dan’s post is coming at things from a different angle, but it’s clear he has a similar goal in mind: “emphasiz[ing] empowerment, innovation and instant business value consumption.”

While I was searching, I found a few more interesting articles out there – they’re all well worth your time to read if you’ve made it this far:

Finally, in an interview with Data Quality Pro, data governance coach Nicola Askham emphasized the positive aspects of data governance:

People think governance is about somebody with a big stick but it’s not. It’s about getting people to communicate and talk about their data and being in a position to ask for what they need with their data. The people on the other end need to understand they have a responsibility to meet that requirement if possible.

But when asked explicitly about coming up with a new term, she replied “For a while, I toyed with the idea of starting a campaign to re-name it but I didn’t think it was worth adding to the confusion surrounding the term by coming up with another title.”

She’s probably right.

But because of the negative connotations that the term “data governance” carries today, we should all exercise care when we use it. We should be careful to ensure that the meaning we’re trying to convey is clearly received – regardless of the terms we’re using.

That feels like an ending, but I’m not done. I want to close with story.

Five years ago I was working on a data governance product, and as part of that work I talked with lots of customers and with Microsoft customer-facing employees. In those conversations I frequently heard people say things to the effect of “don’t use the ‘G word’ when you’re meeting with this leader – if you say ‘governance’ he’s going to stop listening and the meeting will end.” This didn’t happen in every conversation, but it happened in many.

Last month I hosted a multi-day NDA event with senior technical and business stakeholders responsible for adopting and implementing Power BI and Azure Synapse at some of the biggest companies in the world. The event was focused on Power BI and Synapse, but the customer representatives kept bringing up the importance of data governance in session after session, and conversation after conversation[3]. It was like night and day compared to the conversations I had when I was trying to get people to care about governance.

Has the world changed that much, or am I just talking to different people now?

I think it’s probably a bit of both. The world has definitely changed – more and more organizations are recognizing the value and importance of data and are increasingly treating data as an asset that needs to be managed and curated. But these days I also engage mostly with organizations that are atypically mature, and are further along on their data culture journey than most. With this selection bias, it’s probably not surprising that I’m having a different experience.

I’ll close with a question and a thought: Who are you talking to about data governance?

Before you begin any data governance conversation, do your best to have a clear understanding of your audience and your goals in communicating with them. No matter what terms you use, it will make all the difference.


[1] I’m always terrified that I will post something that someone else has already posted. On more than one occasion I’ve completed and published a new post, only to find out that I had written the same thing months or years earlier on this blog. Sigh.

[2] I’m pretty sure I’ve referenced this post before. It’s good enough to reference again. You should read it again.

[3] Thankfully we had also included some key folks from the Azure Purview team as well.

Data Culture and Digital Transformation

One of the key success factors for organizations to thrive today is adopting modern self-service business intelligence tools and transforming their businesses to become more agile, more automated, and more data driven. For years technology vendors and industry analysts have thrown around the term “digital transformation” to broadly describe this phenomenon, and technology has matured to catch up with the hype.

Cheesy graphic of zeroes and ones - Image by Gerd Altmann from Pixabay

I use the term “hype” here deliberately. In my experience the term “digital transformation” has been thrown around in the same way as the terms “cloud” and “big data” were thrown around, just a few years later. The cynical part of my brain initially categorized it as “marketing bullshit,” but the intervening years have shown me that this wasn’t actually the case. Digital transformation is real, and it’s a key driver for a successful data culture with real executive support.

Over the past few years I’ve had hundreds of conversations with executives, decision-makers, and business and technical leaders from hundreds of enterprise Power BI customer organizations. These are real people working to solve real problems, and they come from a broad range of industries, geographies, and levels of maturity. I learned a lot from these conversations, and have done my best to help Power BI improve based on what I learned[1], but when I step back and look at the bigger picture there’s a significant trend that emerges.

Stakeholders from organizations that adopt Power BI[2] as part of a digital transformation describe more mature data cultures, and a greater return on their investments in data and analytics.

As you can probably imagine, once I saw this correlation[3], I kept seeing it again and again. And I started looking more closely at digital transformation as part of my ongoing work around data culture. Two of the most interesting resources I’ve found are articles from the Harvard Business Review, which may not be the first place you think to look when you’re thinking about Power BI and data culture topics… but these two articles provide important food for thought.

The first article is almost six years old – it’s from 2015, and focuses on The Company Cultures That Help (or Hinder) Digital Transformation. In the article, author Jane McConnell describes five of the most difficult obstacles that prevent organizations from adopting the changes required by a digital transformation:

(Please feel strongly encouraged to click through and read the whole article – it’s well worth your time, and goes into topics I won’t attempt to summarize here.)

I suspect these challenges sound as depressingly familiar to you as they do to me. These obstacles weren’t new in 2015, and they’re not new now – but they’re also not going away.

Jane McConnell goes on to identify what characteristics are shared by organizations that have overcome these obstacles and are succeeding with their digital transformations. The alignment between her conclusions and this blog’s guidance for Building a data culture with Power BI is striking[4]:

  • A strong, shared sense of purpose alleviates many obstacles, especially those of internal politics. When an organization has a clearly defined strategy, it is easier for everyone to align their work towards those strategic goals, and to justify that work in the face of opposition.
  • Freedom to experiment helps people prioritize, make decisions, and rethink how they work. Having a culture where data governance takes the form of guardrails and effective guidance, not roadblocks, is key to driving meaningful positive change.
  • Distributed decision-making gives people at the edges of organizations a voice in digital transformation. Although there is a need for centralized decision-making and control for some aspects of a data culture (data sources, applications, policies, etc.) the real power of managed self-service BI comes from letting IT do what IT does best, and letting business experts make informed business decisions without undue governance.
  • Organizations that are responsive to the influence of the external world are more likely to understand the value digital can bring. My customer engagements don’t provide any insight to share on this specific point, but I suspect this is significant too. Organizations that are not responsive to external factors are unlikely to make it onto my calendar for those strategic conversations.

In her conclusion, Jane McConnell suggests that readers who see these obstacles in their way should “find ways to transform your work culture using digital as a lever.” In the context of the Harvard Business Review’s target audience, this advice makes a lot of sense.[5] If you are a senior business leader, shaping the work culture is something you are empowered and expected to do. If you’re not, this is where having an engaged and committed executive sponsor will come in handy. If you don’t already have that sponsor, framing your conversations using the vocabulary of digital transformation may help in ways that talking about data culture might not.

The second HBR article I found valuable and fascinating in the context of digital transformation and data culture is written by Randy Bean and Thomas H. Davenport and titled Companies Are Failing in Their Efforts to Become Data-Driven. This one is more recent, and focused more closely on the data side of things.

(As with the article discussed above, please feel encouraged to click through and read this one too. Both articles are written by professionals with significant experience, and an informed strategic perspective.)

This article starts off with a excellent statement of fact:

Whether their larger goal is to achieve digital transformation, “compete on analytics,” or become “AI-first,” embracing and successfully managing data in all its forms is an essential prerequisite.

It then goes on to inventory some of the ways that organizations are failing to deliver on this essential prerequisite, including “72% of survey participants report that they have yet to forge a data culture.”[6]

I’ll let you read the source article for more numbers and details, but there is one more quote I want to share:

93% of respondents identify people and process issues as the obstacle.

If you’ve attended any of my “Building a data culture with Power BI” presentations, you’ll know that I break it down into two main sections: the easy part, and the hard part. Spoiler alert: The easy part is technology. The hard part is people.

The article by Bean and Davenport includes a lot of insights and ideas, but not a lot of hope. They’ve talked to senior data leaders who are trying various approaches to build data cultures within their enterprise organizations, but they all see a long march ahead, with hard work and few quick wins. Technology is a vital part of the transformation, but people and culture is necessary as well.

Building a successful data culture requires top-down and bottom-up change. If you’re in a position of authority where you can directly influence your organization’s culture, it’s time to roll up your sleeves and get to work. If you’re not, it’s time to start thinking about the changes your can make yourself – but it’s also time to start thinking about how using the vocabulary of digital transformation might help you reach the senior leaders whose support you need.


[1] This is your periodic reminder that although I am a member of the Power BI Customer Advisory Team at Microsoft, and although I regularly blog about topics related to Power BI, this is my personal blog and everything I write is my personal perspective and does not necessarily represent the views of my employer or anyone other than me.

[2] I assume that this holds true for other modern BI tools, but since I’m only talking to Power BI customers I can’t really say. And since Power BI continues to increase its lead over the competition…

[3] Not causation.

[4] The bolded text in this list is taken from the HBR article; the rest of the text is from me.

[5] Even if the use of “digital” is sooooo 2015.

[6] Now I wish that I had found this article before I started my data culture series, because I definitely would have used “forge” instead of “build” as the verb everywhere.

The Blind Men and the Data Elephant

Are you familiar with the parable of the blind men and the elephant?

elephant-skin-245071_640
Would you have known this was an elephant, just from this picture?

Sometimes it seems to me that the world of business intelligence – and self-service business intelligence in particular – is made up of blind men feeling their way around a elephant made up of technology and people, each of them feeling something different but none of them able to effectively communicate to the others what they are experiencing.

This blog post was inspired by this email, sent by a technical job recruiter:

Data leader recruiter email
What does this email tell you about the role and the company?

More specifically this blog post was inspired by a tweet[1] from Power BI consultant Jeff Weir, in which he shared this recruiter’s email:

2020-01-18-14-16-43-964--msedge

In this conversation Jeff and I each took the role of a blind man, with this data analytics manager position playing the elephant. Jeff and I each reached very different conclusions.

Jeff may have[2] concluded that Power BI as a tool wasn’t ready for the job, or that that this company wasn’t fully committed to doing what it takes to build a successful data culture, including the right training for their Power BI creators and consumers.

I reached a different conclusion, and I the more I read and re-read the recruiter’s email the more I believed that my initial conclusion is correct: this is an organization that is stepping back from solutions to ensure that they’re focused on the right problems. This is an organization that already has tactics, but is willing to admit that those tactics aren’t getting them where they need to go without the right strategy. This is an organization that seems ready to make significant, substantive change.

Why did I reach this conclusion?

The first sentence: “Ultimately Power BI while being a tool they are currently using it is not the only tool they will consider.”[3]

Wow. As an organization they are avoiding the sunk cost fallacy and explicitly stating they’re open to change, even though that change is likely to be disruptive and expensive. Switching BI tools is hard, and it is not a change that is taken lightly. The leaders at this organization are willing to take that hit and make that change, and they’re taking the steps to find the right leader to help them make it… if that leader decides the change is necessary.

The second sentence, with my emphasis added: “Here they are really looking for someone with some strong technical ability, but more so strong leadership and strategy skills.[3]

Wow!  The recruiter is explicitly calling out the organization’s priorities: they need a strategic leader. They need someone to help them define the strategy, and to lead them in its execution. Yes, they need someone with the technical chops to help carry out

The third sentence: “there will be an element of helping there and mentoring the staff members currently in the team.”

Maybe not exactly wow on this one, but it’s clear that the organization knows that they need to build the skills of their current BI team, and they want someone able to help. Something missing here that I would prefer to see[4] is additional information about the size and skill levels of the team today, and what other learning resources the organization makes available.

The third sentence, again: “it is more about getting a grip on the current landscape of the data and what can be done with it, setting a vision and a strategy aligned with product development and then going from there…”

WOW! This sounds like an organization that knows their current path isn’t leading them to success. It sounds like an organization that acknowledges its challenges and is proactively looking for a strategic solution to root causes, not just a band-aid.

But… it also sounds like an organization that needs a Chief Data Officer, not just an Insights and Data Analytics Manager, and based on Jeff’s Twitter comment it sounds like they’re not willing to pay a competitive rate for the less senior position, much less the more senior one. They seem to want parts of a data culture, but don’t  appear willing to invest in what it will actually take to make it a reality

I was originally planning to structure this post around the theme of 1 Corinthians 13:11, but the more I thought about it the more I realized that describing a technical solutions focus as being “childish ways” that you then grow out of really didn’t match up with what I was trying to say.[5] Although to be fair, this post has traveled far afield from what I intended when I started writing, and I’m honestly not certain I ended up making a particularly strong point despite all the words.

Maybe if I’d had more time I could have just said “different people see different things in shared situations because of differences in context, experience, and priorities, and it’s important to take multiple perspectives into consideration when making important decisions.” Maybe not. Brevity has never been my forte.


[1] Please feel encouraged to read the whole thread, as it went in a few different directions that this post doesn’t touch on directly. I also did explicitly ask Jeff’s permission to reference the conversation and image in a blog post… although I doubt either one of us expect it to arrive quite as late as it did.

[2] I qualify my summary of Jeff’s conclusion because I’m only working with the information available to me in the Twitter conversation, and I do not know that this is a complete or accurate summary. I suspect it is at least accurate, but only Jeff can say for sure.

[3] Please pause for a moment to reflect on how difficult it was to type in that sentence without editing it for clarity and grammar.

[4] Yes, I understand that this is an excerpt from one email that shows only the most narrow slice into what is likely a complex environment, and that it is not realistic to expect every aspect of that complexity to be included in three sentences – no matter how long that final sentence might be.

[5] Thanks to everyone who shared their thoughts on Twitter about the wisdom of using a Bible verse in a technical blog post.

Power BI, PowerPoint, and the importance of shared goals

Do you ever get the feeling that you you’re participating in a completely different conversation than the person you’re talking to?

Maybe you are.

Image by Arek Socha from Pixabay
An actual photograph of Matthew’s brain most of the time.

Back in December[1], Power BI MVP Lars Schreiber shared this tweet:

I’ll bet that was a difficult conversation.

Although I wasn’t in the room with Lars and his client, I’ve been in similar rooms having similar conversations on many occasions where it gradually became obvious that my understanding of the meeting’s goals were not shared by the other participants.

Without a shared understanding of goals and priorities, collaboration quickly breaks down.

Without a shared understanding of goals and priorities, activity are falsely equated with progress – for how can you make progress without a chosen destination?[3]

Without a shared understanding of goals and priorities at the beginning, much of what is done will need to be undone and/or redone once the disconnect is identified and rectified. Often it’s not just a matter of going back to the start – it’s worse. The parties that argued against the project[4] the first time will be empowered and emboldened by any delays and false starts, and the greater the impact of the misunderstanding, the more difficult it will be to get things back on track.

In my experience the best thing to do in situations like this is to immediately step back, stop focusing on implementing a solution to a problem, and focus instead on clearly defining the problem that needs to be solved. Once you know not everyone is working on the same thing, ask the questions no one thought to ask before, or which were asked without the right people involved.

The best case scenario is that everyone can quickly get aligned on common goals and priorities – the disconnect was a bump, not a crash.

Even in the worst case scenario, it’s better to ask the hard questions and to avoid pressure to “just keep working” before your strategic goals are reestablished and validated. The sunk cost fallacy will work against you, but it’s important to remember that it is a fallacy.

If you’re six months into a year-long project, it’s hard to admit that you might need to throw away two or three months worth of work, and end up coming in over schedule and over budget. That’s hard, but it’s better than delivering something no one needs at the end of the year having consumed the entire schedule and the entire budget with nothing useful to show for it.

Going back to that tweet, I have every reason to assume that Lars and his client were successful. Even though Power BI and PowerPoint are very different tools, there are many use cases where either one could be applied to great effect… and at the risk of Abraham Maslow rolling over in his grave, if the only tool you have is PowerPoint, every problem starts to look like a presentation.

I suspect that Lars used this shocking statement as an opportunity to start a new conversation, and to explore the problems his client was using PowerPoint to solve. The next time you find yourself in a similar situation… maybe you will too.


[1] Which is also when I started this post. Life has been busy forever.[2]

[2] I added the previous footnote over a year before I added this one. Life has indeed been busy forever.

[3] This makes me think of one my favorite Sun Tzu quotes.

[4] Or other type of effort, but in my experience it’s usually a project.