Making Our Code More Inclusive

At Indeed, inclusion extends beyond employee resource groups and celebrations. Diversity of background, experience, and thought makes for a stronger workforce, more effective decision-making, and powerful innovation. To foster inclusion, we want to build a psychologically safe environment at every level and in every area of the business. That’s why we’re removing terminology that works against such inclusion from our codebase.

Five Indeed inclusion group members smiling and wearing shirts labeled "Women at Indeed" in a relaxed office setting

Diversity and inclusion are ingredients for success. Leaders of Indeed Amsterdam’s Women at Indeed employee resource group (l-r): Edwin Moses, Trudy Danso-Osei, Freek van Schaik, Renske van der Linden, and Valerie Sampimon.

What does technical terminology have to do with inclusion?

Like all words, technical terms have connotations that give them immense expressive power. Some connotations are well known and generally understood. Others depend on context and are understood differently by people with varying lived experiences. The original etymology of a term often has little to do with the connotations it accrues over time.

Computer science and software engineering employ many terms that are convenient, meaningful, and useful. However, some terms ask groups of people to ignore the powerful negative and exclusive connotations they carry.

The terms “master” and “slave” exemplify this. Some engineers see these words and are privileged to deduce a benign connotation—a slave is a subordinate process that acts in accordance with the demands of the master. However, for many people, particularly people of color, these terms immediately conjure images of human slavery’s horrors. This connotation doesn’t just exist in the context of one country’s history, such as American slavery. With an estimated 21-45 million people currently enslaved worldwide, the terms master and slave represent both an historic and current global humanitarian crisis.

Many other terms have similar negative connotations. Words that associate colors with value judgments, such as “blacklist,” and language around the exploitation or denigration of cultures, such as “tribal knowledge,” represent just a couple. Ableist language such as “lame” and “blind” used in the wrong context can negatively impact people with disabilities. People continually fight bigotry and prejudice based on these characteristics, and these terms invoke and perpetuate those injustices.

Some of these terms might surprise those of us who don’t share the lived experiences of marginalized individuals. But when our colleagues tell us we are using terms that exclude or hurt them, we should trust them and find new words to use.

Starting the conversation

Even before Indeed officially introduced inclusion and belonging as one of our company values in 2019, our engineers began removing problematic terms from our technology.

We started by opening up the discussion on our internal wiki, with internal blog posts and a dedicated content hub for identifying and deprecating exclusive terminology. All engineers can contribute to and comment on the Inclusive Terminology wiki page. From contributions made there, we created a non-exhaustive quick reference guide to help each other make responsible terminology decisions.

Instead of Use Why
master* primary, main, trunk These terms represent an inherently oppressive relationship.

*The removal of “slave” from the set in common usage does not remove the implied oppressive relationship. Historically, the usage of the term “master” in relation to a Git branch stems from a master / slave relationship.

slave replica, secondary
whitelist allowlist, unblocklist These terms imply a culturally specific binary of good versus evil.
blacklist denylist, blocklist, banned
backlog grooming backlog refinement “Grooming” is a term with specific legal meaning in British English.
tribal knowledge institutional knowledge “Tribe” is a loaded term with negative connotations for First Nations and African communities.
grandfathered legacy, pre-existing Grandfather clauses originated from Jim Crow era discrimination laws in the United States.

Each engineering team chose how to implement the new language in their code. Then, teams shared best practices and processes. We continue these conversations today.

Case study: Replacing “master” with “primary” in a Git project

Renaming the master branch of a Git project is not a trivial exercise, especially for projects with lengthy histories. Recently, our Design Systems team completed this work for one of their projects. To do this, the team:

  1. Cloned the master branch and named the clone “primary.”
  2. Updated the default branch in GitLab from master to primary.
  3. Locked down the master branch. It still exists for historical purposes, but it can no longer be used.
  4. Applied the former settings for the master branch to the new primary branch.

A couple of issues could arise in this scenario. For example, a user could create a branch off master before the team created the new primary branch. Because primary and master share a common history, the user could theoretically merge the feature into primary. To mitigate such issues, the team enacted a code freeze while they made the change. They also tested their process on a smaller project before renaming the main project.

Tangible results

To track this work, Indeed engineers leaned on Atlassian’s Jira, our tool for software development tracking. We added a label to Jira tickets that involve inclusive terminology so we can filter and sort them. This gives us a high-level view of where exclusive language exists, our ongoing efforts to remove that language, and our progress. To date, we’ve closed 97 of 113 issues and counting.

A pie chart representing Jira tickets filed for exclusive language

Pie graph showing the number of Jira issues labeled “inclusive-terminology” by status, with 97 closed, 1 deferred, 9 on backlog, 1 pending review, 2 pending triage, and 3 in wish list status

Challenges to making this happen

This work sparked lots of discussion among our engineers. The last thing we wanted to do was turn these language changes into a policing and shaming process. So, we decided to make this a grassroots effort instead of a top-down mandate. That way, everyone is empowered to respectfully discuss terminology changes while learning from one another. Leadership provides support and guidance when necessary and actively participates in the conversation.

One subject that came up in these discussions was cost and level of effort. Changing terminology throughout all our products is a long-term project that requires many engineer hours. In fact, as of today we still need to remove over 5000 instances of the term “slave” from our codebase. We’re committed, and the psychological safety generated by this work far outweighs the time and effort required to remove exclusive terminology.

A way forward

Language constantly evolves to meet the needs of those who use it, and words fall out of fashion as we progress. Because of this, we know changing the terms in our codebase is an ongoing practice, not a one-time effort.

We continue to document words we want to replace and offer suitable alternatives. We avoid using those terms in any new code and ask our vendors to avoid those terms in their products as well. As we change our codebase, we methodically and carefully locate and replace the existing usages.

We still have work to do. We constantly increase our awareness of exclusive terms and their implications, and we engage in respectful conversations about these topics with each other. Together, we want to create a work environment that is psychologically safe, inclusive, and welcoming for all people at Indeed. By sharing these practices, we hope to model inclusivity and improve the tech industry as well.


Inclusive Code—cross-posted on Medium.

Coming Together to Support the Open Source Community

Indeed Open Source Program logo

Over the last few weeks, conference and event cancellations around the world have heavily impacted the open source community. These events play an important role in the ecosystem that supports free and open source software. If we want that ecosystem to remain healthy, it is important for us to act now.

Why support matters now more than ever

Conferences and events provide essential opportunities for the open source community to:

  • Coordinate activities
  • Raise funds
  • Grow their user bases
  • Support each other
  • Evangelize their technologies
  • Educate and onboard new contributors
  • Ship new releases
  • Share knowledge

Running these events requires a lot of time, effort, and money. When they are cancelled, the event organizers bear the brunt of the losses. If we want these events to continue—and the open source community to sustain itself and grow—all users of free and open source software must respond.

The FOSS Responders

Open source community leaders from across the industry have come together to form a working group called FOSS Responders. We’re focused on identifying open source events, communities, foundations, and community members who are most in need of support. We also want to support individuals who are unable to absorb conference-related cancellation fees. Our goals: amplify these community needs and mobilize organizational and individual resources to help.

This working group of committed industry professionals includes participants from Indeed, GitLab, Open Collective, the Sustain community, the Drupal Association, and several other organizations. You can find more information about this working group—including information on how to join and participate—at fossresponders.com.

Virtual funding event

Indeed and Open Collective are collaborating to host a virtual funding event on May 22, 2020. We want to raise funds for conference organizers that have suffered irrecoverable losses due to event cancellations. We are calling on our peers in the industry to join us at this event as fellow FOSS Funders.

By coming together to share knowledge, collaborate on decision making, and coordinate our collective response, we can ensure that these events will continue to serve and support the community in the months and years to come. Find more information about the virtual funding event.

Taking action

Regardless of your need or your capacity to help, the time to act is now. Here are some specific actions you can take.

How to help

Now is the time to give back to the projects we depend on. This is how we future-proof our open source infrastructure investments and help millions who built the software we benefit from:

  • Donate and buy membership to foundations that support your projects
  • Donate to individuals working on projects you use via GitHub Sponsors and Open Collective
  • Donate to the FOSS Responders Open Collective—your funds will be used to help individuals who might otherwise fall through the cracks

How to get help

FOSS Responders will amplify your need so others can easily see who and how to help. By sharing your need, we can connect you with helpers.

  • If you are an individual who needs help paying for conference-related cancellation fees, fill out the FOSS Responders Individual Request
  • If you had to cancel an event and your organization needs financial assistance as a result, open an EVENT issue
  • If you need other kinds of help, open an ORGANIZE issue

How to get involved

The FOSS Responders working group is growing quickly and we could use your help.


Supporting the Open Source Community—cross-posted on Medium.

Improving Incident Retrospectives

This post was originally published on learningfromincidents.io.

Photo by Jared Erondu on Unsplash

As a Site Reliability Engineer (SRE) at Indeed, I often participate in the retrospective process that follows an incident. Retrospectives—in use at Indeed since late 2015—are a meaningful part of our engineering culture. I have never questioned their importance, but recently I was struck by shortcomings I saw in some retrospectives. For example:

  • A retrospective meeting might use only ~30% of the allotted time.
  • What is discussed might be gleaned from reading the incident ticket and retrospective document instead of attending the meeting.
  • Too much focus is devoted to the conditions that “triggered” the incident.
  • Signals used for deciding to hold a retrospective tend to direct focus toward incidents with high impact or high visibility.
  • Were participants actually learning anything new? It became apparent to me that we were not using every incident to realize our full potential to learn.

I decided to explore why so that we could improve our process.

The typical retrospective

Retrospectives at Indeed are usually a one-hour discussion including up to several dozen participants. The meeting is open to anyone in the company, but usually participants have either been involved in the incident response or have a stake in the outcome.

Facilitators follow a prescribed process:

  1. Review the timeline.
  2. Review the remediation items in the template.
  3. Find owners for the remediation items.
  4. Open the room for questions.

Spotting opportunities for improvement

In Summer 2018 I visited one of our tech sites and was invited to several local retrospective meetings to discuss some recent incidents. As an SRE it wasn’t unusual for me (or members of my team) to be invited. I also had subject matter expertise in a technology related to the incidents.

The facilitators took about 5 minutes to review the timeline, spent 8-10 minutes reviewing the remediation items, and concluded with questions related to the specific technologies involved in the causal chain. I didn’t learn anything new. I could have gained the same information from reading the incident ticket and retrospective document. This was a rare opportunity when a unique and eager group of people gathered in a conference room ready to collaboratively investigate. Instead, we never achieved the full potential.

This result is not uniform across retrospectives. I’ve been present in retrospectives where the participants offered such rich detail that the conversation continued well beyond the one-hour time limit, culminating with a huddle outside of the conference room.

The facilitators for these particular retrospective meetings followed the process faithfully but had only utilized ~30% of the time. It was clear to me that the retrospective process itself needed improvement.

Nurturing a safety culture

To understand potential changes, I first solicited viewpoints on why we conduct retrospectives at Indeed. Reasons I heard are likely familiar to most software organizations:

  • Find out what caused the outage
  • Measure the impact
  • Ensure that the outage never happens again
  • Create remediation items and assign owners

These goals also reflect Indeed’s strong sense of ownership. When someone’s service is involved in an incident, there’s a concern that we were closer to the edge of failure than we thought we were. Priorities temporarily change and people are more willing to critically examine process and design choices.

It’s important to use these opportunities to direct efforts toward a deeper analysis into our systems (both people and technical) and the assumptions that we’ve made about them. These approaches to a different safety culture at Indeed are still relatively new and are evolving toward widespread adoption.

Recommendation: Decouple remediation from the retrospective process

One process change I recommend is around the creation of remediation items. The retrospective process is not necessary as a forcing function for driving accountability of finding and owning remediation items.

I consistently observe that the creation of remediation items occurs organically after Production is stabilized. Many fixes are obvious to teams in the hindsight following an incident.

I see value in decoupling these “after action” activities from the retrospective process for many reasons.

  • The search for remediation items is often a tacit stopping point that halts further or deeper investigation.
  • The accountability around owning remediation items should be tightly coupled to incident ownership.
  • The retrospective process should be an optional activity. By making the retrospective process optional, teams that decide to engage in it are doing so because they see value in it rather than as an obligation or a checklist item.
  • Participants are freed up to conduct a deeper investigation unencumbered by the search for remediation items and shallow explanations.

Recommendation: Lighten up the retrospective template

Another useful change is with the retrospective template itself.

Using retrospective templates can be a lot like filling out forms. The focus is directed toward completion of an activity rather than free exposition. A blank document encourages a different kind of sharing. I have witnessed incidents where responders were so motivated to share their thoughts and descriptions that they produced rich and detailed analysis simply by starting with a blank document.

If every incident is shaped like a snowflake, it’s impossible to develop a template that is equipped to capture its unique characteristics. A template constrains detail and triggers explanations through close-ended questions. A blank canvas is open-ended. A template is yet another tacit stopping point that hinders deeper analysis. I recommend that we apply templates to incident analysis, but that we use blank documents for the retrospective process.

Driving organizational change

I have learned a lot by working to drive change at Indeed as we’ve grown quickly. My efforts have benefitted from my tenure in the company, experience participating in hundreds of incidents, and connection to the literature. I have made headway but there is still a lot to do.

I attribute some of my progress so far to finding other advocates in the company and remembering to communicate.

Find advocates

Advocates are colleagues who align closely with my goals, acknowledge where we could be doing better, and share a vision of what could be. I had no trouble finding these advocates. They are colleagues who are willing to listen, have an open mind and have the patience to consider another perspective. I held numerous 1:1s with leaders and stakeholders across the organization. I found opportunities to bring these topics up during meetings. I gave tech talks and reached out to potential advocates whenever I visited one of our global Engineering offices.

Over-communicate

As much as I might think that I was communicating what I was working on, it was never enough. I found I had to constantly over-communicate. As I over-communicated and leveraged multiple media, I may have sounded repetitive to anyone in close proximity to my words. But this was the only way to reach the far edges of the organization who might not have otherwise heard me. Not everybody has time to read every email or internal blog post.

Looking ahead

Response to these changes has been largely positive. The focus during retrospectives is still anchored to the technological factors, when more attention could be paid to the human factors. I’m exploring different avenues for increasing the reach and effectiveness of these efforts. This includes working with our instructional design team to create a debrief facilitator program, communicating more often and more broadly, making more process changes, continuing to help teams produce and share high quality write-ups, and focusing on producing educational opportunities. At this point we’ve only scratched the surface and I’m looking forward to what we will accomplish.


About the author

Alex Elman is a founding member of the Site Reliability Engineering team at Indeed. He leads two teams: one that focuses on Resilience Engineering and one that supports the flagship Job Search product. For the past eight years Alex has been helping Indeed adopt reliability practices to cope with ever increasing complexity and scale. Follow Alex on Twitter @_pkill.


Improving Incident Retrospectives—cross-posted on Medium.