Building for Intersectionality in Tech: Intersectionality and Software Engineering
By Nicole Thayer & Tiffany Wong
Note: This is the third post in this blog series on intersectionality in tech. Check out the first, second, and fourth posts.
Welcome back to our ongoing series about how employees at Carbon Five are approaching conversations about intersectionality in tech. For more information on why we’re doing this and what we’re hoping to accomplish with the series, please read the introductory post.
A quick survey with a few engineers at Carbon Five about which areas of technology feel ethically risky to work in these days revealed that there is no shortage of concerns: algorithms that determine credit worthiness, bias in facial recognition software, recidivism prediction, risk assessment for access to healthcare — the list goes on. Many areas of technology have been revealed to perpetuate systemic harm on already marginalized communities.
The role of a software engineer in this conversation can be tricky. How much responsibility can an engineer take on the consequences — intended and unintended — of a finished product? We’ll discuss some common challenges engineers can encounter when considering intersectionality in our work, as well as opportunities to be more mindful of these issues — both in our code and on our teams.
Roles and Responsibilities
Engineers typically don’t make the call
A common understanding among engineers is that while we can raise product issues, there is no guarantee that they will be addressed.
“Oftentimes the challenges with the day-to-day work live within the fact that stakeholders determine the work we are doing. They set priority. There are times where that priority comes from a very specific perspective and their view is not open to a more intersectional lens.”
— Anna Neyzberg, Carbon Five Engineer
It’s difficult to advocate for “non-critical” scope on projects that are facing looming deadlines, which in most instances are most projects.
Still, engineers at Carbon Five agree that it is the responsibility of each individual to raise concerns as they arise, and that the process can be as simple as starting a conversation. Former Carbon Five engineer and VP of Engineering at Anova Culinary Lilei Huang chooses to start the conversation by giving decision makers the benefit of the doubt.
“If I were asked to work on a feature that goes against my values, I may raise my concern first with a client because they may not be aware of the issue,” Huang said.
Carbon Five engineer Gabrielle Taylor suggests asking questions frankly.
“If there were a real estate and property value mapping app, I might ask at an early stage, ‘Can we talk about the potential that this feature has to contribute to gentrification in this area?’, or ‘Can we avoid overlaying crime data in such a way that might cause people to avoid investing in disadvantaged communities?’” Taylor said.
Starting the conversation early and in a way that encourages collaboration rather than blame is a great way to not only boost morale at the start of a project, but also ensure that everyone has the opportunity to build a better, more inclusive product.
It’s worth noting though that belonging isn’t built into every team and if psychological safety isn’t prioritized and regularly experienced, it could be harder for certain individuals to speak up in an environment where they are uncertain how the conversation will be received. Carbon Five engineer Mitch Saltykov believes allyship and advocacy plays an important role in these instances.
“One tactic I’ve put to use is to act as a conduit between more marginalized people and leadership positions,” Saltykov said. “As a senior, white, cis, male, there are ways to quietly support without stepping on the voices that need to be heard. I try to listen to, highlight, and support folks of other identities who have ideas to contribute.”
Engineers typically have control over the solutions
While engineers typically aren’t the ones coming up with product specifications, we are always the ones implementing the ideas — a process that without consideration can bring negative, unanticipated results.
“One of the most troubling and impactful trends is applying large-scale, Big Data approaches to problem-solving with opaque algorithms. This opacity could be intentional, such as when a teacher evaluation system is legally prohibited from being exposed to the teachers it affects. Or it could be accidental, where devs don’t know why a machine learning system works the way it does anymore, but still trust it anyway. Both are opportunities for unchecked large-scale harm.” — Mitch Saltykov
With looming deadlines and full backlogs, it can be easy for busy engineers to place a lot of trust in third-party tools, and consequently, a lot of trust in the hands of the companies that create these tools. However, as we become more aware of areas where harm has been done, opportunities exist for engineers to play an active role in how a feature is implemented and what data sets are chosen to be included.
“Anything that checks whether people should be approved for loans or creditworthiness, or that checks to see if property investments make sense, or screens people for the likelihood of health issues, or which otherwise surfaces information and is meant to be used as a tool in decision-making should be viewed through a very critical lens to ensure that it does not enable or perpetuate existing systemic bias,” said Taylor.
Considering solutions for multiple intersections
While discussions around intersectional harm often focus on the most visibly marginalized communities, it’s important to also acknowledge the people who have additional barriers to using a product because of its lack of accessibility. For however difficult accessing content on a web page or mobile app can be for individuals, there exist a number of well documented tools and automated solutions for detecting accessibility barriers that UI engineers can easily take advantage of.
In “Investing in your accessibility workflow”, Yuraima Estevez details a number of tools including eslint-plugin-jsx-a11y, axe-core, and Lighthouse that can be implemented to solve accessibility challenges. From adding ARIA tags to keyboard shortcuts, or form validation to proper error recovery, solutions exist to help make sure that the web stays open to anyone who wants to access it, and engineers don’t need advanced training to make it happen.
Agile creates space for dialogue
In asking ourselves when issues can be brought up during the software development process, we realized the opportunity is actually present at all times. Teams practicing agile development are quite conducive to ensuring that intersectional concerns are addressed. From sprint planning to retro, and code review to QA, our engineers agree that every step of the agile process can be a potential starting point for having a conversation on intersectionality with teammates.
Conversation Starters
Daily: I’ve been thinking about how <feature> might impact <non-dominant user group>. Does anyone want to set up a separate meeting to discuss?
Backlog Prioritization: When will we get to researching the impact of <potential harm> this work has on <non-dominant user group>?
Retrospective: I wish we had considered how <non-dominant user group> might interface with <feature> and would like to figure out how we can address this better next time.
Code Review: Where does this dataset come from? Have we done research into how this data is gathered and how representative of our users it is?
Acceptance: How can we test how <non-dominant user group> uses this new feature
Carbon Five Director of Engineering Matt Brictson pointed out that pair programming also provides an opportunity to bring more diversity of opinion to interpreting requirements and implementing solutions.
“In software there are gray areas everywhere in the sense that a story in a backlog can never fully specify what the computer needs to be instructed to do,” Brictson said. “That is up to the engineers to interpret, and lots of micro-decisions happen at this step.”
Thinking through these micro-decisions in a pair can almost always ensure the presence of additional discussion and more thorough considerations. After all, an additional set of eyes not only brings added technical knowledge, but also added lived experience and perspectives.
Building Intersectional Teams
While it seems like almost every company (including ours) recognized the need to bring in experienced leadership to guide diversity, equity, inclusion, and belonging efforts this past year, it’s important to remember that DEIB is practiced at every level of the organization and has tangible effects in every role.
The case for inclusion
“Engineering teams are often fairly homogenous and have serious blind spots in how products are built.” –Anna Neyzberg
There have been wide-ranging discussions on the importance of diversity in the workplace as a means to increase profit and boost innovation. The general idea is that people of different backgrounds and experiences will approach problems in different ways and, compared with a homogenous workforce, come up with more novel solutions. However, hiring for diversity without a means to ensure inclusivity means that diverse ideas could still be met with strong opposition.
Neyzberg points out a term in psychology called the “fluency heuristic,” a mental heuristic in which, if one object is processed more fluently, faster, or more smoothly than another, the mind infers that this object has the higher value with respect to the question being considered.
“The more easily you are able to understand something, the more value you give that thing,” Neyzberg explained. “If a team is mostly homogenous and working from a mostly similar perspective, oftentimes the ideas given by the majority team tend to hold more weight. If an opinion is offered by a member of a team that is underrepresented and it differs from the majority opinion, the opinion of the individual that is underrepresented may hold less weight.”
We mentioned earlier that allyship can play an important role in these situations if members of the team recognize how they can be allies, and that there are many ways to put concrete action behind that word. Education and building a culture of curiosity where unfamiliar ideas are regularly met with follow-up questions instead of negativity is a great starting point. Listening and processing instead of being quick to respond is another, and finding the courage to be comfortable with discomfort or even willing to give up a little comfort for the sake of considering an underrepresented viewpoint all lead to environments where anyone, regardless of their intersections, can feel a sense of belonging.
Compassionate development
Earlier, we discussed the potential ramifications of not considering intersectionality for the end user, but end users are not the only people who interact with software. Inclusivity on a team where the primary function is to generate code means that the process of code generation is inherently inclusive and considerate of all teammates.
“One of the most valuable takeaways from my last project is the idea of what compassionate development looks like. By that I mean coding in ways to set up the next developer for success. With compassionate development, you don’t make any assumptions about the expertise of any developer. You make an effort to write code that is easy for the brain to parse, follow established patterns to hopefully have a common framework, and you write tests that are not only self-documenting, but that also guard against regressions, so the next person can code with confidence.” – Lilei Huang
Ultimately, intersectional awareness around the technology we produce is an ongoing practice and a responsibility that can and should be shared across the board. Nonetheless, software engineers play an important role as gatekeepers of how real people interact with the ideas that others come up with, and in that role exists a significant opportunity to prevent harm from being experienced by those whose identities haven’t been considered.
Up next, we’ll learn about how product managers at Carbon Five think about intersectionality, including questions about prioritization, persona design, and even more user research.
Click here for more information on Carbon Five’s internal efforts around diversity, equity, inclusion, and belonging (DEIB). If you’re in the tech industry and interested in exploring DEIB issues, we’d love to work with you!We’re always taking on new projects and hiring folks who are interested in making the tech industry a better place to work.
We’re hiring! Looking for software engineers, product managers, and designers to join our teams in SF, LA, NYC, CHA.
Learn more and apply at www.carbonfive.com/careers
