Category: Communication

Simplifying the solution domain

On By Matthew RocheIn Communication, Community, Data Culture, Metaphors, Power BILeave a comment

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

On By Matthew RocheIn Communication, Data Culture, Diversity, Power BI4 Comments

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

On By Matthew RocheIn Communication, Data Culture, Power BI5 Comments

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.

Rebranding Data Governance

On By Matthew RocheIn Communication, Data Culture, Data Governance, Power BI6 Comments

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.

The Blind Men and the Data Elephant

On By Matthew RocheIn Communication, Data Culture, Diversity, Metaphors, Power BI1 Comment

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

On By Matthew RocheIn Communication, Data CultureLeave a comment

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.

Thoughts on community

On By Matthew RocheIn Career, Communication, Community, Diversity, Mental Health, Power BI1 Comment

This post is mainly a story about how community has affected my career, and how it might affect yours as well. The post has been sitting in my drafts for a few months waiting for inspiration to strike. That inspiration came in this recent[0] data culture video where I talked about communities of practice inside enterprise organizations, and the ways that positive behaviors can be promoted and encouraged for these internal communities of practice – because the same patterns often apply to public communities as well.

So let’s talk about community.

No, not that Community. Technical community. Community like this:

hand-1917895_640

I started off my tech career as a Microsoft Certified Trainer (MCT) in 1996. I spent much of the next decade as a trainer, mentor, and consultant, but even though I was learning and growing year after year, the pace of that growth felt slow. I quickly became a medium-size fish in a tiny pond[1] and that was pretty much that. My career growth was limited in part by the company I chose to keep.

To be fair, there was an online[3] MCT community where I would often lurk and occasionally post, but I never took real advantage of it. I didn’t feel confident enough to post often, and for some reason traveling to a conference or other in-person MCT event just didn’t feel like something that was available to me – this was something that other people did, not something I could do.[4]

In late 2004 I started thinking about getting back to more training after a few years focusing on software development and consulting. I decided that the upcoming SQL Server 2005 release would be a great opportunity for making this change. Microsoft had made available to MCTs the preview versions of two “What’s new in SQL Server 2005” courses – one for developers and one for admins – and I was going to get certified to teach these courses as soon as they were available to offer. I’d been working with SQL Server since version 6.5, and much of my consulting work included developing solutions on SQL Server 2000, so this was a logical direction that matched my experience, skills, and interest.

To make a long story slightly less long – and because I’ve shared some of the details while this post was sitting in my drafts – that focus on SQL Server 2005 was my jumping off point to become an active member of the MCT and SQL Server communities. I was still doing many of the same things I’d been doing all along, but now I was doing them where more people could benefit, and where more people could see me doing what I did. And people noticed.

People noticed that I knew what I was talking about on technical topics, but mainly people noticed that I engaged in a constructive and helpful manner. That I gave more than I took.[5]

And this brings us to the concept of visibility from that earlier blog post, and the opportunity that comes from being seen kicking ass – being seen doing the great work you do every day. For me, being actively engaged in the MCT community led to my first job at Microsoft. People who knew me because of my community involvement let me know that there was a job I should apply for, and they put a referral into the internal HR systems to make it more likely I would get called for an interview[6], and the rest is history.

For you, being actively engaged in your community – whether it’s the Power BI community or something else – will likely mean something very similar. The details will be different because the context is different, but adding your voice to the communities you frequent is how you let the community know who you are and what you do.

When you answer questions – and when you ask them too – other members of the community will begin to understand what you do, and how you work. When you write a blog post or record a video, more people will begin to understand how you think, and how you communicate. They’ll learn from you, and they’ll learn about you.

This is good.

As more people learn about who you are and what you do, and as more people begin to see and value your contributions, they’ll start thinking about how awesome it would be if you could contribute more directly to their projects and products. For me this meant being asked more frequently to teach SQL Server and SSIS classes, and an increased volume of inquiries about consulting availability.[7] I had more opportunities for more interesting and better paying work because of my engagement with the community, and it changed my life for the better in many ways.

For you it will look different because the context is different, but you can follow the same pattern. Your contributions to the community organically become your resume[8], your marketing web site, your demo reel. Potential employers and potential clients[9] will have a more complete picture of how you work than a job interview can provide, and that can make all the difference.

Implied in this pattern is the positive nature of your community contributions. If you’re a bully or a gatekeeper or engage in other types of abusive behavior… people notice that too. This can become its own opportunity for improvement, because if you’re more mindful about presenting the side of you that you want people to see, the more likely you are to become that better version of yourself.[10]

Engaging with the community changed my life. It can change yours too.

Interesting side note on timing: I joined Twitter ten years ago this month.

At that time I had just accepted a position on the SQL Server Integration Services  (SSIS) product team, and had asked one of my new colleagues where the SSIS community was centered, and he pointed me there. The rest sort of took care of itself…

[0] Referring to this data culture video as “recent” gives you some insight into how long this post languished in draft form after the introduction was written.

[1] This is kind of like saying “big fish in a small pond” but self-aware enough to realize I’ve never been a large fish on any scale.[2]

[2] I am so sorry, and yet not sorry at all.

[3] Two words: Usenet newsgroups.

[4] I’ve thought about this a lot in the intervening years, and believe that the root cause was probably a combination of my rural, poor, opportunity-sparse upbringing, and my mental health challenges, but I doubt I’ll ever know for sure.

[5] I’m generalizing here, and making some big assumptions based on the available evidence. This is what I think people noticed based on the way that they reacted, but only a handful said so. Of course, they typically said so when offering me work…

[6] This is something I have done a few times over the years myself, and there’s no better feeling than knowing I played some small part in helping Microsoft attract new talent, and in helping a member of the community achieve their career goals.

[7] For me it also meant that I roughly doubled my billing rate over the course of 18 months. I had so many inquiries that I was turning down almost all of them because I didn’t have the bandwidth to say yes, and decided to take advantage of the laws of supply and demand.

[8] This 2016-era post from MVP Brent Ozar presents a much more prescriptive approach to this theme.

[9] And potential employees as well, in the fullness of time.

[10] And let’s be honest – if you’re an insufferable asshole who refuses to change, participating in a community is a great way to let people know, so they can know that you’re someone they should avoid hiring, interviewing, or contracting. This is also good.

Never underestimate the voice of the customer

On By Matthew RocheIn Career, Communication, Data Culture, Diversity6 Comments

Most of what I do in my day job involves listening.

A sculpture of men with ears pressed to a brick wall - Image by Couleur from Pixabay
It’s better to put your ear up to the wall than it is to bang your head against it.

Specifically, I spend a lot of time listening to people who use Power BI[1] talk about why they use it, how they use it, and where they struggle along the way. I ask a few questions to get them started, and then I ask a few follow-up questions to help them along as they tell their story – but mainly I listen.

I listen, and then I use what I hear to help make Power BI a better tool for these people and their organizations’ needs.

I listen for patterns and trends, and for a signal to emerge from the noise of hundreds of conversations. When it does, I make sure that the right decision-makers and leaders hear it and understand it, so they can take it into account as they decide where to invest and how to prioritize those investments.[2]

I listen with an informed ear. I spent almost 15 years building software and data solutions, so I understand a lot of the technical and organizational challenges these people face. I spent the next decade or so building data products and services as a program manager at Microsoft, so I understand a lot of the challenges involved in prioritizing and building product features. And perhaps most importantly, I am genuinely interested in listening to and learning from the people with whom I talk. I truly want to hear their stories.

Of course there’s only one of me, and I can’t spend my whole workday listening to people tell their stories… so I’ve helped build a team to listen[3], and it’s making a difference. The next time you see an announcement about new capabilities in Power BI that will improve the lives of large enterprise customers, odds are this team had a hand in making those capabilities a reality.

Why am I telling you all this? This is my personal blog, and I’m not looking for a job, so who cares, right?

You care.

You care because this type of listening is a thing that you can do to make better software. You can do this whether you’re building commercial software or if you’re part of a BI team that needs to build solutions for larger user populations.[4]

You care because letting the people who use your software – or the people you want to use your software – talk about what what’s important to them… will let you know what’s important to them. And if you’re really listening, you can use what you learn to make better decisions and deliver better products and features.

If you’re genuinely interested in the people who use the software you build, you should consider giving this approach a try.

[1] These people tend to be the business and IT owners of Power BI in large enterprise organizations, but they can be just about anyone involved in implementing, adopting, using, or supporting Power BI.

[2] If you’re interested in learning more about the Power BI product team’s planning process, I cannot recommend highly enough this 2019 presentation from Will Thompson.

[3] As part of building that team we all read and/or re-read Lean Customer Development by Cindy Alvarez. If you have not yet read this awesome book, there’s no time like the present.

[4] I honestly don’t know if this type of rigor is appropriate at a smaller scale, because I haven’t done it and haven’t personally seen it done. I suspect that it would be very valuable, but also suspect that there may be lighter-weight options that would provide a better return on investment.

Old videos, timeless advice

On By Matthew RocheIn Career, Communication, Generic Blather, PatternsLeave a comment

It’s 2021, which means my tech career turns 25[1] this year.

It me

Back in 1995 an awesome book was published: Dynamics of Software Development by Jim McCarthy. Jim was a director on the Visual C++ team at Microsoft back when that was a big deal[2]. The book is one of the first and best books I read as a manager of software development teams, and it has stood the test of time – I still have it on the bookshelf in my office[3].

Of course, I wasn’t managing a software development team in 1995. I discovered Jim’s wisdom in 1996 or 1997 when I was preparing to teach courses on the Microsoft Solutions Framework[4]. When I opened the box that the trainer kit came in, there was a CD-ROM with videos[5] of Jim McCarthy presenting to an internal Microsoft audience on his “rules of thumb” for reliably shipping great software. When I first watched them, it was eye-opening… almost life-changing. Although I did have a mentor at the time, I did not have a mentor like Jim.

The second time I watched the videos, it was with my whole team. Jim’s rules from these videos and his book became part of the team culture[6], and I’ve referred back to them many times over the decades.

Now you can too – the videos are available on YouTube:

Some of the rules may feel a bit dated if you’re currently shipping commercial software or cloud services[7] but even the dated ones are based on fundamental and timeless truths of humans and teams of humans.

I’m going to take some time this week to re-watch these videos, and to start off the new year with this voice from years gone by. If you build software and work with humans, maybe you should too.

[1] Damn, that is weird to type, since I’m sure I can’t even be 25 years old yet.

[2] It may also be a big deal today, but to me at least it doesn’t feel quite as much.

[3] Not that I’ve seen my office or my bookshelf in forever, so this assertion should be taken with a grain of 2020.

[4] Fun fact: if you remember MSF, you’re probably old too.

[5] Because in those days “video” and “internet” weren’t things that went together. This may or may not have been because the bits had to walk uphill both ways in the snow.

[6] To the extent the team could be said to have a shared culture. We were all very young, and very inexperienced, and were figuring things out as we went along.

[7] Back in 1995 CI/CD wasn’t part of the industry vocabulary, and I can count on zero hands the clients I worked with before joining Microsoft who had anything resembling a daily build.

Representation and visibility

On By Matthew RocheIn Career, Communication, Community, Diversity4 Comments

tl;dr: We need more representation in tech, in part because career opportunities come from kicking ass where people can see you, and that comes from knowing that you belong, and that knowing comes from seeing people like you already belonging.

Image by Gerd Altmann from Pixabay

Representation is a complex topic. Being a straight, white, cisgender, American man, I don’t have a lot of personal experiences with the lack of representation. But I do have one, and it involves swords.

Back in 2004 a friend of mine sent me a copy of the first edition of The Swordsman’s Companion by Guy Windsor. At this  point I had no idea that people were recreating medieval martial arts and fighting with steel weapons[1], so I read through the book and eventually sold it at a yard sale. I was interesting, and I loved the idea of being able to do what the people in the book were doing, but deep inside I knew that people like me didn’t actually do things like that. I was wrong, of course, but at the time the totality of my life experience told me I was right, and I simply didn’t question this knowledge.[2] Ten years passed before this opportunity presented itself again – ten years in which I could have been studying, practicing, competing, improving.

Now take this almost-trivial example and apply it to your career. What if you had never seen someone like yourself in a job role? How would you know that this was something that you could do, that this was a path that was open for you to travel?

When I look back on my career in IT, I can see tipping points – places where everything changed, and my life was forever improved. All but one of them (we’ll come back to this one) happened because someone saw me kicking ass and said “I want you to come kick ass with me.”

  • In 1996 when Dave saw me excelling as an applications trainer and offered me the opportunity to become a technical trainer and MCT.
  • In 1997 when Jeff saw me teaching Windows NT networking and offered me a job with a much higher salary and responsibilities that included consulting and application development.
  • In 2003 when Carolyn offered me a full-time contract as I was leaving my then-collapsing employer and starting my own consultancy, and when I simply didn’t know how I would pay my mortgage in six months, or pay the hospital bills for my impending second child.
  • In 2005 when Corey saw me teaching a beta SQL Server 2005 course, and said “you need to come work at TechEd this year.”
  • In 2007 when I quoted Ted almost double my then-standard daily rate to get him to quit nagging me about working for him, and he instantly agreed and asked how soon I could start.
  • In 2008 when Ken and Dave told Shakil that I was the only person who could do the job he needed done, and he ended up offering me my first job at Microsoft.
  • In 2011 when Matt learned I was looking for a new role and said “we have an open PM position on the SSIS team – let me introduce you to the hiring manager so you can see if you want to apply.”
  • In 2017 when Kasper kept subtly mentioning how much he loved the team he was on, until I finally figured out he wanted me to join it.

This is my story, and I’m including names both to say “thank you” and to make it real – these are the people who enabled me to be who I am today, where I am today, doing what I love so much today. I’ve heard variations on this story from many of my colleagues and peers, but this one is mine.

Please don’t get me wrong – I don’t believe anyone was giving me any handouts. At every step along the way I was doing the work – I was working hard, pushing, trying, struggling to kick as much ass as I possibly could. I was really good, because I had studied and practiced and put in the long hours to learn and improve – but without these people seeing and recognizing my hard work, the opportunities simply would not have existed for me. At any of these tipping points, if I hadn’t been where these people could see me, the moment would have passed, and the opportunity would have been lost. Each opportunity was dependent on the opportunities that came before it – each one depended on my being where I was, being visible and being seen.

This brings me back to that very first tipping point. In 1996 I saw a classified ad[3] for a job teaching people how to use Microsoft Windows and Office, and I applied for it.

And this brings us back to representation.

I applied for that first job because I could see myself in the role – I knew that I could do it. I had no difficulty picturing my 20-something Christian white male self in that role, and neither did the folks doing the hiring.[4]

But what if I was female, or Black, or transgender? What if I looked at an industry that was overwhelmingly male and overwhelmingly white and overwhelmingly cis, and knew that I didn’t belong, because there was no one like me doing things like that? Would I have opened that very first door, on which every later door depended?

I can’t answer that, but looking at the still-white and still-male faces around me every day in tech, I have every reason to believe that many candidates would see this lack of representation and infer from it a lack of opportunity – and never take that first step. And for those who do take the first steps I only need to look around to see the barriers that the tech industry put in place for women and minorities, letting them know every day that they’re not welcome.

Back in July I shared a post that referenced an amazing webcast by UX Designer Jasmine Orange on “Designing for the Ten Percent.” In that post the link was buried in a footnote, so I want to call it out here explicitly – if you made it this far into my post, you really want to watch this webcast. Jasmine’s premise[5] is that by designing for underrepresented users/communities/audiences/people you end up making better products for everyone.

I believe the same is true of tech in general – by building organizations, teams, and cultures that are welcoming to people who have been traditionally excluded, we build organizations, teams, and cultures that are better and more welcoming for people who have never been excluded. Diverse teams are stronger, more resilient, more agile, and more productive. Diverse cultures thrive and grow where monocultures collapse and die.

Why do I care? Does any of this even affect me directly?

Yes, it does.

On one hand, being part of a diverse team means that I will be more likely to be part of a successful team, with the financial rewards that come with success. On the other hand, I feel more welcome and more at home as part of a diverse team.

Still, it’s not about me, is it?

If you’re considering a role in tech and you’re not sure if you should apply for a job, do it. Even if you don’t feel like you’re a perfect fit, or don’t believe you meet every single requirement in the job posting. The white guys are going to apply because they know they below. You belong too, even if you don’t know it yet.

If you’re coming into tech from an underrepresented minority, you not only belong, you’re vitally needed. You bring something that no one else can bring – your background, your experiences, your perspectives – all the lessons you learned the hard way that an all-male, all-white team might pay an expensive consultant to tell them about after they’ve failed enough times.

Not every employer will recognize this value, but that doesn’t mean it’s not there, or that it’s not real. Some employers will judge every candidate against the “tech bro ideal” and will try to make every hire fit into this mold.

If you’re an employer, don’t be this guy. If you’re an employer, recognize the strategic value of having a diverse team. And recognize that this diverse team won’t happen on its own. Support organizations like Black Girls Code, because this is where your hiring pipeline will come from. Value the diverse perspectives that are already represented on your team, and promote them. Give authority and power to people who will hire diverse candidates. Give authority and power to people who look like the people you’re trying to recruit.

And if you’re working in tech today, please be be the person who notices. When you see someone kicking ass – doing an amazing job and demonstrating talent and potential to do more – be the person who says something. Even if you can’t see yourself in that person. Even if they don’t look like you and the rest of your team.

Representation is important, because it helps more people know that they can open that first door. Visibility is important, because it provides the opportunity for change and growth – visibility is what opens the second door, and the third, and….

Ok…

I started off writing a completely different post, but this is the one that wanted to come out today. At some point in the next few weeks[6] I’ll follow up with a post on community and how community is a key technique for increasing your visibility, but this post has gotten long enough, and then some.

Thanks for sticking with me – I’d love to hear what you think.

[1] I learned in 2014 when I first saw this video and fell in love.

[2] Underlying this false knowledge was likely the experience of growing up rural and poor, and not having a lot of opportunities as a child, or many experiences as an adult. It wasn’t until 2005 when I first travelled to Europe for a Manowar concert that my mindset started to change, but that’s probably not relevant to this post.

[3] Classified ads are what we called Craigslist before it was LinkedIn. Something like that.

[4] At this point I feel compelled to mention my friend Kathy, who actually got the job I applied for. I didn’t get the job, so I ended up taking a job as a bank teller. When the training center had another opening a few weeks later they called me back to ask if I was still available, and I said yes. True story. Hi Kathy!

[5] More accurately, this is my interpretation of Jasmine’s premise.

[6] LOL @ me, and LOL @ you if you haven’t learned by now not to trust any predictions of future output on my part. We should both know better by now.