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.

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…