Diversity of Perspective

I blogged last October[0] about the challenges I faced when trying to use the new Html.Table function in Power Query. A key part of my challenge was the gap between my perspective, and the perspective of the team shipping and documenting this feature.

At first I chalked this off as an old dog[1] trying to learn a new trick[2], but I’ve been thinking about this since then, and I’m not sure that this is the case. I think that it may have been the result of differing perspectives – and differing expectations resulting from those perspectives.

Image by S. Hermann & F. Richter from Pixabay
This may or may not be a photo of Matthew

My perspective is that as a data integration tool, Power Query will work the way that my ~20 years as a data professional have trained me to expect data integration tools will work. If there’s a query language or formula language or expression language that is required to access a specific source, I expect that language to be identified and documented in the tool.

The Power Query team, on the other hand, may have had a different perspective here. I haven’t explicitly asked them[3], but I suspect that their perspective is that it’s 2018, and anyone working with HTML data already knows what CSS selectors are, and either knows how to use them, or where to look to learn enough to use them.

I don’t know which perspective is more valid. Part of me believes that mine is, and bemoans the time I spent struggling to achieve a simple goal, because the documentation didn’t connect the dots for me. But I also note that no one – not in comments here, not on Twitter – has said that they were similarly challenged.

But I can say this: A difference in perspective meant that what was delivered wasn’t what was needed, at least by one user.

Another example of this type of mismatch is one I see too often[4] at conferences: Microsoft presenters using Microsoft’s specialized vocabulary when speaking with non-Microsoft audiences. This typically takes the form of using internal code names and acronyms, rather than official product names – if you’ve been to more than a handful of Microsoft events you’ve probably seen this yourself. I think the worst example I’ve seen was when a presenter mentioned that an upcoming feature was coming “in the scandium time frame.[5]

Every culture – whether it’s centered in a geographical region, a profession, a religion, or a large corporation – has a specialized internal nomenclature. It enables members to communicate more efficiently. This isn’t a bad thing – it’s natural and good, and helps teams and groups deliver on their goals and priorities.

But problems can and do arise when one party doesn’t take the other party’s background into consideration. This is where having a diverse team can help.

When a team has a diverse makeup, it makes it more likely that potential problems will be prevented before they need to be identified, and identified before they need to be fixed.

If you want to be more efficient and to produce products and services (and documentation!) that delivers on your customers’ needs the first time, every time, by default, your team makeup should reflect the customers who use your product. If you look around and everyone on your team looks the same, this should be a warning sign that customers who don’t look like you probably don’t have the same experience that you do.

And if you don’t see that as a problem, you should probably look elsewhere for your problem. Try looking in the mirror.

Update: Two days after this post was published, David Heinemeier Hansson posted a blistering example of why diversity is so important, using his wife’s experience with Apple’s new credit card to drive the point home. I strongly recommend reading the whole thread.


[0] I started writing this post in November 2018, and it’s been languishing in my drafts folder ever since. I’m making an effort to clean up my drafts by the end of the year, so hopefully this one will actually see the light of day before it’s 2020. Fingers crossed…

[1] Me.

[2] CSS selectors.

[3] I feel like I’m enough of a problem child most days, so I try not to bother them unless it’s really necessary.

[4] Although thankfully not nearly as often as I used to.

[5] If you know what this means, you work on the Azure team[6]. Sadly, the people in the audience did not work on the Azure team. Thankfully, someone in the audience stood up and asked for clarification.

[6] When I worked on the Azure team I still didn’t know. I was constantly asking for clarification in meeting after meeting and email after email. Maybe I am just slow…

Never stop asking “stupid” questions

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

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

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

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

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

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

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

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

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

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

How do I know that people are noticing?

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

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

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

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

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

Especially the stupid questions.

Those are the best ones.

 

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

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

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


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

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

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

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

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

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

It all comes down to culture

I talk about data culture a lot, and in my presentations I often emphasize how the most important success factor when adopting a tool like Power BI[1] is the culture of the organization, not the tool itself.

I talk about this a lot, but I think Caitie McCaffrey may have just had the final word.[2]

2019-10-24-12-47-22-722--msedge

I don’t think that Caitie was talking about the enterprise adoption of self-service business intelligence, but she could have been.

In my day job I get to talk to leaders from large companies around the world, and to see how they’re adopting and using Power BI, Azure. Before today I didn’t think of Moby Dick – I thought of Leo Tolstoy’s classic Anna Karenina, which starts with this classic line:

All happy families are alike; each unhappy family is unhappy in its own way.

Although the details vary, large companies that have successfully adopted managed self-service BI at scale have cultures with important aspects in common:

  • Leaders empower business users to work with data
  • Leaders trust business users to use data to make better decisions
  • IT supports business users with platforms and tools and with curated data sources
  • Business users work with the tools from IT and the guidance from leaders, and work within the guardrails and guidelines given to them for this use
  • Business and IT collaborate to deliver responsive solutions and mature/stable solutions, with clearly defined responsibilities between them

Companies that are successful with managed self-service BI do these things. Companies that are not successful do not. The details vary, but the pattern holds up again and again.

How do these roles and responsibilities relate to culture?

In many ways a culture is defined by the behaviors it rewards, the behaviors it allows, and the behaviors it punishes. A culture isn’t what you say – it’s what you do.

In the context of BI, having a culture with shared goals that enable business and IT to work together with the support from the company leaders is the key. If you have this culture, you can be successful with any tool. Some tools may be more helpful than others, and the culture will enable the selection of better tools over time, but the tool is not the most important factor. The culture – not the tool – inevitably determines success.

This is not to say that BI tools should not improve to be a bigger part of the solution. But to paraphrase Caitie… maybe you should let that white whale swim past.

 


[1] But definitely not only Power BI.

[2] He says unironically, before writing many more words.

Diversity of Background

Your background determines who you are.

Who you are determines your values and your priorities.

Your values and priorities determine what you do, and what you accept being done.

Now apply that to your work as a technical professional.

Photo by rawpixel on Unsplash

Think for a moment about the team you work with. What is the team breakdown by gender? By nationality? By education? By skin color? By language? By ethnic background? By religion? By cognitive ability?

Now think about the decisions your team makes when deciding what to build, how to build it, and how to determine when it’s ready to ship.

Consider this headline from earlier this year: “Microsoft’s facial recognition just got better at identifying people with dark skin.” That’s a good thing, right?

Now consider this excerpt from the article:

Microsoft stated that it was able to “significantly reduce accuracy differences across the demographics” by expanding facial recognition training data sets, initiating new data collection around the variables of skin tone, gender and age and improving its gender classification system by “focusing specifically on getting better results for all skin tones.”

“The higher error rates on females with darker skin highlights an industrywide challenge: Artificial intelligence technologies are only as good as the data used to train them. If a facial recognition system is to perform well across all people, the training dataset needs to represent a diversity of skin tones as well factors such as hairstyle, jewelry and eyewear.”

I’d like to emphasize that I’m not on the Face API team and don’t have any insight into the team beyond this story, but I think it’s probably safe to say that if the team had more darker-skinned men and women as team members, the decision to ship an API with high failure rates for darker-skinned men and women may not have been made.[1] Imagine a developer saying “but it works on my face” in the same tone you’ve heard one say “but it works on my machine” in the past. If it doesn’t work on your machine, that’s when even the most obstinate developer will admit that the code has a problem.

This example of the impact diversity of background can make is significant, but it’s also pretty common. If you follow tech news sites, you’ve heard this story and others like it before. So let’s look at another one.

In systems that you’ve built, how easy is it to change an email address or username? This might be a transactional system, where the email address or username is business key. Or it may be an analytics system, where these fields may not be handled as slowly changing dimension attributes. Think about your Microsoft Account[2] as an example – just how easy is it to change the email address you use for your cloud identity across dozens of Microsoft services?

As it turns out, it’s pretty darned easy today, and I have to wonder if there are transgender team members who are responsible for this fact.

For most cisgender people, the only time you’d think about changing your name is when you get married, and then it’s only your last/family name. Changing your first/given name may feel like a weird corner case, but it definitely won’t feel this way if you or someone you love is transgender. In that case, you understand and appreciate the impact of deadnaming, and you may well have experienced the struggle of making name and email changes in system after system after system.

Rather than going on with more examples, I’ll get to the point: If you have a more diverse team, you have a better chance of building a product that is better for more customers more quickly, and to ship the right thing sooner rather than later.

To me this is an obvious truth because I have seen it play out again and again, for good and for ill. Not everyone agrees. There are still people who use the term “diversity hire” as a pejorative. This summer the amazing intern working with my team was told by one of her fellow interns that the only reason she got the position was because she was female, and there was a quota[3]. Although some people[4] may be threatened by the recognition of the value of diversity, that doesn’t reduce the value in any way.

Join a diverse team. Form a diverse team. Support a diverse team. And build something that’s what the world needs, even if the world doesn’t look just like you.

 


[1] And to be fair, the blog post to which this article refers goes into some excellent depth into how Microsoft is addressing both tactical and strategic aspects of this challenge. Please also note that a lack of diversity in product development will produce a substantively different set of problems than will a lack of morality in product development.

[2] The cloud identity that used to be called Live ID, after it was called Passport. It’s the email address you use to sign into everything from Windows to Outlook to OneDrive.

[3] Hint: It wasn’t, and there wasn’t. She was awesome, and that’s why she got the internship. I sure hope she sticks with it, because if I was half as good when I was 21 as she is, I would be ruling the world today.

[4] Typically the people who directly benefit from a lack of diversity. Yes, typically white heterosexual cisgender males. Typically people who look like me.

Diversity of Ability

I’m better than you are.

No, that’s not how I want to start…

What makes a high-performing team?

No, no, that’s still not right. Let me try again…

When you think about the people you work with, your co-workers, teammates, and colleagues, what is it that you find yourself admiring?

ability
Photo by Mark Raugas – http://innercapture.com/galleries/squatch18/index.htm

For me, it often comes down to things that I’m not good at – useful skills and knowledge that I lack, or where my team members are far more advanced. When you consider the people I work with, this can be pretty intimidating[1]. It’s great to know that I can reach out at any time to some of the best experts in the world, but it sometimes makes me wonder what I have to offer to the team when I see them kicking ass and optionally taking names.

As it turns out, I have a lot to offer. Specifically, I’ve been able to do some pretty significant things[2] that have changed the way my team works, and changed the impact that the team has on Power BI as a product. And if I believe what people have told me[3],  I’ve implemented changes that probably could not have been made without me.

This brings me back to this question: What makes a high-performing team?

Since I’m no expert[4], I’ll refer to an expert source. This article from Psychology Today lists 10 characteristics of high-performing teams, and #1 on the list is this:

Define and Create Interdependencies. There is a need to define and structure team members’ roles. Think of sports teams, everyone has their position to play, and success happens when all of the players are playing their roles effectively. In baseball, a double-play is a beautiful example of team interdependency.

Based on my experiences, I’ll paraphrase this a little. A high-performing team requires team members with diverse and complimentary abilities. Everyone should be good at something – but not the same thing – and everyone should be allowed and encouraged to contribute according to his or her personal strengths and interests[5]. Every team member should have significant abilities related to the priorities of the team – but not the same abilities. And equally importantly, each team member’s contributions need to be valued, appreciated, recognized, and rewarded by the team culture.

I’ve worked on more than a few teams where these criteria were not met. At the extreme, there were teams with a “bro” culture, where only a specific set of brash technical abilities were valued[6], so everyone on the team had the same skills and the same attitudes, and the same blinders about what was and what was not important. And of course the products they built suffered because of this myopic monoculture. Although this is an obvious extreme, I’ve seen plenty of other teams that needed improvement.

One example that stands out in my memory was the first major product team I worked on at Microsoft. There was one senior developer on the team who loved sustained engineering work. He loved fixing bugs in, and making updates to, old and complex code bases. He was good at it – really good – and his efforts were key to the product’s success. But the team culture didn’t value his work. The team leaders only recognized the developers who were building the flashy and exciting new features that customers would see in marketing presentations. The boring but necessary work that went into making the product stable and viable for enterprise customers simply wasn’t recognized. Eventually that team member found another team and another company.

I’m very fortunate today to work on a team with incredible diversity. Although most team members[7] are highly skilled at Power BI, everyone has his own personal areas of expertise, and an eagerness to use that expertise to assist his teammates. And just as importantly, we have a team leader who recognizes and rewards each team member’s strengths, and finds ways to structure team efforts to get the best work out of each contributor. Of course there are challenges and difficulties, but all in all it’s a thing of beauty.

Let’s wrap this up. If you’ve been reading the footnotes[8], you’ve noticed that I’ve mentioned imposter syndrome a few times. I first heard this term around 8 years ago when Scott Hanselman blogged about it. I’d felt it for much longer than that, but until I read his post, I’d never realized that this was a common experience. In the years since then, once I knew what to look for, I’ve seen it all around me. I’ve seen amazing professionals with skills I respect and admire downplay and undervalue their own abilities and contributions. And of course I see it in myself, almost every day.

You may find yourself feeling the same way. I wish I could give advice on how to get over it, but that’s beyond me at the moment. But what I can say is this: you’re better than the people you work with[9]. I don’t know what you’re better at, but I’m highly confident that you’re better at something – something important! – than the rest of your team. But if your team culture doesn’t value that thing, you probably don’t value it either – you may not even recognize it.

If you’re in this situation, consider looking for a different team. Consider seeking out a team that needs the thing that you have to give, and which will appreciate and value and reward that thing you’re awesome at, and which gives you joy. It’s not you – it’s them.

Not everyone is in a position to make this sort of change, but everyone can step back to consider their team’s diversity of ability, and where they contribute. If you’ve never looked at your role in this way before, you may be surprised at what you discover.

 


[1] Epic understatement alert. I work with these guys, and more like them. Imagine my imposter syndrome every damned day.

[2] I will not describe these things in any meaningful way in this post.

[3] Which is far from certain. See the comment on imposter syndrome, above.

[4] Imposter syndrome, remember? Are you noticing a theme yet?

[5] I explicitly include interests here because ability isn’t enough to deliver excellence. If you’re skilled at something but don’t truly care about it, you may be good, but you’re probably never be great.

[6] Bro, short for brogrammer, with all the pejorative use of this term implies. If you’ve been on one of these teams, you know what I mean, and I hope you’re in a better place now.

[7] Present company excluded, of course.

[8] Yes, these footnotes.

[9] Did this work? I was a little worried about choosing the opening sentence I did, but I wanted to set up this theme later on. Did I actually pull it off, or is this just a cheap gimmick? I’d love to know what you think…

Thoughts on Expertise, Ignorance, Chocolate, and Bacon

In late September I had two very different experiences that I’ve found myself thinking about a lot since then. One involved chocolate, and the other involved bacon, and both involved ignorance.

My wife and I were taking a bacon making class one Sunday evening. I’d tried making homemade bacon before, but the results were disappointing, and I wanted some expert instruction. I’d been looking forward to the class for months.

While we were in the area, we decided to stop by Dawn’s Candy and Cake to inquire about tempered chocolate. I’ve been making chocolate treats for decades, and have tempered chocolate many times, but always found it to be a finicky pain in the butt. Dawn’s offers chocolate tempering classes, and I was hoping that there would be some way I could pop in to use chocolate that an employee had tempered to use with truffles I had made myself. This would let me focus on flavors, and let someone else worry about the annoying parts.

Sadly it was not meant to be. Although the young woman who was working that evening was very helpful, all of the tempering classes in the time-frame I needed were completely booked. But all was not lost. This amazing 17-year-old[1] stepped up to save the day. She printed out the tempering instructions they hand out during classes, and walked me through them in detail. They were pretty much what I’d done in the past, but with enough differences that i was happy to receive them. It was obvious she’s done this before; she explained the processes and concepts clearly and concisely…

So I asked her some follow-up questions, abut selecting chocolate with the right viscosity[2] for different purposes. She said she’d never even heard of viscosity, and wasn’t sure what to tell me.

When we got to the bacon class, we learned that the instructions we would be using were the same instructions I had followed in my earlier failed attempt. This was disappointing, but the middle-aged man teaching the class was very forward in letting us know how he’d made bacon scores of times, and how everyone who had tried his bacon was spoiled forever on the store-bought stuff. He let us know very explicitly that he was an expert…

And as the class progressed, he proceeded to read the copied-from-the-internet directions, evade every substantive question, and inform the students that the things they were concerned and asking about weren’t important for unexplained reasons, all while continuing to tout his expertise. The class itself turned into something of an ordeal, as the instructor used every trick in the bulshitting-to-cover-up-your-ignorance-in-front-of-the-class book.[3]

Sigh.

The two experiences came back to back, and they could not have been more different. One instructor was confident enough to admit that she didn’t know, and the other was not. One instructor let his ego get in the way of his students’ learning, and the other didn’t let her ego get involved at all. One was focused on helping, while one was focused on not looking like an idiot. One succeeded, and the other one failed.

I’m not going to dwell on the fact that one of these people was young, and the other was middle-aged, or the fact that one was female and the other was male. While these factors may be significant, I know enough exceptions to the stereotypes[4] that I’m not going to go there. I’d rather focus on the behaviors themselves.

I strongly believe that the willingness to express vulnerability or weakness – including ignorance – only comes with confidence.

When you’re not confident in yourself, if you don’t know your strengths and weaknesses, and if you haven’t made some sort of peace with them, it’s incredibly difficult to say “I don’t know,” especially if you’re in a position of authority.  Some people choose to deny gaps in their knowledge, trying to cover them with bluster and obfuscation. Some may get away with it some of the time, but it’s never a long-term strategy for success. This behavior eventually builds a reputation as an unreliable blowhard.

People who admit their ignorance accomplish two important things. First, they give themselves the opportunity to learn something. Second, they encourage trust and confidence in the people around them[5]. When you show that you’re able and willing to express ignorance, this adds weight and confidence to your words when you’re expressing knowledge and expertise.

Anyway… where was I going with this? What’s the moral of this story?

I think the moral of the story is don’t be that guy.

Following my two culinary learning experiences, I have returned to Dawn’s Candy and Cake on at least three occasions, and have recommended their training events and supplies to multiple people. I’ll never take another class at the other place. And after talking to other participants after the class, I know I’m not alone in that decision.


[1] I know she was 17 because when my wife and I were talking about my upcoming tattoo appointment, she talked excitedly about how she wanted to get a tattoo when she turned 18 in a few months. Yes, I felt as old as I’ve felt in ages.

[2] In case you’re interested, this is a decent overview: https://www.reference.com/food/viscosity-important-candy-making-459c24a3ca10028b

[3] I started my IT career as a trainer, and spent years in the classroom. I could write this book.

[4] And I try to be exceptional, every day.

[5] If the people around you are the type of people who would ridicule you for admitting you don’t know something, you have also benefited from learning that you should be surrounded by different, better people.