Engineering Gender-Inclusivity into Software: Tales from the Trenches

Although the need for gender-inclusivity in software itself is gaining attention among both SE researchers and SE practitioners, and methods have been published to help, little has been reported on how to make such methods work in real-world settings. For example, how do busy software practitioners use such methods in low-cost ways? How do they endeavor to maximize benefits from using them? How do they avoid the controversies that can arise in talking about gender? To find out how teams were handling these and similar questions, we turned to 10 real-world software teams. We present these teams experiences “in the trenches,” in the form of 12 practices and 3 potential pitfalls, so as to provide their insights to other real-world software teams trying to engineer gender-inclusivity into their software products.

💡 Research Summary

The paper investigates how real‑world software teams translate the abstract goal of gender‑inclusivity into concrete development practices. While academic literature offers numerous frameworks and guidelines, practitioners often struggle to apply them due to time, budget, and staffing constraints. To bridge this gap, the authors conducted in‑depth interviews and observations with ten diverse software teams that had attempted to embed gender‑inclusive methods into their products. From these “trench” experiences the authors distilled twelve actionable practices and three cautionary pitfalls, presenting a pragmatic roadmap for other teams.
The twelve practices fall into three lifecycle phases. In the requirements phase, teams introduced a “inclusive language guideline” and a “diversity checklist” to ensure that user stories, documentation, and stakeholder communications avoid gender‑biased terminology from the outset. In the design and implementation phase, they created richer user personas that explicitly represent a range of genders, ages, and cultural backgrounds, and they ran scenario‑based usability tests to surface any gender‑specific friction. Code reviews were augmented with a “inclusivity checkpoint” and automated lint plugins that flag gender‑biased naming or logic. In the deployment and operations phase, teams set up automated feedback loops (e.g., surveys, bug‑report triage) to continuously monitor real‑world usage for inclusivity issues, established community‑monitoring processes to detect hostile discourse on external forums, and institutionalized regular training workshops to keep the topic visible. Additional cross‑cutting tactics included running low‑cost pilot projects to validate changes before scaling, building internal expertise to reduce reliance on external consultants, and fostering a sense of collective ownership so that every team member feels responsible for inclusive outcomes.
The three pitfalls identified are: (1) politicizing the discussion, which can inflame intra‑team tensions; (2) treating checklists as a box‑ticking exercise without linking them to measurable user experience improvements; and (3) over‑reliance on specialized gender‑inclusion experts, which raises costs and undermines long‑term sustainability. The authors recommend mitigating these risks by starting with small, well‑scoped pilots, iterating based on concrete data, and embedding inclusivity into the team’s cultural fabric rather than treating it as a one‑off compliance task.
Overall, the study contributes a field‑tested, low‑cost, high‑impact set of practices that can be adopted by organizations of any size—from startups to large enterprises. By grounding gender‑inclusivity in everyday development rituals and by highlighting both enabling strategies and common traps, the paper offers a valuable guide for software engineers, managers, and researchers seeking to make their products more welcoming and equitable for users of all genders.