Everybody Belongs in the Conversation: Dialpad's Journey Towards More Inclusive Language

In June 2020, the murder of George Floyd sparked protests against police brutality and in support of Black lives. These events sparked a parallel movement in the tech community to examine the language we use, some of which with problematic origins and connotations. Although the discussion around most of these terms is not new, conversations about race and inclusion were pushed into the mainstream anew.

Within Dialpad, multiple teams independently initiated discussions about the ways in which exclusive language can have a negative impact on people, even while not being used with exclusionary intent.

While language use is simply one small corner of being inclusive of all Dialers, this was particularly close to my heart because I am a linguist. My linguistic training has shown me that language is always changing, and that language and society are inextricably linked. I wanted to share that with the rest of the team and use my expertise to direct our conversations into action, so I spearheaded our journey towards inclusive language by putting together a set of guidelines, with an eye to eventual company-wide adoption.

At the time, I had recently listened to an episode of The Diversity Gap podcast that really resonated with me. Stephanie Ghoston — a coach, consultant, and guest on that episode — said, "In order to have deep-rooted, long-term, sustainable transformation, we need folks doing individual work, work in our community and on our culture, and we have to look at the institutional piece." In her experience, organizations tended to look at the highest level and ignore the other pieces, but Ghoston pointed out that there is agency in understanding that a connection exists between individual actions and the bigger picture of racism (or any form of exclusion).

As an engineer with comparatively little institutional power, this felt like a place where I could use my knowledge to educate team members and make an impact on our culture.

Beginning the Journey to More Inclusive Language

I started by compiling a list of all the exclusionary terms I could find, focusing on technical language used in coding and non-technical business language that was likely to be used on our company website and in our documentation. Thanks to the wide-reaching public discussion on the subject, I found several blog posts with lists of words and possible alternatives.

What stood out to me was that the framing of many of these posts assumed a lot of context and background knowledge that is often not obvious to people who aren't in the weeds of social justice work. Additionally, these articles often made it sound like you can 'solve' inclusivity by memorizing and using a fixed list of unimpeachable words and always avoiding a list of taboo words. Any linguist worth their salt would tell you this is simply not the case. Language use is inherently contextual, and the point of inclusive language is not to censor people, but rather to understand that language use can hurt people in subtle but substantive ways. I wanted our guide to explain why certain terms were exclusive to some groups, to help people understand that adopting inclusive language is a sign of our compassion rather than compliance. To this end, the guide includes an introductory section motivating its existence, and every example of exclusive language is linked to an appendix explaining how the term is exclusive, including resources for further reading.

After listing them out, I worked with another linguist to pick the best alternative to recommend based on accuracy, transparency of meaning, and usage by other companies and services. The next step was to share these suggestions with and solicit feedback from technical leads and engineering heads across Dialpad.

Before the broader launch within the company, we also added a section covering the intended usage of these guidelines. We got buy-in from engineering leaders that all new code, documentation, and web content should follow the guidelines: pre-existing issues in all of these areas were to be fixed as soon as possible if they were simple, and if not, they were to be considered 'inclusion debt.' Dialers were directed to create tasks in our issue tracking system to track this inclusion debt and address it as they had time.

The terminology in our guide falls into three broad categories — gender-, race-, and ability-based exclusive language, as well as their inclusive alternatives. An example from each category is highlighted below.

Generic 'He' → Singular 'They'

Moving away from language that centers on men signals the inclusion of people of all genders. There are many good alternatives that refer to a generic person without the connotation that maleness is the 'default' gender.

'They,' 'them,' and 'theirs' have been used as a third-person singular pronoun since the 15th century AD when the gender of the person is unknown or explicitly unspecified. Despite what self-styled grammar mavens may tell you, we linguists give you full permission to use these pronouns everywhere when you are talking about a generic user or developer, to be inclusive of everyone.

It is important to remember, though, that when referring to specific individuals, inclusive practice is to use the pronouns they have asked you to use to refer to them! For example, I use she/her and xe/xyr pronouns (pronounced with a 'z' sound, rhymes with "be" and "beer"), so you should say, "She loves birds," or "Xe wrote a song about trilobites."

'Whitelists' & 'Blacklists' → 'Allowlists' & 'Denylists'

The terms 'blacklist' and 'whitelist' exploit the metaphor of black being bad and white being good. Research on a phenomenon called the 'bad is black effect' has found that this type of metaphor contributes to implicit bias, so we recommend using 'allowlist' and 'denylist' as alternatives. Additionally, 'allow' and 'deny' are more interpretable than “black” and “white” in this context.

Not every term that uses 'black' or 'white' is exclusive. For example, 'glass-box' and 'black-box' models refer to models where you can and cannot see their inner workings respectively. The metaphor here is a visual one, rather than relying on equating black to bad. Similarly, a 'white-label' product is one that has been rebranded by another company. The history of this term has to do with actual white labels being placed on packaging that would later be filled in with other branding. When in doubt, it's always worth doing further research on the history of a term.

'Sanity Check' → 'Confidence Check'

Ableism — discrimination and prejudice against disabled people — is pervasive in our society, and the language we use is a part of the bigger problem of "systematically devaluing bodies and minds that are deemed deviant, abnormal or defective," according to disability activist Lydia X. Z. Brown. Her website includes a detailed discussion of ableist language and alternatives for a general audience.

A 'confidence check' is a quick test of some very basic assumptions of some code. Calling it a 'confidence check' does not perpetuate casual ableism unlike calling it a 'sanity check' because conflating mental illness with 'bad' or 'less' is ableist.

Post-Launch & Implementing the Guidelines

The response was positive. People throughout Dialpad appreciated the explanations in the appendix and many learned things that really surprised them.

The Automatic Speech Recognition team — my team — was the first to hit full compliance with the guide. I led a meeting for my team where we went through the recommendations and discussed how we would like to be reminded when we slip up in conversations, as is inevitable when adopting a new pattern of behavior. Overwhelmingly, people voted to be privately direct messaged with a gentle nudge about inclusive language.

Teammates fixed issues as they came across any, sometimes combining them with other regular work. Our team also has Tech Debt Days to address technical debt and clean up our code, allowing a few members the perfect opportunity to take on tasks related to inclusion debt. In mid-January, GitHub (the platform we use to host our code) released tools to simplify the renaming of the so-called 'master' branch of development to 'main.' With GitHub's updated process, the transition was seamless. By March, we were the first team at Dialpad to have addressed all of our inclusion debt!

The Future of Inclusive Language

Language is always shifting, changing, and being used in new and imaginative ways. Many words we now consider exclusionary used to be commonplace, and therefore it will always be true that this guide is a living document. Practicing inclusion necessitates multiple perspectives, and so we encourage all Dialers to bring up potential changes with their managers or directly in the document. In the months since I created the first draft of the guide, we have had additions brought up by Dialers through various channels, and we have collaborated to give each other context and come up with good alternatives. The future of this guide may include a section on casual language as well, as this has been requested by multiple Dialers recently.

Of course, the future of inclusion in general at Dialpad must extend far beyond the realm of the language we use. With the #TechForBlackFounders Program, we are offering heavily discounted Dialpad licenses to U.S.-based, early-stage startups led by Black founders, who make up an abysmal 1% of founders backed by venture capital. We are prioritizing accessibility in our product's design and engineering, a concrete way to combat ableism. We have vibrant Employee Resource Groups (ERGs) that build community, create safe spaces for Dialers to bring up concerns, and use company money for sponsorship. We declared Juneteenth to be a company-wide holiday and encouraged all Dialers to learn about their local Black history.

Since my team works on speech recognition, we need to ensure that we are able to transcribe all varieties of English well, and not simply prioritize the prestigious ones. Most speech recognition systems tend to do very well on Anglo/Western names and not very well on names like mine (Vasundhara) — this is not acceptable to us. All of our customers' names are equally deserving of accurate transcription.

Creating this guide was one of the first inclusion initiatives I led at the company, and I am very proud of this work. I felt supported by my coworkers and managers, who understand why this matters and are putting in the effort to fix it alongside me. I think that, if Stephanie Ghoston was reading this, she would be proud of the way in which we are tackling change at every level.

With any of these initiatives about inclusion, it is critical that we do them right, and to that end, we have a cultural emphasis on soliciting feedback from internal and external stakeholders who are affected by these issues, and educating ourselves on these issues. In an effort to share and collaborate on these guidelines with a broader group of people, we have decided to publish our inclusive language guidelines on GitHub, and we welcome contributions. I hope you can use this blog post to start a conversation at your school or your workplace, maybe even using our guidelines as a starting point!

To read the complete guide, contribute to it, and maybe even make a copy for your company, you can visit the public-facing, open-source copy of our inclusive language guide.