You can do it – don’t give up!

After my recent post where I dug into hidden difficulties, I feel like it’s important to share the other side of the story. If you really want to do something, you can do it[1].

It’s easy to look around – especially on social media – and see people making complex and difficult tasks look simple and effortless. It’s also easy to judge your own learning processes, struggles, and failures, against the final edited results of people who have been learning and practicing for years – and to feel disheartened by the comparison.

Please do not fall into this trap – everyone makes mistakes. Take a look at this outtake from my recent video on being a PM at Microsoft:

The final video ended up including around 20 minutes of “talking head” footage, but I had closer to 40 minutes of raw footage before I edited out all most of the mistakes and false starts.

It’s not just me. One of my data community heroes, Power BI MVP Ida Bergum, recently shared a similar example:

If you’re ever feeling like an impostor[2], like there’s no way your efforts could ever measure up to all the “experts” you see online, don’t give up. You can do it.

Every successful example that you see online or at a conference or on a bookstore shelf has gone through the same journey. They may be further down the path – that’s usually the easy thing to see. They also had a different starting point and they probably have a different destination in mind as well, even if it’s close to your goals.

Even if you see someone and think “I wish I…” it’s important to remember that they struggled along the way as well. Odds are they struggled in different ways or in different places, but no one’s journey is free of bumps and detours – even if people usually prefer to share the highlights from the easy parts.

One of my favorite quotes on this subject is from a cartoon alien-dog-thing, and you can find it all over Pinterest:

Picture from https://quotesgram.com/adventure-time-jake-the-dog-quotes/

It never feels great to suck at something you want to not suck at, but everyone sucks at the beginning. Most people just don’t like to admit it – at least not until they’ve moved past the “sorta good” phase.

One overlooked benefit of being earlier on your learning journey is that you can still remember what it was like to suck at something, and what was valuable to you then. If you’ve been doing something every day for 20 years, odds are you may not remember what it was like to just be starting off. But if you are becoming sorta good at something, you have a perspective that you can share with everyone out there who sucks at that thing, and would really like to be sorta good.

Anyway… I didn’t quite figure out how to get the narrative for this post into written form. The story was there in my head, but didn’t want to take shape once I started typing. But I won’t let that stop me, because it doesn’t need to be perfect to be good, and useful.[3]


[1] I’ve included the “if you really want” qualifier deliberately. Motivation and desire are critical for success, because it’s that want that will push you to keep getting back up after you fall down, and will keep you looking for more resources and opportunities to learn and improve.

[2] I still remember the day I first read this blog post by Scott Hanselman. My friend Cheryl had shared it on Facebook, with a comment about how she had thought “it was just me.” I’d known and admired Cheryl for years, and had no idea she felt this way, because I’d only ever seen her kicking butt. This is just another example of why it’s important to talk about mental health.

[3] I swear I didn’t plan this ending, but once it presented itself you’re darned right I was going to run with it.

Diving into the blender

Sometimes things are hard.

Sometimes things are hard, not just hard for you, but just really hard.

And sometimes you can’t always tell which is which, until after the hardship has passed.

This post is something of a personal story, but based on the positive responses I’ve received to my post on being a PM at Microsoft, I suspect that there might be someone out there that might find some lesson or inspiration or something in the story.

In the summer of 2011 I  moved my family from upstate New York to Redmond, WA to join the SQL Server Integration Services[1] PM team. I’d been an SSIS MVP before joining Microsoft in 2008, and this felt like a real dream job. I could help the team finish and ship SSIS in SQL Server 2012, and then make the next version of SSIS better than it could otherwise be.

Except it didn’t quite work out that way.

In reality, I was joining a part of Microsoft that was at the forefront of the massive wave of change that transformed the company into the Microsoft we know today. Everything was in flux, from roles and responsibilities to ownership and processes, to the fundamental questions of what products and services we would build and ship. The 18 months that followed was a series of large and small reorgs, and every time I felt like I was getting my feet under me, everything seemed to change again.

People around me seemed to be rolling with it, and adapting to the new reality. For me, it was chaos, and I floundered. Even though I had worked for Microsoft for three years, this was my first technical PM role. I made it through, but it was one of darkest periods on my adult life. It was hard. It almost broke me, and I thought it was me.

Image by AD_Images from Pixabay
Pixabay didn’t have any pictures of blenders, and this one really captures how it felt.

Later on in 2014 I was working as a program manager on the first generation of Azure Data Catalog, and I was interviewing a new member of the PM team. For the purposes of this story[2] I’ll call this new PM Rick. Rick was a veteran PM who had shipped multiple major features in SQL Server and the first releases of SQL Azure, so he was interviewing the team as much as we were interviewing him.

During the interview, Rick asked me to tell my story – how did I end up where I was, where had I worked, what did I do, that sort of thing. So I told him my story, and when I got to the summer of 2011, he inhaled so sharply that I paused. I looked at him, and saw a look of surprise and respect[3] on his face. He looked at me, and he said:

Damn. You dove into the fucking blender.

He then went on to talk about how in his experience this time and place was the epicenter of unprecedented change and disruption that saw many veterans struggle – and saw many of them decide to look for opportunities elsewhere.

Rick and I worked together for for the next year and a half, and I learned a lot from him over that time. But I think the most important lesson I learned was that it wasn’t just me. I’d thought I was going for a swim in familiar waters, but I had actually dived into a blender, and I managed to get out with most of my extremities still attached.

That’s the story.

I think there’s a lesson in there somewhere about not giving up, about being true to yourself, and about doing what you think is the right thing to do, even when it feels like nothing you do is making any difference on the world of struggle around you. This would be a great lesson, if it’s actually in there.

The lesson that I know is in there is that sometimes things are really hard, and it’s not just you. This isn’t a nice lesson or an easy one, but that doesn’t make it any less real.


[1] SSIS FTW!!

[2] Also because it is his name.

[3] I’m not the best at reading emption, so I honestly don’t know if there was any respect there, but it sounds good so I’m going to roll with it. Rick can correct me if he needs to. He knows where I live.

Foster Kittens and Managed Self-Service BI

My family is a foster family for cats and kittens from the cat shelter where we’ve adopted some of our own cats. Usually a litter will stay with us for a month or two, but it depends on the kittens themselves, and on external factors.

While the kittens are with us, it’s our responsibility to help them grow, both physically and socially. The experts at the shelter are always available if we need help, but for the most part we have the knowledge and tools we need to be successful. In many cases we’re their first real exposure to humans, and we can prepare them to be loving and playful members of a family. Just not our family.

Once the kittens are ready to be adopted, we take them to the shelter, where they will be carefully matched with their forever family. This last part is important – it’s hard enough to let go, and knowing that each of them will find a good home is what makes it possible.

It’s really the best of both worlds – kind of like managed self-service BI with Power BI.[1]

 

Not unlike fostering kittens, managed self-service BI can be the best of both worlds. As an analyst working in Power BI, you can often pick up projects when the scope is still small and manageable, and when you can have fun playing around with the data and seeing what it’s likely to become.

I’m emphasizing the “managed” in managed self-service BI, because it’s best to not be completely on your own. Having someone backing you up, someone with the expertise and resources to get you through challenging spots with a helping hand, is just as important with BI as it is with kittens. An author on his own may make avoidable mistakes with long-term consequences, but a center of excellence or community of practice can provide training up front, and assistance along the way so the finished self-service solution is ready to grow up – and growing up is an important goal.

Just as my family includes our adult cats, that analyst working in Power BI has a day job. If we kept each litter of kittens we foster, things would soon become messy and unmanageable. If an analyst retained ownership of every Power BI solution he developed, he would struggle to stay on top of his core priorities.

Being able to hand off a self-service solution to a central BI team is what gives this story a happy ending. The BI team can give the analyst’s work the long-term home it deserves, and the analyst can get back to his job… while also keeping an eye open for the next self-service BI challenge to come along and steal his heart.

Of all the kittens I have loved, I miss Tiny the most.
Your head. I will bite it now.[2]
If you’re interested in learning more about the shelter where we volunteer, please visit the Meow Cat Rescue web site. Please also consider donating while you’re there – the global pandemic is making it harder for their awesome staff and volunteers to do what they do, and kitten season is upon us. If you appreciate the BI Polar blog and its companion YouTube channel, there’s no better way to say thank you than to donate to Meow. Even a small donation will help.


[1] I hope you saw that one coming

[2] This footage of Tiny attacking my head didn’t fit into the Power Kittens video, but I shared it on Twitter because it was just too cute to not share.

Don’t tell me it’s easy

“This will be really easy for you to do.”

“This is super simple.”

“This shouldn’t take you long at all.”

bulb-1994881_640

Every time you say this to someone, you’re diminishing them.

Every time you tell someone that completing a task or solving a problem will be easy, you’re telling them that you don’t know them and that you don’t care to know.

You’re saying loud and clear “you’re just like me, and if you’re not just like me then tough luck.”

Don’t do this.

Instead, take the time to realize that your experience and perspective may not be universal. Other people may have different perspectives, different strengths and weaknesses, different skills and different knowledge.

Someone with dyslexia may struggle with some common tasks that involve consuming or processing written information, despite reading every day.

Someone on the autism spectrum may struggle with tasks that involve social interaction, understanding the motivations and goals of others, or understanding how their actions will be perceived by others, despite interacting with people every day.

Someone who is short may struggle reaching items on high shelves, despite taking things off and putting things back onto shelves every day.[1]

Despite any hidden difficulties, these struggling people may still show every sign of effortless success. The things that are constantly difficult for them may be part of their day-to-day work. The tasks that challenge and batter and exhaust them may be part of the successes that define their public persona and reputation. But this doesn’t make the struggle any less real. This doesn’t make it easy.

When someone completes a task that would be easy for you, it could be because it is also easy for them. But it could also be because they spent extra hours or days preparing, or that they have special tools and practices that enable their success.

Speaking of tools and practices, let’s get back to those short people. I’m choosing this example because it’s a simple one that everyone will be able to relate to, or at least to understand. Mental and emotional challenges are no less real than physical ones, but they’re often more difficult to communicate and appreciate.

My wife is a foot (30.5 cm) shorter than I am. We both cook a lot, and we share kitchen tasks like cleaning and putting away dishes.

In our kitchen we we use the top of the cupboards as extra storage for large bowls and canisters and such. I can reach these items with ease, although I may need to stand on my toes to get a better grip. Most of the time I don’t even think about it. For me the top of the cupboards is just another handy shelf.

My wife cannot begin to reach the top of the cupboards – what is simple and effortless for me is difficult or impossible for her without additional help or tools. If she needs to get down something from the shelf she needs to walk into the dining room, get a chair, bring the chair into the kitchen, stand on the chair, get down the item she needs, step down from the chair, take the chair back into the dining room, and return to the kitchen to use whatever item she took down.

Think about that: what might take me half a second and a single motion might take her a minute or more, including some potentially dangerous steps along the way.

Of course, the solutions here are as trivial as the problem itself: I get down and put away the things my wife needs, and we are selective in what we store above the cupboards so this is an edge case rather than a common occurrence. But the only reasons we’re able to find this shared path to success is because we recognize the challenge and collaborate to apply our own individual strengths, while acknowledging and minimizing the impact of our individual weaknesses.

When someone’s work appears effortless, it could be because it comes naturally to them, and they may move on easily to their next chore, and the next. But it could also be that the effort is hidden, and that when the work is done they will need a few hours or a few days just to recover from the herculean exertion that you will never see.

You don’t know, and you probably never will.

So don’t tell me it’s easy, even if it is easy for you. Instead, work with me to discover how it can be easier for us, working together.


[1] Hold that thought. I’ll come back to this one.

 

Being a Program Manager at Microsoft

My awesome friend Christopher also works at Microsoft, but his career and mine have taken different paths since we joined. Here we are together back in 2008, before either one of us worked at Microsoft. He’s the one not wearing a Manowar t-shirt.

gateslunch1
No, no, the other one.

Out backgrounds are remarkably similar. We each spent years before joining Microsoft as Microsoft Certified Trainers, with an emphasis on software development rather than systems administration. We each became involved in the MCT community, and in the broader technical community, and to one extent or another this helped us find our first positions at Microsoft.

These days Christopher is working with student developers – I’ve seen him tweeting a lot recently about Django on Twitch, which probably means that he’s still teaching people about software development… or may be watching Quentin Tarantino movies while drinking too much coffee. Honestly, either one is possible.

Anyway… Christopher reached out to me last month and asked if I’d be interested in talking to college students about to graduate about what it’s like being a program manager at Microsoft. I said yes[1], then I said this:

I’ll let the video speak for itself. I tell my story for the first 15 minutes or so, and around the 14:50 mark I talk with Will Thompson and Tessa Hurr from the Power BI team and ask them to share their experiences as well. But there are a few things that I want to add that didn’t really fit well into the video.

First of all, every team has a need for many types of program managers. I’ve blogged about diversity enough that you probably know how I feel about the value of diverse teams, and this applies to PM teams at Microsoft as well. Since this video is targeted at college students and recent college graduates, I’d like to focus briefly on the career diversity dimension.

What does “career diversity dimension” mean? Looking at most PM teams I see program managers falling into three broad groups:

  1. New to career – program managers who are starting their careers after college, or after switching from a non-IT discipline.[2]
  2. Industry hires – program managers who are new to Microsoft, but who have an established career in a related field.[3] This is often someone who has been a consultant, developer or administrator who works hands-on with Microsoft or competitive tools and technologies.
  3. Veterans – program managers who have been at Microsoft long enough to succeed a few times, fail a few times, and understand what PM success can look like on multiple teams.[4]

Reading this list it may be easy to think that there is a progression of value implied, but this is not the case. A successful team will find ways to get from each group the things that only they can contribute. A PM in one group will be able to see things and do things that a PM in other groups will not, and an experienced team leader will be able to direct each PM to the problems that they are best suited to solve, and can add the most value.

The second thing I wanted to add to the video is that each team is different. I said this in the video, but I want to elaborate here. Each team will have its own culture, and some teams will be a better fit than others for a given PM. I’ve worked on multiple teams where I didn’t think I was contributing effectively, or where I felt that my contributions weren’t valued[5]. At one point this culture mismatch almost led me to leave Microsoft, but with the support of my manager at the time I instead found another team in another org where I could thrive.

And this leads me to the the final point I wanted to add: Microsoft is huge. I’ve been a PM at Microsoft since October 2008, but I’ve had 4 or 5 major career changes since then, with very different responsibilities after each change, requiring very different contributions from me.

When I was interviewing for my first position in 2008, the hiring manager asked me why I wanted to work for Microsoft. I already had a successful career as a data warehousing and ETL consultant, and becoming a Microsoft employee would include a reduction in income, at least in the short term. Why give up what I’d built?

I hadn’t expected this question, and my answer was authentic and unscripted, and I’ve thought a lot about it over the past 11+ years. I told him that I wanted to join Microsoft because Microsoft had bigger and more challenging problems to solve than I would ever see as a consultant, and would never run out of new problems for me to help solve. If I joined Microsoft, I would never be bored.

I wanted to join Microsoft because Microsoft had bigger and more challenging problems to solve than I would ever see as a consultant, and would never run out of new problems for me to help solve. If I joined Microsoft, I would never be bored.

And I was right.

If you’re a PM at Microsoft, please share your thoughts and experiences.

If you’re thinking about becoming a PM at Microsoft, please share your questions.

If you’ve joined Microsoft as a PM after watching this video and reading this blog, please send me an email, because I would love to say hi.


[1] It’s a good thing he asked when he did. I haven’t had a haircut since late February, and I don’t know when I’ll let anyone point a camera at my head again…

[2] This was kind of me when I first applied for a position at Microsoft in the 90s, although I already had a few years’ experience. I was not hired.

[3] This was me in 2008 when I was hired.

[4] This is me in 2020. I tend to talk about the successes more, but it’s the failures I think about the most, and where I learned the most along the way. Success is awesome, but it’s a lousy teacher.

[5] Yes, this sucked as much as you could imagine.

Think before you GIF

Animated GIF images are an inescapable part of our online experiences, and more and more tools make it easier and easier to include them in our written communication. Sometimes this can be a good thing.

Sometimes. Not all times.

Before you include a GIF image – especially one that flashes or blinks or strobes – in your next chat message, please pause to consider the impact that this may have on the recipients.

burnout-3721062_640

Before you include a GIF, ask yourself:

  • How many people will see this – is this a 1:1 chat, or is it a large group?
  • Does the GIF include flashing, strobing, blinking, fast-moving images?
  • Do any of the people who will see the GIF have photosensitive conditions like seizures or migraines?
  • Are you sure?
  • Does the software tool you’re using allow users to disable GIF autoplay?

I include this last point because Microsoft Teams does not provide any option to disable GIF autoplay. Seriously – even tough the UserVoice forum for Teams says that this was done in 2017, the Teams UX today does not provide any option for users to prevent GIFs from playing for them.

So if you are on a Teams meeting with 100 people and you post a GIF, everyone sees it. And odds are, that GIF you posted will mean that someone on the call will need to leave the call, or close the chat, or maybe end up in a dark room in pain for the rest of the day.

So please think before you GIF.

You can’t avoid problems you can’t see

The last post was about the dangers inherent in measuring the wrong thing – choosing a metric that doesn’t truly represent the business outcome[1] you think it does. This post is about different problems – the problems that come up when you don’t truly know the ins and outs of the the data itself… but you think you do.

This is another “inspired by Twitter” post – it is specifically inspired by this tweet (and corresponding blog post) from Caitlin Hudon[2]. It’s worth reading her blog post before continuing with this one – you go do that now, and I’ll wait.

Caitlin’s ghost story reminded me of a scary story of my own, back from the days before I specialized in data and BI. Back in the days when I was a werewolf hunter. True story.

Around 15 years ago I was a consultant, working on a project with a company that made point-of-sale hardware and software for the food service industry. I was helping them build a hosted solution for above-store reporting, so customers who had 20 Burger Hut or 100 McTaco restaurants[3] could get insights and analytics from all of them, all in one place. This sounds pretty simple in 2020, but in 2005 it was an exciting first-to-market offering, and a lot of the underlying platform technologies that we can take for granted today simply didn’t exist. In the end, we built a data movement service that took files produced by the in-store back-of-house system and uploaded them over a shared dial-up connection[4] from each restaurant to the data center where they could get processed and warehoused.

The analytics system supported a range of different POS systems, each of which produced files in different formats. This was a fun technical challenge for the team, but it was a challenge we expected. What we didn’t expect was the undocumented failure behavior of one of these systems. Without going into too much detail, this POS system would occasionally produce output files that were incomplete, but which did not indicate failure or violate any documented success criteria.

To make a long story short[5], because we learned about the complexities of this system very late in the game, we had some very unhappy customers and some very long nights. During a retrospective we engaged with of the project sponsors for the analytics solution because he had – years earlier – worked with the development group that built this POS system. (For the purposes of this story I will call the system “Steve” because I need a proper noun for his quote.)

The project sponsor reviewed all we’d done from a reliability perspective – all the validation, all the error handling, all the logging. He looked at this, then he looked at the project team and he said:

You guys planned for wolves. ‘Steve’ is werewolves.

Even after all these years, I still remember the deadpan delivery for this line. And it was so true.

We’d gone in thinking we were prepared for all of the usual problems – and we were. But we weren’t prepared for the horrifying reality of the data problems that were lying in wait. We weren’t prepared for werewolves.

Digging through my email from those days, I found a document I’d sent to this project sponsor, planning for some follow-up efforts, and was reminded that for the rest of the projects I did for this client, “werewolves” became part of the team vocabulary.

2019-10-30-12-37-25-597--WINWORD

What’s the moral of this story? Back in 2008 I thought the moral was to test early and often. Although this is still true, I now believe that what Past Matthew really needed was a data catalog or data dictionary with information that clearly said DANGER: WEREWOLVES in big red letters.

This line from Caitlin’s blog post could not be more wise, or more true:

The best defense I’ve found against relying on an oral history is creating a written one.

The thing that ended up saving us back in 2005 was knowing someone who knew something – we happened to have a project stakeholder who had insider knowledge about a key data source and its undocumented behavior. What could have better? Some actual <<expletive>> documentation.

Even in 2020, and even in mature enterprise organizations, having a reliable data catalog or data dictionary that is available to the people who could get value from it is still the exception, not the rule. Business-critical data sources and processes rely on tribal knowledge, time after time and team after team.

I won’t try to supplement or repeat the best practices in Caitlin’s post – they’re all important and they’re all good and I could not agree more with her guidance. (If you skipped reading her post earlier, this is the perfect time for you to go read it.) I will, however, supplement her wisdom with one of my favorite posts from the Informatica blog, from back in 2017.

I’m sharing this second link because some people will read Caitlin’s story and dismiss it because she talks about using Google Sheets. Some people will say “that’s not an enterprise data catalog.” Don’t be those people.

Regardless of the tools you’re using, and regardless of the scope of the data you’re documenting, some things remain universally true:

  • Tribal knowledge can’t be relied upon at any meaningful scale or across any meaningful timeline
  • Not all data is created equal – catalog and document the important things first, and don’t try to boil the ocean
  • The catalog needs to be known by and accessible to the people who need to use the data it described
  • Someone needs to own the catalog and keep it current – if its content is outdated or inaccurate, people won’t trust it, and if they don’t trust it they won’t use it
  • Sooner or later you’ll run into werewolves of your own, and unless you’re prepared in advance the werewolves will eat you

When I started to share this story I figured I would find a place to fit in a “unless you’re careful, your data will turn into a house when the moon is full” joke without forcing it too much, but sadly this was not the case. Still – who doesn’t love a good data werehouse joke?[6]

Maybe next time…


[1] Or whatever it is you’re tracking. You do you.

[2] Apparently I started this post last Halloween. Have I mentioned that the past months have been busy?

[3] Or Pizza Bell… you get the idea.

[4] Each restaurant typically had a single “data” phone line that used the same modem for processing credit card transactions. I swear I’m not making this up.

[5] Or at least short-ish. Brevity is not my forte.

[6] Or this data werehouse joke, for that matter?

Successfully measuring / measuring success

In 2008 I was hired to solve a problem.

At this point almost 12 years later, the problem itself is no longer relevant[1]. While digging around on an unrelated task today I found this chart, which is. You should look at it now.

2020-03-11-14-44-54-465--POWERPNT
Before Power BI we had PowerPoint, but data was still Power, even back then

The scope of the problem is measured by the blue series on this chart. You should look at it again. Just look at it!

Both the blue series and the yellow series are net satisfaction (NSAT) scores. There’s a lot of context behind the numbers[2], but for the purposes of this post let’s say that on this scale anything over 150 is “time for a team party and a big round of bonuses” and anything under 100 is “you probably won’t include this job on your resume, and you’re thinking about this a lot because you’ve been sending your resume out a lot this week.”

There are two stories that leap out from this chart.

The first story is pretty obvious: something changed in FY06. That change had a dramatically negative impact on the blue series, and a small (and probably acceptable) negative impact on the yellow series.

The second story may not be as obvious, but it’s vitally important: the yellow series was being used to track the impact of the change. Something changed in FY06, and the people that made the change were measuring its impact.

They were tracking the wrong thing.

Until I joined the team, no one had a chart like this. It wasn’t that the blue series wasn’t being tracked – it was. It just wasn’t recognized as the true success metric until things were well into resume-polishing territory.[3]

meme

The lesson here isn’t that someone made a bad decision and didn’t realize it. The lesson is that sometimes the metric you’re tracking doesn’t mean what you think it means.

As is the case in my personal story, the problem is usually quite obvious in retrospect, but it’s also usually quite opaque in the moment. Although most large companies have a culture of measurement, it’s more rare to see a culture that consistently questions those measurements. Although this approach may not work for everyone, I recommend using this three-year-old approach to defining your most important metrics.

I don’t mean that the approach is three years old. I mean that you should approach the problem like a three-year-old would: by repeatedly asking “why?”

When someone[4] suggests measuring using a given metric, ask why. “Why do you think this is the right way to measure this thing?” When you get an answer, ask why again. “Why do you believe that?” Keep asking why – the more important the metric, the more times you should ask why and expect to get a well-considered answer[5]. And if the answers aren’t forthcoming or aren’t credible… that is an important point to recognize before you’ve invested too much in a project or solution, isn’t it?


[1] Which is why I’m not going to talk about the problem or the solution here, except in the most general, hand-wavey terms.

[2] You can read this article if you’re curious.

[3] I should also point out that I wasn’t the person who figured out that we’d been measuring the wrong thing. The person who hired me had figured it out, which was why I was hired. Credit where credit is due.

[4] This someone may or may not be you. But definitely question yourself in the same way, because it’s always hardest to see your own biases.

[5] The person who introduced me to this idea called it “five whys” but I wouldn’t read too much into that specific number. He also never explained what he meant by this, and for months I thought he was referring to some five word phrase where each word started with the letter Y. True story.