How to Work Better Together: Building DEI Awareness in Tech

We have a diversity problem in technology. A lot of our visions and standards of success are centered around one group of people, even though there are many groups contributing to global advancement and growth. The main reason for this is legacy - in a similar sense to legacy code at a company. Similar to that legacy code, we can overcome this inherited debt by educating ourselves and planning time to do the work to rebuild and replace our "legacy code".

Current state of diversity in software development

Intentional diversity is fragile. What I’m calling "intentional diversity" is what happens when people make a conscious choice to shift environments (organizations, industries, etc.) to include traditionally underrepresented groups. This requires groups that are currently overrepresented to commit to making space, personal change, and drive organizational change.

It also requires some of those changes to be mandatory, as optional change is usually neglected - not necessarily out of malice, but human nature. We get "stuck" in a way of doing things that result in known outcomes, even if we’re not sure those outcomes are entirely favorable, because we typically prefer known to unknown. This all points to the fact that significant labor is involved, which is my original point: intentional diversity is fragile, and without work done the status quo will self perpetuate by default.

How diversity helps to solve problems

Diversity increases space for solving problems encountered by increasing the lived experience of those solving the problem.

The example I give for this is actually a blog post I encountered several years ago, "The Curious Case of the Disappearing Polish S". It’s about a bug that was submitted to the platform: that a user cannot type a diacritic S (Š) in the Medium platform. (Incidentally, I discovered while drafting this post that you also cannot type, or copy-paste, this character in Google Docs.) The author, who was one of the engineers working on the ticket, then goes on to describe a lot of history about the Polish keyboard, based on his experience as a Polish person - specifically why the key combination for a diacritic S is what it is. This experience is what allowed him to identify the problem and know how to fix it.

The reason I highlight this particular example is because it’s unlikely that the author was hired for being Polish, or if he was, he was hired for direct things that people look for: companies expanding into Poland and needing a Polish speaker, for example.

Stories like this are also the reason why I titled the talk "Unquantified Serendipity"; what diversity brings to the table is not always quantifiable. You don’t always know what problems can be solved, or how quickly problems can be solved, by persons not present. There are other situations in which we can see what diversity does bring to the table, or didn’t, by its lack. Accessibility and ethics in development is a big area to showcase the latter. When you haven’t designed with screen readers in mind, or with black people in mind and so on, it’s both painfully obvious and common.

The impact of normalizing the appearance of minorities in the software field

Normalization is a step in the right direction, but needs to be done in a way so that the burden falls primarily on the overrepresented groups to make the space, not on the underrepresented groups to take the space. I’m being very explicit about this, because one unfortunate pattern we see is to say with words that underrepresented groups are welcome, but not doing additional work to ensure that is the case in reality.

To be clearer: the expectation should not be to normalize in the sense of "look different from us, but act like us, and we’ll treat you fine". The goal should be for overrepresented groups to accept those who look different from us and act differently, dress differently, have different disabilities, different gender expressions, and so on, and for all of those people to still be safe.

You can see this at the corporate level with dress codes. Usually dress codes are made with the intention of standardizing a professional appearance; however, as with all non-inclusive standards it’s common that company dress codes are more restrictive toward some than others, even if it wasn’t intended at the outset. For example, dress codes:

• Tend to be more restrictive toward women vs men in the gender binary, or even more restrictive to non-binary and trans persons than cis persons beyond the binary.
• Tend to favor people in a certain age range.
• Tend to favor certain races.
• Tend to favor people with an assumed level of financial security, assuming they have already purchased or can afford to purchase the correct wardrobe for the job.
• Tend to favor people without visible or invisible physical limitations; for example, can the dress code safely be adhered to by people who need a wheelchair or insulin pump?
• Tend to favor people from the dominant religion of the area. As a specific example, for a company in a Christian-majority country, is wearing a hijab in compliance with the dress code?
• Tend to be unequally enforced. As another specific example, can a woman bend the dress code to wear slacks, even if the dress code doesn’t allow for it? Similarly, could she also bend the dress code to wear her hijab? If she weren’t Muslim, could she bend the dress code for a cross necklace even if religious jewelry isn’t otherwise allowed?

There are even more considerations than these, these are just the first seven to get you started thinking of ways in which something that appears to be inclusive to you might not appear as inclusive to someone else.

Overcoming the barriers to increasing diversity

In order to overcome the barriers, you need to be aware of them. The barriers themselves are whole bodies of research, but let’s look at a few common barriers in the industry to start thinking about the problems they cause. Barriers to diversity in an industry is commonly referred to as gatekeeping, where there are requirements for a hire that are not needed to perform a job. I’ll briefly talk about a few from my own experience: college / university degrees, entry level gatekeeping, and perception.

Gatekeeping via university degrees is very common where I’m from (the United States). There are some disciplines where an underlying degree helps you professionally as it prepares you for your intended field - but this is not always the case. Usually when a degree is a gate, it’ll appear on a list of job requirements as "a college / university degree", or "a two-year / four-year degree", without listing what area or areas the degree needs to be in.

Increasingly, we also gatekeep on existing experience. By that I mean the problem that those new to our industry experience when they need to "get experience to get experience". This happens when entry level roles already require some number of years of experience as a condition of hire. Without "year 0" opportunities, then the only people in the available job pool will be people already behind the gate and that number will decrease over time as people change industries, retire, or even want to go on holidays or sabbaticals.

Perception of what success looks like is also a major barrier to success. A great example is the previous section, where I outlined groups of people who are not normally included in dress code; not normally actively, but rather invisibly due to lack of representation or lack of awareness of those currently in the majority. A way to start self testing for this is to see what comes to mind when I say "successful engineer", "manager", or "CEO". Specially: what do the people in those roles look like and sound like, by default, in your mind’s eye? These unconscious biases hold us back from being able to truly accept and uplift our colleagues.

There are other ways that mindset matters as well, and that has to do with how you approach situations as well as how you give and receive feedback. I’ll discuss feedback a bit toward the end, as there’s more to cover there, and start here just with approaching situations. Our subconscious is wired to make snap judgements based on what we know of a person, which before we actually know a person is based on what we see and/or hear. This informs all sorts of decisions, even ones as simple as when a mentee or colleague asks for information or advice: are the answers they’re given typically only answering exactly what they’ve asked and nothing more? Do we answer the request more or less thoroughly assuming their proficiency level without asking? As one-offs, our individual answers might not matter so much, but once you start reading about the systemic impact of unconscious biases you’ll see that certain groups are consistently responded to with certain assumptions of more or less aptitude, more or less career growth, and so on.

My goal with being clear on how much there is to research, and that the above is only a short list, is to set this expectation early on: you’ll need to pace yourself. This can and will be hard, as there is a lot wrong with our world.

That said, in order to do the work to actionably improve, you need to keep yourself motivated to continue the work that needs to be done, both in yourself and in our societies, without becoming overwhelmed, burning out, and stopping.

Where to go from here?

Learning is a journey and while this is no different, it can feel different. Part of that is because we started learning the lessons that we’re unlearning so early that they feel like part of our core selves. It can be a bit like learning that gravity doesn’t work the way we thought (enter, physics) and having to rethink all the assumptions we’ve made based on that. That process will be long, and can be frustrating. Being able to practice being uncomfortable, to work through that frustration, is crucial to your journey. Feedback is a gift, and as you’re more able to navigate your negative emotions you will encounter more willingness from others to teach you what you don’t already know. To practice this, sit back for a moment and think of a time when you received feedback that was uncomfortable, but accurate, and how you reacted internally and externally. Once you’ve reflected on that, think of a time when you received feedback that was uncomfortable, but inaccurate, and again how you reacted internally and externally; how you felt in these situations, how you treated the other person in those situations. Try to think of a way that you could have internalized better and treated the other person better. Practice and reflect on this often so you can increase your ability to take feedback from others as you learn and grow.

About the Author

Quintessence Anx is currently a developer advocate at Pagerduty after a long tenure in Ops and IT roles. Outside of work, she co-founded Inclusive Tech Buffalo and mentors underrepresented groups to help them launch sustainable careers in technology.  This article is based on her talk Unquantified Serendipity: Diversity in Development, which she gave at A Day of Organisational Psychological Safety by Aginext.