Category: Career

Looking back: Five years on the Power BI CAT team

On By Matthew RocheIn Career, Communication, Community, Mental Health, Power BILeave a comment

Five year ago this week I joined the Power BI Customer Advisory Team, commonly known as the CAT team.[1]

I didn’t know it at the time, but in early 2018 I made the most positive change in my two-plus decades working in tech. The work since then has often been challenging and difficult, but I have never felt more satisfied or more appreciated[2] than I have on this team. As I’ve shared before, I’ve worked in tech for over 25 years, but my time on this team has been the best of the lot, by a wide margin.

Why has my time on the Power BI CAT team been so amazing? Looking back over the past five years I see five key factors to my success.

A team that needed the unique strengths I bring
In 2018 the Power BI CAT team already had some of the world’s leading experts on Power BI and the Microsoft business intelligence platform. Although I’d been a data professional in my pre-Microsoft career, I was feeling a little stale on the hands-on side of things, and was definitely feeling my share of impostor syndrome as I started my new role.

What I found was that my product management, data warehousing, ETL, and data governance experience filled gaps in the team’s existing strengths. From the beginning I was welcomed and empowered to make suggestions and implement solutions to problems that the team had not previously been able to solve. Given the prevalence of “not invented here syndrome” in some parts of Microsoft, this welcome wasn’t something I could take for granted.

A team with strengths that complement my weaknesses
When I joined the Power BI CAT team I was anything but a Power BI expert.[3] I honestly don’t know why they hired me, because even in retrospect I don’t believe I was a great fit for the team’s priorities when I joined. Although I did bring my own unique strengths, the fact that I didn’t know the difference between Live Connection and Direct Query[4] had the potential to introduce challenges.

The entire team had my back. When I reached out to request assistance or to ask “dumb” questions, everyone stepped up to help out. They valued me and my unique background and perspective. They knew that it was a smart investment to help me get over these “new to space” speed bumps, and to get up to speed on the ins and outs of Power BI. They were right, of course, but given the competitive nature of some past teams, this support also wasn’t something I could take for granted.

A manager who consistently provides opportunity, trust, and support
It’s taken a real effort to keep this post from becoming fawning Marc Reguera fan appreciation, but I cannot overstate the impact made by having a great manager.  I’ve worked for some wonderful and helpful managers over the years, but I have never before worked for anyone with Marc’s gift. He deeply understands people’s strengths – what people are good at and what gives them joy and energy. He then finds high-value problems for them to solve using their strengths, and which align with the evolving goals of the team.

Time and again Marc enabled me to try new things, and provided a safe space for me to work outside my comfort zone. Marc tirelessly promoted my work and the results I delivered, and he consistently pushed me to do more and to think bigger. Marc saw strengths in me that I didn’t recognize in myself, and he gave me the opportunities to exercise those strengths. I put in the hard work, but Marc provided the environment for my work to deliver the most impressive results.

A leader and sponsor who earns and maintains my trust
How has Power BI gone from a new offering in 2015 to being the clear leader in business intelligence for many years running? This is a bigger question than I can answer in a blog post, but a lot of the answer is understanding what customers need, and relentlessly delivering improvements based on this understanding.

When I joined the Power BI team in 2018 we already had well-established channels for listening to users, and a team culture that prioritized acting on user input. What we didn’t yet have was a similarly strong channel to understand what large enterprise customer organizations needed to drive broad adoption and manage a complex user base. Much of what I’ve done since then has been building this channel and expanding on its scope and impact… but what does this have to do with leadership I can trust?

When you’re building a new customer feedback channel, sometimes you’ll learn things that don’t align with the status quo. Sometimes the feedback you’re sharing contradicts current understanding and plans. In my experience this is one of the most telling tests of an organization’s culture. I’ve worked on teams where sharing truths that don’t fit leadership’s narrative was a career-limiting move, but this is not the case on the Power BI team.

Instead, I’ve found the strongest executive sponsorship I can imagine, with leaders who are eager to learn about customers’ lived realities, and who are willing to change plans and priorities based on what they learn. At every step of the way, Arun Ulag and his leadership team have championed my work, and empowered me to make a bigger difference than I could ever had made otherwise. Having an executive sponsor isn’t only important for building a data culture.

A global pandemic that normalized remote work
This factor doesn’t really fit in with the other four, but if I’m being honest with myself I need to include it. Over the past few years I’ve written and spoken publicly about some of my personal mental health challenges, and how I’ve worked to find and apply the unique strengths produced by these challenges.

One challenge I never truly appreciated until remote/virtual work became the norm was how much energy I spent every day on face-to-face social activities. Walking to a conference room, making social chit-chat as people filter into the room, maintaining appropriate eye contact and body language throughout the meeting, walking to the next conference room, and repeating this pattern all day long. I’m exhausted just typing it.[5]

In all seriousness, I probably expended 30-40% of my total daily budget of emotional and intellectual energy[6] on these non-value-add activities. When I was working in person I could get the job done, but when everyone was working remotely I could thrive. It was like someone had removed a great weight I had been carrying so long I didn’t know it was there, and once that weight was gone I had so much more of everything to give.

Patrick seems excited that I made it through my list of Power BI CAT success factors

This post has ended up very different than the post I intended to write when I sat down at the keyboard, but it’s apparently the post that needed to come out. Sometimes you need to share your gratitude for the people and circumstances that have made your life better in important ways, and an anniversary like this is one of those times.

Five years ago I felt like my career had stalled, and it wasn’t clear to me what I should do next. Since I can’t begin to claim that the past five years of growth and success were planned, the next best thing is sharing a personal retrospective. I hope you’ll be able to look at these factors for my successes and find their parallels in your own life. If you find yourself on a team like this, you may want to stay there. If you find yourself on a team that’s the opposite of the Power BI CAT team, you may want to start looking for your next opportunity.

Here’s to another glorious five years.

[1] Let’s get it out of the way early: Yes, the T in CAT stands for Team. No, I don’t care. Work with me here.

[2] Yes, this appreciation includes bigger numbers with dollar signs next to them, but that is definitely not the most important part of the story.

[3] Let’s be honest – compared to most of my CAT counterparts, I’m still not.

[4] Seriously.

[5] I suspect that readers who have autism spectrum behaviors will be nodding along at this point. I know that it’s not just me.

[6] Or spoons, as my teenager assures me the kids no longer say.

The Unplanned Career

On By Matthew RocheIn Career, Communication, Community, Diversity, Presentations, Video3 Comments

If you’ve worked in tech for 25 years, you’ve seen some stuff, and you’ve learned a lesson or two. On October 1st, I presented a new session at Data Saturday Atlanta, sharing the story of my unplanned career, and some of the lessons I’ve learned along the way. This was the first time I presented this very personal session; and I’m incredibly grateful for the full crowd that attended, and for their feedback after the session.

My primary goal for the session is to show that you don’t need a computer science degree to build a successful career in tech – and that our industry needs more people from more non-traditional backgrounds.

My secondary goal for the session is to share some of the sharp edges that are typically hidden when people talk about their careers. Everyone wants to share their highlights, but sharing your own pain and failures is harder. This is important, because too often we’re each comparing our own blooper reel against everyone else’s highlights… and nothing good comes from that.

The Data Saturday event was in-person only[1], but I’d had a bunch of people mention they wanted to attend, but couldn’t make it to Atlanta. So…I packed a camera and microphone and recorded the video on my own.

If you weren’t able to attend, please check out the recording, and please let me know what you think!

[1] Please understand that there is no criticism implied here. Organizing a hybrid event is significantly more difficult than organizing an in-person or online-only event, and focusing on in-person community produced wonderful results.

On building expertise

On By Matthew RocheIn Career, Communication1 Comment

How do you learn a new skill? How do you go from beginner to intermediate to expert… or at least from knowing very little to knowing enough that other people start to think of you as an expert?

This post describes the learning approach that has worked for me when gaining multiple skills, from cooking to sword fighting to communication. This approach may work for you or it may not… but I suspect that you’ll find something useful even if your learning style is different.

Purely decorative stock photo

When I’m building expertise[1] in a new area, there are typically five key activities that together help me make the learning progress I need. They don’t come in any particular order, and they all tend to be ongoing and overlapping activities, but in my experience they’re all present.

Practicing: Building expertise in an area or skill requires actively performing that skill. You can’t become great at something without doing that thing. Practice whenever you can, and look for opportunities to practice things that are outside your comfort zone. If your practice is always successful, this may be a sign that you’re not pushing your self enough, and your progress may be slower than it needs to be.

Studying: It’s rare to learn something completely new. Even if you’re trailblazing a brand new area of expertise, you probably get there by learning about related better-known areas, from existing experts. Read whatever you can, watch whatever you can, listen to whatever you can. Find content that matches the way you prefer to learn, and spend as much time as you can consuming that content. Make it part of your daily routine.

Observing: Find existing experts and watch them work. Where reading books or watching videos exposes you to the static aspect of expertise, being “expert adjacent” exposes you to the dynamic aspect. Mindfully observing how an expert approaches a problem, how they structure their work area, how they structure their day, will give you insights into how you can improve in these aspects.

Networking: Find ways to engage with a community of like-minded people who share your interest in your chosen area of expertise. Not only will these activities provide ongoing opportunities to learn from peers, the questions and problems that other community members share can serve as motivation to explore topics you may not have otherwise thought of independently.

Teaching: Teaching a skill to others forces you to think about that skill in ways that would probably not be needed if you were learning on your own. Teaching forces you to look at problems and concepts in ways that expose your biases and blind spots, and to ask (and answer) questions that would never have occurred to you on your own. Teaching a skill is in many ways the best way to deeply learn that skill.

Please note that these activities aren’t sequential, and no one activity is dependent on the others. In my experience, all five activities are ongoing and overlapping, and each one complements and enables the others.

What does this look like in practice?

I grew up in a family where cooking wasn’t really a thing[2], so I started learning to cook as an adult. Despite this, my cooking and baking have become something of a gold standard for friends and acquaintances. My learning experience looked something like this:

Studying: I bought and read dozens of cookbooks. If a topic or book looked interesting, I bought it and read it. I subscribed to many cooking magazines and read them when they arrived each month and watched pretty much every cooking show I could fit into my schedule.[3]

Practicing: I cooked and baked almost every day. I tried new ingredients and recipes and techniques that I discovered through my study, and figured out what worked, and what I needed to do to make it work for me. I organized fancy dinners for friends as a forcing function, and to keep myself from getting too lazy.

Observing: When I dined in restaurants[4], I would try to sit at the chef’s counter or somewhere I could get a good view of the kitchen, and would mindfully watch how the chef prepared and served each dish.

Networking: I made foodie friends. I talked about food and cooking with them, and occasionally cooked with them as well. Sometimes we’d go to cooking classes together. Sometimes we’d borrow equipment or cookbooks from each other. Eventually we’d invite each other over for dinner. Those were the days…

Teaching: I found opportunities to share what I’d learned with others. When someone would exclaim “Oh my goodness – how did you make this?!?”[5] I would do my best to tell them and show them. Sometimes this was a conversation, sometimes it was a 1:1 tutoring session, sometimes it was a small group class. Each time I learned something about the topic I was teaching because of the questions people asked.

Cooking is just one example, but I have similar experiences for every topic where people have asked me questions like “how do you know all this?” or “how did you get so good at this?” For every area where I have developed a reasonable degree of expertise, it’s because I have done some combination of these things, often over many years. I have every reason to believe that this approach will work for you as well.

Ok… that’s the blog post, but I’m not quite done. Back in January when I started writing this one, I started with the three “content seeds” you see below.

Data Chef

FFS

That’s right. Past Matthew left me the phrase “Data Chef,” the link to the PowerBI.tips video he’d just finished watching, and the phrase “FFS.” Three months later I have no idea how these relate to the topic of building expertise. If you can figure it out, please let me know.

[1] You may have noticed that I’m deliberately using the phrase “building expertise” instead of a different phrase like “learning” or “acquiring a new” skill. I’ve chosen this phrase because the approach described here isn’t what I do when I’m learning something casually – it’s what I’ve done when building a wide and deep level of knowledge and capability around a specific problem or solution domain.

[2] I love my mother dearly, but when I was a child she would cook broccoli by boiling it until it was grey, and you could eat it with a spoon. I never realized that food was more than fuel until I was in my 20s and met my future wife.

[3] Yes, I’m old, in case talking about magazines didn’t give it away. I assume the same pattern today would involve subscribing to blogs or other content sources. Also, can you remember back when you needed to watch TV shows when they were on, not when you wanted to watch them?

[4] Back in the day I used to travel for work a lot, so I ate in restaurants a lot. Sometimes I was on the road two or three weeks per month, which translated into a lot of restaurant dinners.

[5] If you’ve never met me in person and have never eaten the food I make and share, you might be surprised by how often this happens. If you know me personally, you probably won’t be surprised at all.

Risk Management Basics

On By Matthew RocheIn Career, Communication1 Comment

When I began my software career back in the 90s, one of the software-adjacent skills I discovered I needed was risk management. When you’re building anything non-trivial, it’s likely that something will go wrong. How do you find the right balance between analysis paralysis and blindly charging ahead? How do you know what deserves your attention today, and what can be safely put on the back burner and monitored as needed?

This is where risk management comes in.[1]

In this context, a risk is something that could possibly go wrong that would impact your work if it did go wrong. Risk management is the process of identifying risks, and deciding what do do about them.

One simple and lightweight approach for risk management[2] involves looking at two factors: risk likelihood, and risk impact.

Risk likelihood is just what it sounds like: how likely is the risk to occur. Once you’re aware that a risk exists, you can measure or estimate how likely that risk is to be realized. In many situations an educated guess is good enough. You don’t need to have a perfectly accurate number – you just need a number that no key stakeholders disagree with too much.[3] Rather than assigning a percentage value I prefer to use a simple 1-10 scale. This helps make it clear that it’s just an approximation, and can help prevent unproductive discussions about whether a given risk is 25% likely or 26% likely.

Risk impact is also what it sounds like: how bad would it be if the risk did occur? I also like to use a simple 1-10 scale for measuring risk impact, which is more obviously subjective than the risk likelihood. So long as everyone who needs to agree agrees that the impact a given risk is 3 or 4 or whatever, that’s what matters.

Once you have identified risks and assigned impact and likelihood values to each one, multiply them together to get a risk score from 1 to 100. Sort your list by this score and you have a prioritized starting point for risk mitigation.

Risk mitigation generally falls into one or more of these buckets:[4]

  1. Risk prevention – you take proactive steps to reduce the likelihood of the risk occurring.
  2. Risk preparation – you take proactive steps to plan for how you’ll respond to reduce the impact if the risk does occur.

For risks with high risk scores, you’ll probably want to do both – you’ll take steps to make the risk more likely to occur, and you’ll take steps to be ready in case it still does.

Here are a few examples of risks that might be identified when performing risk management for a BI project, along with examples of how each might be mitigated:

  • Risk: A database server might be unavailable due to hardware failure, thus interrupting business operations
    • Possible prevention: Purchase and configure server server hardware with redundant storage and other subsystems
    • Possible preparation: Define and test a business continuity and disaster recovery[5] plan for recovering the database server
  • Risk: You might not get permissions to access a data source in a timely manner
    • Possible prevention: Prioritize getting access to all required data sources before committing to the project
    • Possible preparation: Identify an executive sponsor and escalation path for situations where additional data source access is required
  • Risk: A key team member might leave the team or the company
    • Possible prevention: Work to keep the team member happy and engaged
    • Possible preparation: Cross-train other members of your team to minimize the impact if that key member moves on
  • Risk: Your data center might lose power for a week
    • Possible prevention: Locate the data center in a facility with redundant power and a reliable power grid
    • Possible preparation: Purchase and install generators and fuel reserves
  • Risk: Your data center location might be destroyed by a giant meteor
    • Possible prevention: Um… nothing leaps to mind for this one
    • Possible preparation: Again um, but maybe using a geo-distributed database like Azure Cosmos DB to ensure that the destruction of one data center doesn’t result in downtime or data loss?[6]

You get the idea. I’m not going to assign likelihood or impact values to these hypothetical risks, but you can see how some are more likely than others, and some have a higher potential impact.

Now let’s get back to a question posed at the top of the post: how do you find the right balance between analysis paralysis and blindly charging ahead?

Even in simple contexts, it’s not possible to eliminate risk. Insisting that a mitigation strategy needs to eliminate a risk and not only reduce it is ineffective and counterproductive. It’s not useful or rational to refuse to get in a car because of the statistical risk of getting injured or killed in a collision – instead we wear seat belts and drive safely to find a balance.

And this is kind of what inspired this post:

The “perfect or nothing” mindset isn’t effective or appropriate for the real world. Choosing to do nothing because there isn’t an available perfect solution that eliminates a risk is simply willful ignorance.

Most real-world problems don’t have perfect solutions because the real world is complex. Instead of looking for perfect solutions we look for solutions that provide the right tradeoff between cost[7] and benefit. We implement those pragmatic solutions and we keep our eyes open, both for changes to the risks we face and to the possibility of new mitigations we might consider.

Whether or not risk management is a formal part of your development processes, thinking about risks and how you will mitigate them will help you ensure you’re not taken by surprise as often when things go wrong… as they inevitably do…

[1] Yes, I’m linking to a Wikipedia article for a technical topic. It’s surprisingly useful for an introduction, and any search engine you choose can help you find lots of articles that are likely to be more targeted and useful if you have a specific scenario in mind.

[2] This is the only approach to risk management that will be shared in this article. If you want something more involved or specialized, you’ll need to look elsewhere… perhaps starting with the Wikipedia article shared earlier, and following the links that sound interesting.

[3] If you are in a situation where “good enough” isn’t good enough, you’ll probably want to read more than just this introductory blog post. Are you starting to see a trend in these footnotes?

[4] That Wikipedia article takes a slightly different approach (direct link to section) but there’s a lot of overlap as well. What I describe above as “risk prevention” aligns most with their “risk reduction” and my “risk preparation” aligns most with their “risk retention” even though they’re not exact matches.

[5] The other BCDR.

[6] I had originally included the “giant meteor strike” risk as an example of things you couldn’t effectively mitigate, but then I remembered how easy Cosmos DB makes it to implement global data distribution. This made me realize how the other technical risks are also largely mitigated by using a managed cloud service… and this in turn made me realize how long ago I learned about mitigating risks for data projects. Anyway, at that point I wasn’t going back to pick different examples…

[7] However you want to measure that cost – money, time, effort, or some other metric.

Communicating the voice of the customer

On By Matthew RocheIn Career, Communication, Patterns, Power BI1 Comment

My last post focused primarily on a problem that can arise when there’s a central team that sits between a team responsible for delivering solutions, and teams that have problems to be solved. The advice in that article is valuable[1], but it’s also very general. It also introduces a problem without providing any advice to solve the problem, beyond the not-very-helpful “keep an eye open for this problem behavior playing out.”

In this article I’m going to share some more specific advice to help overcome this challenge if you’re part of that central team. In this article I’m going to share my advice for communicating the voice of the customer.

In my experience, there are four key success factors for effectively communicating the voice of the customer when you’re not really the customer yourself.

Success Factor 1: Understand both the problem domain and the solution domain. Since this is what most of the last set of articles have covered already I don’t plan to re-cover this familiar ground, but it’s still important to mention. If you’re going to act as a bridge between two worlds, you need a meaningfully deep understanding of both.

Success Factor 2: Don’t have an agenda. More specifically, don’t have an agenda other than enabling the success of the the solution team and the customers you enable. In order to speak with the voice of the customer, the people you’re communicating with need to understand that you’re really speaking for the customer, and not for yourself. This doesn’t mean you can’t have an opinion – it means that you need to share the customer’s truth even when it might not support that opinion.

Success Factor 3: Tell a story. If you only share numbers and statistics, you’re leaving the interpretation of those numbers up to your audience, and that audience doesn’t have the context that you do. You’re from the team that understands the needs of the customer – and you’re the one that doesn’t have an agenda. These two facts make put you in an ideal position to tell a story that captures the customer’s scenarios, goals, priorities, and challenges and to ensure that it is received in a way that inspires your audience to action.

Success Factor 4: Include numbers and statistics. If you only tell a story, your audience will often assume that you’re telling your own story to forward your own agenda. Having data available to back up the story, including specific data to back up each key story point, helps overcome any skepticism and ensure that your story can be received, believed, and acted upon. The amount of data you need will depend on factors including how much trust you’ve already earned with your audience, and how well the actions you’re hoping to inspire align with their current goals.[2] 

Somewhere between telling a story and including data[3]  lies including the literal voice of the customer. When you’re meeting with customers, take thorough notes. When possible, record your customer conversations. Then, when preparing to tell your story, have verbatim customer quotes prepared to reinforce they key points of your story. This lets you say “here’s a customer problem I think you need to prioritize solving” and “here’s how these customers have independently described their experiences in their own words.” It’s easy for someone to say that you don’t really understand the customer’s problem, because you’re not really the customer. But it’s hard for someone say that the customer doesn’t understand their own problem.[4] Bringing the voice of the customer to a story is like having another five or six aces up your sleeve, but it’s not technically cheating.

These four behaviors have proven indispensable in my work on the Power BI CAT team, and I see them as success factors in many of the teams I’ve worked with that also operate between the problem domain and the solution domain. If you’re part of a center of excellence or another team that follows this pattern, look for opportunities to incorporate these behaviors into your work. They’ve served me very well, and I suspect they’ll do the same for you.

[1] In any event, I think it’s valuable, but my opinion here may not be coming from a position of neutral impartiality. You can reach your own conclusion.

[2] In my experience, earning and retaining the trust of your audience is a much more important factor than the story or the data. Right now the only advice I can think of here is “act consistently with integrity and transparency” but maybe I can find a blog post on this topic at some point.

[3]  I could call this “Success Factor 5” or even “Success Factor 3.5” but then I would need to go back up and edit the post introduction and I’m far too lazy for that sort of work.

[4] If you do find the solution team you work with saying that the customer’s problems aren’t real, this is a massive red flag that needs to be confronted. In my experience, if this attitude persists it’s time to start escalating or looking for a new team.

Measuring success and satisfaction

On By Matthew RocheIn Career, Communication, Patterns, Power BI1 Comment

Back in 2020 I wrote a post titled “Successfully measuring / measuring success” that talked about a problem without meaningfully describing it, because at the time I didn’t believe that the problem itself was particularly relevant. I was more interested in the pattern, which at the time I thought was “measuring the wrong thing.”

In recent weeks I’ve found myself sharing this post more frequently, and have come to believe that the underlying pattern is actually something else. Let’s look at my beautiful  2010-era chart one more time.

Before Power BI we had PowerPoint, but data is still Power

In this chart, both series represent NSAT[1] scores – basically they’re saying “this is how happy our customers are with a thing.” This sounds pretty simple, but the tricky part is in the details. Who are “our customers” and what is the “thing” they’re happy or unhappy with?

In the context of the chart above, the yellow series was “customer satisfaction with what they got.” The blue series was “customer satisfaction with what we shipped.” Implied in these descriptions and the difference in the two data series is that something happened between the time we shipped something and the time the customers got something, and that the thing that happened was key to the customers’ satisfaction.

Without going into too many details[3], we were shipping a product that was used by partners, and those partners used our product to deliver an experience to their customers. In the FY06 timeframe we started to change the product that we shipped, and the partners used the updated product to deliver an experience that met their customers’ needs. Now they just had to do a little more work to keep their customers happy. As the product changes continued, the partner load increased. They had to do more and more to fix what we gave them and to keep their customers happy. You can see the story play out in the blue series in the chart above.

We were looking at the yellow series, and falsely conflating “customer satisfaction” with “customer satisfaction in what we have shipped to partners.” We didn’t truly appreciate the importance of the party in the middle and their impact, and it ended up causing no end of problems. We were measuring customer satisfaction, but failing to appreciate what it was that customers were satisfied with – and how little that satisfaction related to what we had created.

And this is the pattern I’ve been seeing more often lately.

In my recent post on the role of the Power BI CAT team and how that role has parallels with Power BI centers of excellence, I described a success pattern where a central team serves as a value-add bridge between people with problems and people with solutions.

This pattern is one that I’ve seen provide significant value in multiple contexts… but it also introduces risk of measuring the wrong things, and overlooking real problems. This is a side-effect of the value that the central team provides. Customers are interacting with the work of the central team in addition to[4] the work of the solution team, and it may be difficult for them to understand what part of their experience is dependent on what factors.

In this situation there is a risk of the solution team overlooking or failing to appreciate and prioritize the problems their customers are experiencing. This is  a problem that the “curate” function in the diagram above is designed to mitigate, but the risk is real, and the mitigation takes ongoing effort.

When a member of a solution team works with customers directly, it’s hard to overlook their challenges and pain. When that solution team member hears about customer challenges from an interim party, the immediacy and impact can be lost. This effect is human nature, and the ongoing effort of the central team to curate customer feedback is vital to counteract it.[5]

As mentioned at the top of the article, I’ve seen this pattern more often recently, where a solution team is failing to recognize problems or opportunities because they’re looking at the wrong thing. They’re focused on what their end customer is saying, instead of looking at the bigger picture and the downstream value chain that includes them and their customers, but isn’t limited to these two parties. It’s easy to mistake “customer being happy” for “customer being happy with what we produce” if you’re not keeping an eye on the big picture.

It’s easy to mistake “customer being happy” for “customer being happy with what we produce” if you’re not keeping an eye on the big picture.

If you’re in a situation like this, whether you’re a member of a solution team, a member of a central team, or a member of a customer/consumer team, you’ll do well to keep an eye open for this problem behavior playing out.

[1] You can read this article if you’re curious about NSAT as a metric and what the numbers mean and were too lazy[2] to read the 2020 blog post I linked to above.

[2] I’m judging you, but not too harshly.

[3] I’m being deliberately vague here, trying to find a balance between establishing enough context to make a point and not sharing any decade-plus-old confidential information.

[4] Or in some circumstances, instead of.

[5] Please keep in mind that in most circumstances the central team is introduced when direct ongoing engagement between the solution team and customers can’t effectively scale. If you’re wondering why you’d want a central team in the first place, it may be because your current scenario doesn’t need it. If this is the case, please keep reading so you’ll be better prepared when your scenario gets larger or more complex and you need to start thinking about different solutions.

You are not the customer!

On By Matthew RocheIn Career, Communication, Cooking and Baking, Diversity1 Comment

Unless you’re building a solution for your exclusive personal use, you are not the customer. If you are not the customer, you need to invest in understanding the customer’s motivations, problems, and goals. The right solution for you may not be the right solution for someone else – even someone you may think of as being “like you” – for reasons that may not be apparent until you look more closely.[1]

This is another post looking at problem domains and solution domains, and it’s inspired by a recent non-technical conversation over brunch[2] with some foodie friends. My wife and I had gotten together with friends who love good food – people who we’ve had over for dinner many times over the years, and from whom we’re always delighted to receive dinner invitations. These are people who know how to cook, and who have invested in their kitchens over the years, so they’re well-equipped to cook what they want.

Imagine my surprise when a friend who has a fabulous combi oven[4] in her kitchen kept talking about how much she loved her new toaster oven that was also an air fryer. Or when another friend who is more than capable of making wonderful meals from scratch waxed poetic about how Thermomix now allows you to use community recipes from any region so she can now make that dumpling recipe she’s been looking at… and about how easy it is to make toast in her June smart oven because it recognizes that she’s put a slice of bread into it and knows how dark she likes her toast…

My initial reaction was to point out how all of these toys were unnecessary, because they already had the real tools they needed to do all these things and more[5], but as the conversation went on I realized I was in a tastier version of a very familiar conversation. This was a conversion about pro and self-service tools, and  about persona-appropriate experiences.

Have you ever been in a conversation when someone suggests that “all you need to do” to solve a problem is to use some code-first tool or service, when all you really want is something lightweight and simple? You probably don’t have an environment set up already, and even if you did the proposed tool don’t solve the problem in the way you want to solve it… even though the tool is capable of solving the problem.

Have you ever built a report that gives its users all the information they need to answer their questions, only to find that your target audience doesn’t like or use the report, and instead keep building their own workarounds?[6]

Have you ever found yourself on the other side of that scenario, where someone has given you a report with all of the numbers, but none of the answers?

These are all variations on the same theme: the importance of persona-appropriate experiences. Delivering capabilities is never enough – you need to deliver capabilities via an experience that works for the people who will use it.

Building an experience people want to use requires a meaningful understanding of those people. What are their backgrounds, their skills, their motivations, their priorities, their preferences… as well as the problems they need to solve. There are lots of ways to build this understanding, and they all start with your acknowledging that you are not the customer, and your willingness to spend time understanding the actual customer’s problems before you start trying to solve them.

I’m confident that a commercial restaurant kitchen would have all of the capabilities you would need to prepare breakfast – and more. I’m similarly confident that you would prefer something smaller, less complex, and more familiar – like your own home kitchen – and that if you were only given a commercial kitchen you would soon start looking for alternatives or workarounds that work better for you.

The next time you’re working to solve someone else’s problems – whether you’re building a BI solution or a software product or service – pause to ask yourself if you’re giving a commercial kitchen to a home cook. While you’re paused, also take a minute to remind yourself that you’re not the customer.

[1] The admonition “you are not the customer” was included in some of the first training materials I read when I became a program manager at Microsoft. It took me a few years to understand why this is so important, but now it’s something I think about almost every day.

[2] This was December 2021, our first restaurant meal with friends since December 2019, right before the omicron wave arrived in the Seattle area. Who knows when we’ll be able to dine out again…

[3] Kind of like me. I’ve been cooking and baking as a primary hobby for over 30 years, and have a wonderfully-equipped home kitchen. It doesn’t have every tool or toy I might want, but it has everything I need, and quite a few specialized tools I might not technically need but which make common-enough tasks easier and less time consuming.

[4] A combi oven is an oven that combines convection and steam, and which allows you to precisely control both the temperature and humidity while you’re baking.  This simplifies baking lots of things, from bread to cheesecake, but they tend to be very expensive. They’ve just recently moved from high-end professional kitchens into high-end home kitchens. I don’t own one, but I definitely want one.

[5] Thankfully I had my mask on as we were waiting for our food to arrive, which made it easier for me to keep my damned mouth shut for just one minute, which is not my forte.

[6] Yes, in Excel.

On joining the product team

On By Matthew RocheIn Career, Communication, Power BILeave a comment

Almost two years ago I published a blog post and video on Being a Program Manager at Microsoft, in which I shared some of my personal experience and advice based on my decade plus at Microsoft. I’ve received an incredible amount of feedback[1] on that 2020 post… and now it’s time for a follow-up.

My last few posts have focused on topics related to problem domains and solution domains, including how these concepts relate to Power BI and my work on the Power BI CAT team. What about for people who are currently Power BI or data professionals who might be thinking about changing careers to join the product team? These are pretty abstract concepts – what do they mean to you?

This conversation calls for an analogy, and since I don’t know anything about driving race cars or automotive mechanics, I’m going to use an analogy about race car driving and mechanics[2].

As a Power BI or data professional, you’re like a race car driver.

Your job is to win races. You need to respond to the rapidly-changing demands of the moment to deliver victory for your team[3]. You’re in the spotlight,

As a race car driver, there are two main factors that contribute to your wins and losses:

  1. Your skills as a driver
  2. The performance of the car you’re driving

To win a race, you need to know how to get the most from your car, and make it perform for the conditions on the track, and within the rules of the race.

As a program manager on the product team, you’re like a mechanical engineer responsible for designing, refining and tuning the race car engine.

Your job is to deliver an engine that performs the way your drivers need it to perform, as part of the larger system of the race car as a whole. The race car needs to have the capabilities and characteristics that enable drivers to win races, and the engine is a key part of that… as is the steering, suspension, and whatever other subsystems make up a race car.

Your job is not to drive the race car, and you can excel at your job without ever having won (or driven in) a race.

Re-read that last sentence and pause to let it sink in. If you’re thinking about joining the product team that makes your favorite software tool or platform, you’re also thinking about giving up the day to day job of using that software.

Even more than this, the skills that you’ve built as a race car driver – or as a data professional – are no longer directly relevant. Please don’t get me wrong – if you’ve spent years implementing data and BI solutions this will serve you very well as a program manager on a product team building data and BI tools. But that experience will be valuable in the way that having been a race car driver could be valuable in informing the design and optimization of race car engines.

Having an intimate understanding of – and deep personal experience with – the problem domain can help inform your work in building and improving the solution domain… but your job is no longer what it used to be. You need to learn and master new skills to be successful in the new role, and that means no longer being the expert on the problem domain like you used to be.[4]

This can be a difficult realization and wake-up call for people making a career change, because it means giving up – or at least moving away from – the work they know and love. It can also mean discovering new work and new challenges that they may love even more… but change is hard at the best of times, and it doesn’t always come at the best of times.

I hope this blog post and analogy[5] doesn’t scare anyone off. Working on a product team can be incredibly fun and rewarding – it’s just different from working with the product that the team builds and ships. It’s another situation where the problem domain and solution domain differ in ways that aren’t always obvious until you’ve had a chance to work in both worlds.

Joining the product team after working as a data professional changes your relationship with the product. What used to be your solution domain, where you were the expert responsible for understanding the product and delivering solutions based on its capabilities, now becomes your problem domain. You’re responsible for increasing its capabilities to make it more useful for others to build their solutions, but you’re no longer building those solutions yourself.

 

[1] I continue to believe that this video may have been the best thing I did in 2020. I’ve had dozens of conversations with people around the world who want to be program managers or product manager – at Microsoft or other tech companies, and some of them have already achieved their goal. This feels like I’m actually making a difference in the world when the world is doing its best to make me feel powerless, and that’s like a gift that keeps on giving. I may not be the only one who feels this way. While this post was in draft form waiting to be published, my friend Davide created a website to showcase this video – he even transcribed it! You can check it out here: http://aka.ms/being-a-ms-pm.

[2] Because of course I am. This is an analogy that presented itself to me in one of those conversations mentioned just one footnote earlier, and which works as well as any I’ve found so far.

[3] There are teams in racing, right?

[4] This is where it’s useful to have a person or team responsible for bridging these two worlds.

[5] Another possibly less scary analogy could have involved someone who loves eating becoming a chef in a professional kitchen. Since I know enough about these worlds to be dangerous, I didn’t trust myself to use this analogy without ratholing on lots of details no one but me would care about. Maybe I’ll try that one again when I have more time to think about it…

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.