How Language Can Cultivate Inclusivity in Tech

In IT, terms like “master/slave,” “blacklist” and “whitelist,” “kill,” “disable,” and “abort,” have been used for decades by programmers, IT service desks and even users. Despite their seemingly innocuous meaning in computing, such terms have recently come under criticism for their perceived racially charged undertones, aggressive and insensitive nature.

Yet, little has been done to change the lexicon. With harmful terms and language entrenched in IT systems, codebases, documentation and an array of other repositories, removal is complex. Finding more inclusive words that everyone can agree to is also a challenge, as is ensuring everyone actually uses the new terms.

The need for inclusive terminology is not new, but continued injustice has strengthened political and social protest movements and increased awareness of the issue globally. Employee and public demand for improvements in diversity, equity, and inclusion (DEI) has become a catalyst for real change. Thanks to CEO commitments globally, there has never been a better time to drive meaningful change on business DEI initiatives.

When it comes to IT, a unique opportunity exists for CIOs to act now to drive a more inclusive naming approach for IT services across the enterprise, and subsequently, the industry. Language is just one area, but it can and does have a ripple effect. Placing more attention on the use of inclusive words can start a virtuous circle, drawing attention to the need for other inclusive practices.

Here are five steps that CIOs can take to promote more inclusive language and terms in IT, leading to a stronger and more inclusive organizational culture.

Step 1: Assemble a task force with the CIO at the helm

Evidence shows that expecting employees to voluntarily assume “above and beyond” DEI-related roles can dilute impact and progress. For example, if a CIO is told by their CEO that they need to join the organization’s DEI committee, they may do so out of obligation but will take a passive role, assuming that the “real” DEI work is being done by HR. This type of collective accountability really means that nobody is accountable in the end, leading DEI initiatives to fall short of their goals.

If there is an incentive or consequence attached to DEI goals being achieved or missed -- such as affecting an employee’s performance rating and/or bonus -- it can give the initiative real teeth. For example, if one of the CIO’s formal performance goals is tied to the rollout of inclusive language across the IT organization, that offers more specific and actionable motivation to progress DEI across the broader enterprise.

To kick off a language inclusivity initiative, the CIO should assemble a multidisciplinary, diverse team to take part for an agreed duration (minimum of 12 months). Include members from IT as well as stakeholders from throughout the enterprise to co-create a compelling vision and objective. The CIO and remaining task force members can then take on the initiative’s goals are part of their formal, individual development plans.

Step 2: Design evaluation framework for IT terminology

Language, like culture, is complex and ever evolving. Different terms can hold different meanings to individuals from diverse groups. A robust framework can help the taskforce evaluate IT terminology from a multidimensional and multicultural perspective. CIOs can consider adapting existing frameworks to simplify this process, such as the openly available framework originally developed by the Kubernetes Naming Working Group and adopted by the Inclusive Naming Initiative.

The framework should define a series of questions, or “gates,” to identify whether a term is inclusive. Rank each gate in order of potential harm, with Gate 1 as the strictest. For example:

If the term fails the test at any gate, it should be replaced. If the term passes a gate, it can move to the next gate. Using the aforementioned example, one can see that technology terms like “blacklist/whitelist” or “master/slave” would fail at Gate 1. Terms like “marshal/unmarshal” would fail at Gate 2, while a term like “man hours” would fail at Gate 3.

Step 3: Identify terms for replacement & alternative IT words list

Once the evaluation framework has been created, focus on compiling a list of terms currently used in IT that may be considered potentially harmful or exclusionary. Gather feedback from the entire IT organization on suggested terms for replacement using employee listening sessions and surveys to ensure no cultural nuances are missed.

The task force can then use the framework to determine whether terms on the list are potentially problematic. Take an “if in doubt, replace” mindset for any term that lacks consensus. It’s better to replace now than to regret later.

For terms deemed in need of replacement, brainstorm alternative terms, such as “blocklist/allowlist” in place of “blacklist/whitelist.” Seek outside input for suggested replacement terms by leveraging third-party research such as the Internet Engineering Task Force’s suggestions for inclusive terminology or the American Psychological Association’s guidelines for bias-free language. Make the list of proposed terms for replacement and their alternatives openly available online for IT employees to view and suggest additions.

Step 4: Implement a replacement plan

Once the alternative word list is complete, the task force can start the process of rectifying non-inclusive language. This may be a complex task; with harmful terms and language likely used in a plethora of codebases, APIs, and libraries, it requires a methodical approach.

The task force must first decide if they will update language that already exists in the operating environment or if they’re going to start using new terms going forward. Changing existing language embedded in current and historical documentation is a significant effort, but it may be worthwhile because it strongly communicates a commitment to inclusive language.

Varying degrees of complexity and risk exist depending on where the term is used. For example, words in documentation or webpages can be updated using a simple “find and replace.” However, function names or configuration directives that are exposed externally, such as via an API or a configuration file, require a deprecation plan to avoid the risk of breaking production deployments.

The more dependencies that a word or term has, the greater the risk and potential impact. Implement changes in a test environment where possible, using staging environments to check for production impact. Ensure that planned changes are communicated across internal and external communities, including application owners, vendors and third parties.

Step 5: Drive a “language fresh start” campaign

Harmful terms have been part of IT’s lexicon for decades, thus a few emails citing the need to replace certain technology terms will not be enough to drive real change. Shifting the mindset and behaviors in how language is perceived and used in IT will require ongoing effort.

Start a “language fresh start” campaign by forming an inclusive language advisory board, which continues to govern the process of driving inclusive IT language. This group must take every opportunity to spread the message that inclusive language matters. CIOs can regularly present at IT- and organization-wide town halls about the initiative and its progress. Using the power of social accountability, ask employees to sign an online pledge where they commit to using more inclusive language both in their writing/coding and in their spoken word.

The CIO also has an opportunity to influence change throughout their external network. Share with strategic partners the “why” behind this initiative, the business case for using inclusive language and the new terms they may hear IT staff use. To help nudge vendors toward more inclusive language, be explicit with expectations and share specifics of the initiative.

The CIO and the task force will face inevitable pushback and objections at every stage of this process within the organization. Employees will object to “wasting time” on these efforts, will declare this as a “slippery slope” issue, bemoan “cancel culture” and object to changing language that has been in use for a long time with “nobody objecting before.” To get out in front of these objections, tease out scenarios and preempt specific objections. Communicate proactively with detailed FAQs to mitigate concerns and minimize dissenting voices.

Language is a powerful tool, and CIOs have a real opportunity to shift towards a more inclusive culture by evolving the language of IT. With a methodological and comprehensive approach, CIOs can do their part to support lasting cultural change in their organizations.