The technology industry continues to struggle with its diversity problem. However, having delivered enterprise software for well over a decade, I think the root cause of—and the solution to—this problem is easy to understand. Anyone who has been tasked with debugging software can understand the solutions and begin immediately implementing them. I was reminded of this when my daughter experienced an issue with one of her first grade classmates.
Diversity is Elementary
I am the father of three kids, ages ten, nine, and seven. The two oldest are boys, and my youngest is a girl. While I love all of my children, my daughter has a special place in my heart. I adore her smile that shines when she laughs, the way her eyes widen when she makes a joke (she is hilarious!), and the many ways that my wife braids her curly hair. She is involved in many activities like ballet, soccer, and piano, but, like any Geek Dad, I am especially interested in her schooling. She always earns high marks in school and brings home arts and crafts that I always think are remarkable for a first grader.
My daughter is the only black student in her first grade class. She and the other students in her class were given an assignment to draw a picture of their families. My daughter started her project and drew a picture of her two brothers, my wife, and me. However, one of her fellow students saw her picture and said, “You drew your dad wrong. He should be holding a gun with a bunch of dead bodies around him. Because he’s black.” This was not the first time my wife and I were put in a position to address the black experience of our kids as they navigate through mostly white schools. I am sure that it will not be the last.
“You drew your dad wrong. He should be holding a gun with a bunch of dead bodies around him. Because he’s black.”
The Perceptions Game
Diversity in technology is often presented as a numbers game. Huge companies such as Google, Facebook, Yahoo, Linkedin, and others jump-started the conversation about diversity in tech a couple of years ago by publishing their diversity numbers. While numbers are necessary, however, they are insufficient to fully solve the diversity problem in tech. In fact, many white people work in tech probably saw the published diversity numbers and wondered what they had to do with them? After all, they’re just developers or system admins or software project managers. Furthermore, they’ve never engaged in the racist or sexist behavior that are hinted at by the numbers. They’ve never used the n-word, never killed people at a church simply because of their skin color, never groped a woman in a bar. They’ll readily admit that those behaviors are horrible. My daughter’s first grade classmate never did any of those things, either, but her actions were still destructive. And her actions were driven by her perceptions. Diversity is not primarily a numbers game. It is primarily a perceptions game. And these perceptions are easy to understand. You don’t have to be much smarter than a first grader to get them.
It was somewhat fitting that I initially presented the ideas in this article at CodeConf 2015 in Nashville, the capital of Tennessee, which was the last state to secede from the Union. Alexander Stephens, the vice-president of the Confederacy, which included this state and my home state of Texas, said these words about the new nation that would be created by the Southern states shortly before the Civil War began:
“…its foundations are laid, its cornerstone rests, upon the great truth that the negro is not equal to the white man; that slavery, subordination to the superior race, is his natural and normal condition.”
Although the Confederacy ended more than a century ago, the perceptions that Stephens shared in his speech still linger. While the violence of the Civil War has ended, we are still subject to the damage of those perceptions. While it is easy to see how damaging these perceptions are when acts of violence are reported in the news, the subtle ways in which they affect our society are far more destructive. While flags can be removed from state buildings and statues torn down, the perceptions that drive inequality are much more difficult to destroy.
Furthermore, I believe that the technology sector is more vulnerable to the pain caused by a lack of diversity, precisely because we think that we’re different. “Talk is cheap, show me the code,” right?
However, we are not different. We are not immune. Yet, we are positioned to solve our diversity problems in ways that people in other industries are not. This is especially true for software developers. I’ve developed enterprise software for almost two decades, and I’ve seen the structured thinking and problem solving skills required to be successful. I challenge all of my tech industry peers to think of the technology field as a software system and the lack of diversity as bugs in the system. By thinking this way, they can see that they already have what it takes to not only understand our diversity problem, but also to know their role in debugging diversity in tech.
While it is easy to see how damaging these perceptions are when acts of violence are reported in the news, the subtle ways in which they affect our society are far more destructive.
The Diversity Debugging Tools I have developed are based on the code debugging techniques of Expected Behavior, Tracing, Refactoring, and Sample Code.
The Principle of Expected Behavior
Let’s start with the Principle of Expected Behavior. I’m the Scrum Master (facilitator, in tech parlance) for a team that is trying to get a release out, and we are dealing with a lot of bugs. So, debugging is fresh on my mind as we try to harden our product. In fact I’m seeing bugs everywhere. When I’m checking out at the grocery store, I see bugs in that horrible experience. Seeing bugs everywhere can get me in trouble, though. I’ve been married for 13 years, but a lot of my buddies have divorced and are dating much younger women. When they introduce me to their dates, I have to remind myself to keep quiet about the bugs I see in that situation.
But, back to my team. As we fix the defects reported by our quality assurance team, we often have to remember that the first step in understanding a bug is knowing the expected behavior of the feature. The first debugging principle we can apply to fixing the diversity defects in technology, then, is the Principle of Expected Behavior. We cannot understand the problems caused by a lack of diversity in tech without knowing the expected behavior of technology environments. Whether it is a workplace, conference, or happy hour, most white males in technology understand and benefit from the behavior patterns they expect from others. However, they often fail to see how underrepresented groups are often denied those benefits.
I have a friend who is the founder of a successful startup called The Muse. Kathryn has shared an experience that I’ve heard echoed by many women in technology at all levels. She goes to a happy hour where a bunch of tech founders are having drinks. Someone turns to her and asks, “So, which one is your boyfriend?”
People of color, women, and LGBT people are exposed on an almost daily basis to behavior that the majority of people in tech would never expect to receive. The ability to see these lapses in expected behavior is vital to helping the technology sector understand that the key problem behind diversity is a lack of inclusiveness.
The Principle of Tracing
Since software programs are often very complicated, debugging them is often made easier by seeing the output of the underlying code. This is done by tracing, which is the practice of displaying output as the program runs. Just as we can trace code to detect small defects in it, we can turn on your diversity tracers and see the often subtle ways that underrepresented groups are excluded from information and exposed to micro-aggressions by the dominant demographic.
People of color, women, and LGBT people are exposed on an almost daily basis to behavior that the majority of people in tech would never expect to receive.
I know a woman of color who shared her experiences as the only black person on an IT team at a large and well-known tech company. She has shared her experience of working with a white co-worker who held ridiculous stereotypes about black people. He assumed that she was abused by her parents as a child and by her then-boyfriend. It’s amazing that someone who was abusing her was fascinated with her fictitious history of abuse. At other tech jobs, she was often compelled to join the team at beer taverns despite not liking beer, learn classic rock songs, a genre that she did not care for, so that she could play Rock Band with her colleagues, and was often mistaken by those new to the office for an administrative assistant or security. Her experience is the norm for people of color in tech. We all too often have to lose our lives to earn a living.
If someone had their diversity tracers on, they could have spotted this. For example, why assume that everyone wants to drink alcohol? Even if the majority of the team loves drinking, be sensitive to those who do not. Everyone can step through the cultural code of their workplace and see if someone is being hurt by it. You simply need the willingness to pay attention.
The Principle of Refactoring
While the allure of adding new features to a program can be powerful, legacy code (a type of source code) is made easier to maintain and less costly to develop by refactoring. Refactoring is the practice of restructuring and improving the internal design of code without changing the external functionality of the system. Diversity refactoring is a good way for technologists to begin making the technology industry a more inclusive one. This is the process of improving the internal structure and design of how underrepresented groups are viewed in tech.
Let me give you an example of how to refactor diversity. A few years ago, a famous founder of a giant technology company stated that he uses the “airport test” during interviews as one way to determine if a candidate should be hired. The airport test is applied by asking yourself if you would want to be stuck in an airport with the candidate. Due to the visibility of the founder who described the airport test, it became a popular part of the selection process at many tech companies. However, it is a terrible way to hire people, especially if you want a diverse workplace.
Everyone can step through the cultural code of their workplace and see if someone is being hurt by it. You simply need the willingness to pay attention.
First, how does a hiring manager’s personal tastes determine if someone is fit to perform a job? Second, the airport test is meant to determine if a candidate fits the “culture” of the organization. Well, if the culture is composed solely of white males, then guess what groups are most at-risk when it comes to failing the airport test? After all, how many hiring managers have been stuck at an airport with a black person? Or with a female co-worker? The airport test is a way to perpetuate a non-diverse workplace.
So, let’s refactor the airport test into the workplace test. Instead of wondering if the candidate would be someone they wouldn’t mind being stuck at an airport with, hiring managers should ask how the interviewee has solved problems at other workplaces. How have they reduced the amount of bugs that are reported after a release? What are some good practices for introducing a new developer to the team? How can developers better understand the end users for whom they are building software? The workplace test takes the “I” out of the selection process put there by the airport test and replaces it with the needs of the company. We have to stop trying to hire cultural rockstars. Make our companies the rockstars by making them more inclusive.
The Principle of Sample Code
One way to debug code is to see a sample of similar code that runs well. Essentially, another programmer “lends” you code that helps you fix or prevent defects. Just as a person can “lend” code to another person, you can “lend” privilege to someone else. This is the Diversity Debugging principle of Sample Code. This principle can be used by helping underrepresented groups get access to information and events that naturally flow to the dominant demographic in most technology companies. So, men at technology companies can help women by letting them know about the golf outing next weekend that the guys talked about while playing pick-up basketball during lunch. When a group of men are discussing a topic and one notices that a woman, who knows the topic well, is being ignored, it is imperative for him to say, “I’d like to hear what she has to say.”
When a group of men are discussing a topic and one notices that a woman, who knows the topic well, is being ignored, it is imperative for him to say, “I’d like to hear what she has to say.”
I did this a couple of years ago when I was putting together a panel for South by Southwest Interactive. Getting a panel accepted there is an extremely competitive process. I had successfully done so three times in previous years, so I knew the components of a great panel. One key factor is the quality of the people you list in your proposal. I had several men in mind with high profiles in tech. However, I knew a user experience designer based in Mexico, and, since my proposal was about design, I decided to team with her for our dual panel proposal. It was a risk because she was far less well-known than the men I could have selected. However, as someone with male privilege who had previously spoken at SXSW several times, I wanted to lend her some of my privilege as a speaker there. Our panel was accepted, and she gained a credential that helped her get her own panel accepted the following year and also fuel her own startup journey. You’d be surprised how useful it is for a female startup founder from Mexico to introduce herself to male investors as a speaker at South by Southwest.
Call to Action
The question I pose to my peers in tech who are empowered to debug diversity is, “What will you do with your power?” I have a suggestion: when the treatment of marginalized groups in tech is discussed, it is often done in silos. Women talk with women, people of color talk with other people of color, LGBT technologists with other LGBT technologists. Why don’t these conversations ever happen by those with privilege? We can start by taking one aspect of our privilege and finding someone else with that privilege and having open and honest conversations about our perceptions of people who lack our shared privilege. Men have to get with other men and discuss topics like GamerGate. Straight people have to get with other straight people and talk about gay marriage. We should actively use the diversity debugging techniques I just outlined.
We have to think of these conversations as diversity pull requests. Like most pull requests, they represent how thinking has diverged from the general perception of diversity and a desire for others to consider the changes. Perceptions only change if we’re willing to interrogate the reality of our shared privileged experiences.
These are our diversity pull requests. They must be used wisely.
