Common sense solutions to simple problems

Have you ever looked at a problem and immediately known how to solve it?

Have you ever seen that there’s already a group of people who are responsible for solving this problem this problem, and although they’re working on a fix they obviously have not seen the common sense solution that is so apparent to you?

ford-498244_640
I knew we could park here! Problem solved!

Yeah[1].

In situations like these, there are three[2] potential reasons for what you’re seeing:

  1. The other people are just too stupid to to see the simple and obvious solution that’s been sitting right under their noses all this time.
  2. The other people, due to the time that they have spent closely examining the problem and potential solutions, have realized that the simple and obvious solution doesn’t actually address the problem – even though common sense suggests that it should – or that the solution has unintended side-effects that outweigh its benefits.
  3. The other people are responsible for additional problems and solutions across a broader or more strategic scope, and although the simple solution may make sense in isolation, implementing it has been deferred to enable work on other, higher priority problems.

(At this point I feel compelled to point out that this is something I’ve thought about for decades, and I’ve had a draft blog post on this subject for almost a year. I’m not trying to subtweet[3] anyone. I’ve had several people recently reach out to me to make sure that they’re not the reason I tweet periodic reminders that lazy communication is theft, so a disclaimer here feels appropriate.)

In my experience, many people seem to automatically gravitate to the first choice, and that bias seems exacerbated by differences in perspective. If the observer is in a business group and the solution team is in IT – or vice versa[4] – it’s easy for them to miss the complexity and nuance in something that appears simple and straightforward from the outside.

Part of this challenge is inherent in this type of relationship. It’s natural and appropriate to hide internal complexity from external stakeholders. I’m pretty sure I even learned about this in college… not that I remember college[5].

But part of it is the choice we make when we engage in the cross-team relationship. Every time we see a “simple problem” with an “obvious” or “easy” or “common sense” solution we get to decide how to react. We can assume that we know everything important and that the “other guy” is an idiot… or we can consider the option that there might be something we don’t already know.

The choice is ours.


[1] This is less of an actual footnote than a tool to enforce a dramatic pause as you read. Assuming you read footnotes as you go through the post, rather than reading them all at the end. I may need more telemetry to better understand use behavior. Why aren’t any simple problems actually as simple as they first seem?

[2] If you can think of other reasons that aren’t just variations on these three, I would love to hear about them in the comments. My list used to only include the first two reasons, but over the last few years I’ve added the third.

[3] Sub-blog? is that a thing?

[4] There are scores of other variations on this theme – I picked this one because it’s likely to be familiar to the people I imagine read my blog.

[5] Maybe this?

Data culture and the centerline

I’m running behind on my own YouTube publishing duties[1], but that doesn’t keep me from watching[2] 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[3] 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[4], 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…

road-220058_640


[1] 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.

[2] In this case, I watched while I was folding laundry. As one does.

[3] Yes, pun intended. No, I’m not sorry.

[4] Either through knowledge or through ignorance.

Tough love in the data culture

When I shared on Twitter the most recent installment in the BI Polar “data culture” series, BI developer Chuy Varela replied to agree with some key points from the video on executive sponsorship… and to share some of his frustrations as well[1].

2020-01-13-08-46-03-439--msedge

Chuy’s comments made me think of advice that I received a few years back from my manager at the time. She told me:

Letting others fail is a Principal-level behavior.

Before I tie this tough love into the context of a data culture and executive sponsorship, I’d like to share the context in which the advice was given.

At the time I had just finished a few 80-hour work weeks, including working 12+ hour days through a long holiday weekend. Much of that time was spent performing tasks that weren’t my responsibility – another member of the extended team was dropping the ball, and with a big customer-facing milestone coming up I wanted to make everything as close to perfect as possible.

Once the milestone had been met, my manager pulled me aside and let me know how unhappy she was that I had been making myself ill to deliver on someone else’s commitments[4]. She went on to elaborate that because of my well-intentioned extra effort, there were two negative consequences:

  1. The extended team member would not learn from the experience, so future teams were more likely to have the same challenges.
  2. The executive sponsors for the current effort would believe that the current level of funding and support was enough to produce the high quality and timely deliverables that actually required extra and unsustainable work.

She was right, of course, I’ve added two phrases to my professional vocabulary because of her advice.

The first phrase[5] gets used when someone is asking me to do work:

That sounds very important, and I hope you find the right folks to get it done. It sounds too important for me to take on, because I don’t have the bandwidth to do it right, and it needs to be done right.

The second phrase gets used when I need to stop working on something:

After this transition I will no longer be performing this work. If the work is still important to you, we’ll need to identify and train someone to replace me. If the work is no longer important, no action is required and the work will no longer be done.

Now let’s think about data culture and executive sponsorship in a bottom-up organization. How does a sponsor – or potential sponsor – react when a BI developer or analyst is delivering amazing insights when it’s not really their job?

If the sponsor is bought in to the value of a data culture, their reaction is like to include making it their job, and ensuring that the analyst gets the support and resources to make this happen. This can take many different forms[6], but should always include an explicit recognition of the work and the value it delivers.

And what if the analyst who has enabled more data-driven decisions is ready to move on to new challenges? What happens to the solutions they’ve built and the processes that rely on their work? What then?

Again, if the sponsor is committed to a data culture, then their reaction will involve making sure that it becomes someone’s responsibility to move the analyst’s work forward. They will assign the necessary resources – data resources, human resources, financial resources – to ensure that the data-driven insights continue.

If you’re working on helping to build a data culture from the bottom up, there are a few opportunities to apply this advice to that end. Please understand that there is risk involved in some of these approaches, so be certain to take the full context into consideration before taking action.

  1. Work with your immediate manager(s) to amplify awareness of your efforts. If your managers believe in the work that you’re doing, they should be willing to help increase visibility.
  2. Ensure that everyone understands that your work needs support to be sustained. You’ve done something because it was the right thing to do, but for you to keep doing it, but you can’t keep doing it with all of your other responsibilities.
  3. When it comes time to change roles, ask who will be taking over the solutions you’ve built in your current role, and how you can transition responsibility to them.

Each of these potential actions is the first step down a more complicated path, and the organization’s response[7] will tell you a lot about the current state of the data culture.

For the first potential course of action, managerial support in communicating the value and impact of current efforts can demonstrate the art of the possible[8] to a potential executive sponsor who may not be fully engaged. If you can do this for your current team or department, imagine what a few more empowered folks could do for the business unit! You see where I’m going…

If this first course of action is the carrot, the other two might be the stick. Not everyone will respond the way we might like to our efforts. If you’re building these solutions today without any additional funding or support, why would I give you more resources? Right? In these cases, the withdrawal or removal of existing capabilities may be what’s necessary to communicate the value of work that’s already been completed.

Wow, this post ended up being much longer than planned. I’ll stop now. Please let me know what you think!


[1] I don’t actually believe in New Years resolutions, but I am now retroactively adding “start a blog post with a sentence that contains six[2] or more hyperlinks to my goals for 2020[3].

[2] Yes, I had to go back to count them.

[3] Nested footnotes achievement unlocked!

[4] If your reaction at this point is “what sort of manager would yell at you for doing extra work?” the answer is “an awesome manager.” This may have been the best advice I ever received.

[5] I’ve probably never said either phrase exactly like this, but the sentiment is there.

[6] Including promotion, transfer to a new role, and/or adding capacity to the analyst’s team so the analyst can focus more on the new BI work.

[7] Remember that a culture is what people do, not what people say – have I mentioned that before?

[8] The art of the possible is likely to warrant its own post and video before too long, so I won’t go into too much depth here.

Data culture: Executive sponsorship

Continuing on our series on data culture, we’re examining the importance of having an executive sponsor. This is one of the least exciting success factors for implementing Power BI and getting more insights from more data to deliver more value to the business… but it’s also one of the most important factors.

Let’s check it out:

Ok, what did we just watch?

This video (and the series it’s part of) includes patterns for success I’ve observed as part of my role on the Power BI CAT team[1]. and will complement the guidance being shared in the Power BI Adoption Framework.

The presence of an executive sponsor is one of the most significant factors for a successful data culture. An executive sponsor is:

  • Someone in a position of authority who shares the goals having important business decisions driven by accurate and timely data
  • A leader who can help remove barriers and make connections necessary to build enterprise data solutions
  • A source of budgetary[2] and organizational support for data initiatives
skyscraper-3184798_1920
Because executives fly on planes, right?

Without an executive sponsor, the organizational scope of the data culture is often limited by the visibility that departmental BI successes can achieve. The data culture will grow gradually and may eventually attract executive attention… or may not.

Without an executive sponsor, the lifetime of a data culture is often limited by the individuals involved. When key users move to new roles or take on new challenges and priorities, the solutions they’ve developed can struggle to find new owners.

Without an executive sponsor, all of the efforts you take to build and sustain a data culture in your organization will be harder, and will be more likely to fail.

Who is your executive sponsor?

Update: A Twitter conversation about this video sparked a follow-up post. You can check it out here: Tough Love in the data culture.


[1] This is your periodic reminder that this is my personal blog, and all posts and opinions are mine and mine alone, and do not reflect the opinions of my employer or my teenage children.

[2] This aspect of sponsorship is a bigger deal than we’re going to cover in this post and video – organizations fund what’s important to them, and they don’t fund what’s not.

Building a data culture

tl;dr – to kick off 2020 we’re starting a new BI Polar video series focusing on building a data culture, and the first video introduces the series. You should watch it and share it.

Succeeding with a tool like Power BI is easy – self-service BI tools let more users do more things with data more easily, and can help reduce the reporting burden on IT teams.

Succeeding at scale with a tool like Power BI is not easy. It’s very difficult, not because of the technology, but because of the context in which the technology is used. Organizations adopt self-service BI tools because their existing approaches to working with data are no longer successful – and because the cost and pain[1] of change has become outweighed by the cost and pain of maintaining course.

Tool adoption may be top-down, encouraged or mandated by senior management as a broad organization-wide effort. Adoption may be bottom-up, growing organically and virally in the teams and departments least well served by the existing tools and processes in place.

Both of these approaches[2] can be successful, and both of these approaches can fail. The most important success factor is a data culture in which the proper use of self-service BI tools can deliver the greatest value for the organization.

The most important success factor is a data culture

books-1655783_640
There must be a data culture on the other side of this door.

Without an organizational culture that values, encourages, recognizes, and rewards users and teams for their use of data, no tool and no amount of effort and skill is enough to achieve the full potential of the tools – or of the data.

In this new video series we’ll be covering practices that will help build a data culture. More specifically, we’ll introduce common practices that are exhibited by large organizations that have mature and successful data cultures. Each culture is unique, but there are enough commonalities to identify patterns and anti-patterns.

The content in this series will be informed by my work with enterprise Power BI customers as part of my day job[3], and will complement nicely[4] the content and guidance in the Power BI Adoption Framework.

Back in November when the 100th BI Polar blog post was published, I asked what everyone wanted to read about in the next 100 posts. There were lots of different ideas and suggestions, but the most common theme was around guidance like this. Hopefully you’ll enjoy the result – and hopefully you’ll let me know either way.


[1] 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.

[2] Including any number of variations – these approaches are common points on a wide spectrum, but should not be interpreted as the only ways to adopt Power BI or other self-service BI tools.

[3] By day I’m a masked crime-fighter. Or a member of the Power BI customer advisory team. Or both. It varies from day to day.

[4] Hopefully this will be true. I’m at least as interested in seeing where this ends up as you are.

The Power BI Adoption Framework – it’s Power BI AF

You may have seen things that make you say “that’s Power BI AF” but none of them have come close to this. It’s literally the Power BI AF[1].

That’s right – this week Microsoft published the Power BI Adoption Framework on GitHub and YouTube. If you’re impatient, here’s the first video – you can jump right in. It serves as an introduction to the framework, its content, and its goals.

Without attempting to summarize the entire framework, this content provides a set of guidance, practices, and resources to help organizations build a data culture, establish a Power BI center of excellence, and manage Power BI at any scale.

Even though I blog a lot about Power BI dataflows, most of my job involves working with enterprise Power BI customers – global organizations with thousands of users across the business who are building, deploying, and consuming BI solutions built using Power BI.

Each of these large customers takes their own approach to adopting Power BI, at least when it comes to the details. But with very few exceptions[2], each successful customer will align with the patterns and practices presented in the Power BI Adoption Framework – and when I work with a customer that is struggling with their global Power BI rollout, their challenges are often rooted in a failure to adopt these practices.

There’s no single “right way” to be successful with Power BI, so don’t expect a silver bullet. Instead, the Power BI Adoption Framework presents a set of roles, responsibilities, and behaviors that have been developed after working with customers in real-world Power BI deployments.

If you look on GitHub today, you’ll find a set of PowerPoint decks broken down into five topics, plus a few templates.

2019-12-12-12-09-19-166--msedge

These slide decks are still a little rough. They were originally built for use by partners who could customize and deliver them as training content for their customers[3], rather than for direct use by the general public, and as of today they’re still a work in progress. But if you can get past the rough edges, there’s definitely gold to be found. This is the same content I used when I put together my “Is self-service business intelligence a two-edged sword?” presentation earlier this year, and for the most part I just tweaked the slide template and added a bunch of sword pictures.

And if the slides aren’t quite ready for you today, you can head over to the official Power BI YouTube channel where this growing playlist contains bite-size training content to supplement the slides. As of today there are two videos published – expect much more to come in the days and weeks ahead.

The real heroes of this story[4] are Manu Kanwarpal and Paul Henwood.  They’re both cloud solution architects working for Microsoft in the UK. They’ve put the Power BI AF together, delivered its content to partners around the world, and are now working to make it available to everyone.

What do you think?

To me, this is one of the biggest announcements of the year, but I really want to hear from you after you’ve checked out the Power BI AF. What questions are still unanswered? What does the AF not do today that you want or need it to do tomorrow?

Please let me know in the comments below – this is just a starting point, and there’s a lot that we can do with it from here…


[1] If you had any idea how long I’ve been waiting to make this joke…

[2] I can’t think of a single exception at the moment, but I’m sure there must be one or two. Maybe.

[3] Partners can still do this, of course.

[4] Other than you, of course. You’re always a hero too – never stop doing what you do.

Never stop asking “stupid” questions

When I joined Microsoft, the team running my NEO[1] session shared a piece of advice with my “class” of fresh-faced new hires:

“Think of your first year as a grace period where you can ask any question you want, without anyone thinking it’s a stupid question for which you should already know the answer.”

This sounded like empowering wisdom at the time, but the unspoken side of it was damaging. Between the lines, I heard this message as well, and it was this part that stuck with me:

“You’ve got one year to figure things out, and after that you’d better have your act together and know everything – because if you keep asking stupid questions we’ll know that we made a mistake hiring you.”

I hope it’s obvious that this wasn’t the intent of the advice, but I’ve spoken to enough people over the years to know that I’m far from the only one to take it this way.

bored-3126445_640
How Matthew pictures everyone reacting when he asks questions.

In retrospect, I believe that I should have known better, but I let this unspoken message find a home in my brain, and I listened to it. I remained quiet – and remained ignorant – when I should have been asking questions.

Over the past few years[2], I have finally broken this self-limiting habit. Day after day, and meeting after meeting, I’m the guy asking the questions that others are thinking, and wishing they could ask, but don’t feel comfortable or confident enough to speak up. I’m the guy asking “why” again and again until I actually understand. And people are noticing.

How do I know that others want to ask the same questions?

I know because they tell me. Sometimes they say thank you in the meetings, and sometimes ask their own follow-up questions. Sometimes they stop me in the hall after the meeting to say thank you. And on a few occasions people have set up 1:1 meetings with me to ask about what I do, and how they can learn to do the same.

How do I know that people are noticing?

A few of the people I’ve interrupted to ask “why” have also set up time with me to discuss how they can better communicate and prepare to have more useful and productive meetings.[3] These are generally more experienced team members who appreciate that my questions are highlighting unstated assumptions, or helped them identify areas where they needed a clearer story to communicate complex topics.

I’ve been with Microsoft since October 2008 – a little over 11 years. I’ve been working in the industry since the mid 90s. At this point in my career it’s easy for me to ask “stupid” questions because the people I work with know that I’m not stupid.[4][5]

This isn’t true for everyone. If you’re younger, new to role or new to career, or from an underrepresented group[6], you may not have the position of relative safety that I have today. My simple strategy of “asking lots of questions in large groups” may not work for you, and I don’t have tested advice for what will.

My suggestion is to ask those questions in small groups or 1:1 situations where the risk is likely to be lower, and use this experience to better understand your team culture… but I would love to hear your experience and advice no matter what you do. Just as your questions will be different from mine while still being useful, your experience and advice will be different, and will be useful and helpful in different ways.

Whatever approach you take, don’t be quiet. Don’t stop asking questions.

Especially the stupid questions.

Those are the best ones.

 

P.S. While this post has been scheduled and waiting to go live, there have been two new articles that showed up on my radar that feel very relevant to this topic:

  1. The Harvard Business Review posted on Cracking the Code of Sustained Collaboration and how leaders can build and encourage cultures where these behaviors are rewarded.
  2. Ex-Microsoftie James Whittaker posted on Speaking Truth to Power, which presents critical observations of three eras of Microsoft, with examples of how different generations of leaders have affected the corporate culture.

These are very different articles, but they’re both fascinating, and well worth the time to read.


[1] New Employee Orientation. Sadly not anything to do with Keanu Reeves.

[2] I wish I could say that this was a deliberate strategic move on my part, but it was more reactive. Credit goes to the rapid pace of change and my inability to even pretend I could keep up.

[3] Yes, that means meetings where fewer people interrupt to ask “why.”

[4] I’m waiting for the flood of snarky comments from my teammates on this one…

[5] Or in any event, my asking questions is unlikely to change any minds on this particular point.

[6] If you’re not a middle-aged, white, cisgender man…