Why Queer-Inclusive DevOps Is More Effective

AKA “The Agile Approach to Rainbows”

The intention of this post is to give a brief presentation and explanation of data regarding LGBT+ people in tech, and how that data relates to teams practicing DevOps.

The CA(L)MS Model

The CA(L)MS Model is a model developed by Damon Edwards and John Willis, intended to give a simple formula for organizations looking to adopt DevOps.

Image description: A triangle is separated into four different layers. The bottom layer says Culture, the layer above Culture says Automation, the next layer says Measurement, and the top layer says Sharing. Between the Automation and Measurement layer, an arrow leaves the pyramid and has “Lean” above it. Each layer has an arrow leaving it with a description of each concept, which are also described in the text below.
It’s like a more agile Maslow’s Hierarchy of Needs.

Starting from the bottom, we have Culture.

Culture in this definition is how team members interact with each other. It primarily focuses on encouraging team members to learn; embracing failure as a method of learning; and having trust in other teams. It is the base of the pyramid, because team culture informs the rest of development, sharing, and measurement. Without a supportive culture, DevOps can’t thrive.

The next layer up is Automation.

Automating what you can (within reason) allows people to focus on what’s actually in their work. Ops folk can focus on improving systems, security folk can focus on predictable behavior and paperwork, developers can focus on developing, and all of those things free up your teams to invest in important and fulfilling work.

Lean can be added after Automation, and while I think the placement of it is entirely based on the fact that we can say CALMS model instead of CAMS model (which makes Google searching at work a bit spicy), Lean means a team must eliminate waste; build quality in; create knowledge; defer commitment; deliver fast; respect people; and optimize the whole. Read more about Lean here.

Next we have Measurement.

Succinctly, Measurement is “You can’t fix what you don’t know is broke”. You need metrics, monitoring, and logs to make sure your systems are up, and by getting more information about your systems you can identify bottlenecks and improve them.

The top level of the model is Sharing.

DevOps is great when it’s used for teams. A single DevOps practitioner doesn’t influence much in an organization, but a DevOps organization is powerful. By sharing processes, knowledge, and information, we can build flows informed by each other, not ignorant of each other.

I want to dive a bit further into the Culture block of this model, because it is the foundation of the rest of the model. According to the model, to have a learning culture you need a safe environment for questions; cross-functional teams; embracing failure; embracing innovation; and trust in other teams.

This is a great breakdown of successful cultural norms to establish in your organization. A safe environment for questions fosters a learning mindset. Team members can show ignorance or vulnerability on a topic and they’ll receive a validating answer. Cross-functional teams allow people to work with other fields and gain a broader understanding of the organization and products’ needs. By embracing failure, management gets more comfortable with investing in new ideas and creates more risk acceptance rather than risk denial. Embracing innovation closely follows embracing failure, because not every innovative idea will work, but every innovative idea is worth at least acknowledging, and innovation breeds further innovation. Finally, trust in other teams allows the organization to function cohesively, without hiding work from others.

What surprised me in reading about the culture block is that it doesn’t explicitly talk about the people that make up the teams. It doesn’t talk about how our identities affect our work.

So who are we, really?

The DevOps community is blessed with people of diverse ideas and backgrounds. I watched Heidi Waterhouse give a talk at the that humanized data and how we maintain it; Kelsey Hightower taught me how to use Kubernetes through online courses; Erica Joy’s insight to software engineering as a black woman has changed how I approach diversity and inclusion in the workplace. (Special hello to Bridget Kromhout as well, a fellow Midwesterner and a community organizing powerhouse.)

Image description: Kelsey Hightower presenting at HashiConf, triumphantly raising his fist in emphasis of something, likely Kubernetes related.
Image description: Kelsey Hightower presenting at HashiConf, triumphantly raising his fist in emphasis of something, likely Kubernetes related.
You’d raise your fist at the sky like this too if you could convince k8s to follow your will.

We also know that diversity drives productivity and innovation. In a global workforce, companies are constantly looking for how to make more effective connections with their communities. Studies done as recently as January 2018 show that diverse teams are incredibly good for business. In fact, heterogeneous teams are better exactly because of their heterogeneity. They challenge each other because they aren’t the same. After a brief period of slowed productivity, diverse teams regularly outperform homogenous teams because the team has overcome communication challenges and thinks more about what they’re doing before they do it. A team that challenges each other, succeeds together.

The question is then raised: why aren’t our teams more LGBT+ inclusive?

According to the Tech Leavers study done by the Kapor Center in 2017, which surveyed people who voluntarily left jobs in tech, “LGBTQ employees were most likely to be bullied (20%) and experience public humiliation or embarrassment (24%), both at significantly higher rates than non-LGBTQ employees (13%, p<.01).” According to the U.S. Transgender Survey in 2015, 27% of transgender people report being fired, not being promoted, or not being hired due to their gender identity. 70% of non-LGBT+ employees think it is “unprofessional” to talk about sexual orientation or gender identity in the workplace, as discovered by the study The Cost of the Closet and the Rewards of Inclusion, done by the Human Rights Campaign in 2014. Finally, in a survey of 61% of Facebook employees (not just in engineering) in 2016, only 7% identified as LGBT+.

What’s relevant about that last statistic is that Facebook’s main HQ is in Silicon Valley. I know for a fact, as a member of the LGBT+ community, that Silicon Valley is Really Gay. If the percent of LGBT+ employees at a company in Silicon Valley is that low, something has gone horribly wrong with our industry.

I also haven’t mentioned intersectionality yet, which must be discussed before moving forward. Not only do we have to think about LGBT+ identity in our teams, but we have to think about what other identities people may bring to the table. If a person is black and LGBT+, their experiences in tech will differ from a white LGBT+ person’s experiences. Both are valid, but they are different. We can look at disabilities, race, gender, sexuality, immigrant status, financial status, and a variety of other factors that inform how they live their lives. If we were to break down data of LGBT+ employees in tech into further marginalizations, I can only suppose that those numbers would get abysmal, and we must do better.

How does this apply to my team?

Now you may be asking, “What does this mean for our DevOps teams?” Like, sure, gay shit’s great and all, but how is that on topic for my product delivery?”

Let’s revisit those things you need for a learning organization: a safe environment for questions, cross-functional teams, embracing failure, embracing innovation, and trust in other teams.

Certain things are compromised when an LGBT+ employee is added to a team. A trans team member may not feel safe being vulnerable at work, because they’re afraid they’ll get fired because of their gender identity. Another team member may have worries that the team she just got embedded on will exclude her because she’s gay. Suddenly, social stress is added to your team member’s work-life balance.

“Well, let’s just not hire LGBT+ team members, right? We can avoid the cultural rehab we need to do and focus on our work instead.”

See the productivity and team efficacy points from above.

“We don’t have the time or resources to fix this! Our servers exploded last weekend and we have 500 tickets from angry students and professors! Our deadline was a month ago!”

Chances are you have some other problems going on besides just cultural, but…

Can you afford $16,000,000,000?

The Kapor Center’s Tech Leavers study shows that “[b]ased on current estimates of average costs for replacing professional employees, each person who leaves a tech job will cost companies an average of $144,000 per employee for full replacement costs (lost productivity, recruiting costs, salary, etc.). Nearly 40% of this sample of tech employees reported leaving their jobs due to unfairness. Based on this data, the annual yearly cost to tech employers for turnover due to unfairness totals over $16 billion per year.”

Furthermore, your organization’s reputation is damaged. The Tech Leavers study continues on to show that “[w]ithin this study, 35% of former employees said their experiences would make them less likely to refer others to seek a job at their former employer, and 25% said they would be less likely to recommend others to buy or use products from their former employer.”

So every lost employee is $144,000, the largest portion of people in this study that voluntarily left tech jobs left due to unfairness, and your company will lose further revenue and reputation due to each employee leaving. It is in your organization’s best interest to tap into some cultural rehab and retain your LGBT+ (and other marginalized) employees.

Walking in Pride parades won’t make your teams better.

Image description: Many people are lined up holding a very long rainbow banner on a street. The photo is taken from below the banner so only the lower bodies of the people are in the picture.
Image description: Many people are lined up holding a very long rainbow banner on a street. The photo is taken from below the banner so only the lower bodies of the people are in the picture.
Gay parade = gayrade?

A common misconception in cultural rehab of an organization is that you can make people aware of a problem and the problem will go away. People will magically fix themselves! Everyone does an implicit bias test when they’re onboarding and no one’s homophobic ever again.

Trying to fix corporate social homogeneity with an implicit bias test is like trying to fight Godzilla with a marshmallow gun. He won’t even notice you popping marshmallows at him, and you certainly aren’t going to stop him. You need something on the scale of Godzilla to fight Godzilla. Let’s talk about some Mothra-sized cultural work to be done.

1. LGBT+ insurance and healthcare benefits

This one is scary, takes a lot of work, and is one of the biggest ways you can show your LGBT+ employees (and employees with LGBT+ family members) that you care. Investing in their health is a major stress reducer for them. If a trans employee knows that their hormone replacement therapy is covered, they’re not going to worry as much about doctor appointments outside of work. If a parent needs therapy for their LGBT+ child, because being an LGBT+ young person is hard and it’s nice to have someone to talk to, they can focus on their work instead of making sure their provider is competent in LGBT+ issues. Removing external stress is a way to show effort and care for your employees, and creates more trust in the HR-to-employee relationship.

2. Diversity initiatives with measurable goals

Diversity initiatives are only useful when they have measurable goals. Fuzzy goals like “we want to hire more black women” aren’t actionable. They don’t create an impetus to change. Creating very explicit goals, like “we want to hire 20% more black women on every engineering team by 2020”, is an actionable goal with success criteria. Making goals more explicit is an excellent way for retrospective analysis to reveal what your organization is actually willing to invest in, especially if you don’t reach your goal. [Taken from the Kapor Center]

3. Referral bonuses for bringing in underrepresented candidates

By treating underrepresented candidates like people unique perspectives with rare skill sets, it makes perfect sense that they would be extremely valuable hires. Not only that, but underrepresented candidates can sometimes be hard to find. In order to compensate others for borrowing their external time to recruit others they know, and for bringing in a valuable candidate, referral bonuses are a natural extension to reward employees for their contributions to your organization. [Taken from the Kapor Center]

4. Education/support at management/administrative level

Support from a management and administrative level flows down to teams. If teams know that diversity is encouraged and needed on all levels, there is more precedence for marginalized people to find comfort in the organization. Teams are also then allowed to follow an example rather than be the example, and that makes team cohesion easier as well.

Regarding comfort in an organization: personally, if there’s a poor reputation for treatment of trans or LGBT+ folk at a company, I cross them off my list of potential employers. For my safety, I refuse to work for places that don’t value diversity.

5. Protocols for transitioning/coming out/dress codes at work

Do this work so trans and LGBT+ employees don’t have to. Put in work before someone needs it, so they know you’ve considered them and what they might need. If you don’t know what a trans employee might need to transition, or what an LGBT+ employee might need to come out, or how to help a genderfluid person figure out a dress code, feel free to hire a consultant that specializes in LGBT+ issues! Some people may even be willing to do it for free. Plenty of people are happy to talk about treating LGBT+ employees well because it matters to them that everyone is given dignity and respect.

Summary points!

  • Diversity makes teams more effective, but tech isn’t very friendly to LGBT+ folk.
  • DevOps is built on culture and people, but often forgets the people behind the automation tools.
  • Acknowledging, accepting, and protecting LGBT+ and other underrepresented members of your teams increases feelings of psychological safety, trust in other team members, and overall productivity.
  • Not acknowledging, accepting, and protecting LGBT+ (and other underrepresented) employees leads to high, costly turnover rates.

The content of this post was presented at DevOps UMN on 5/17/18.

Sources
Kapor Center Tech Leavers
HRC The Cost of the Closet and The Rewards of Inclusion

Software engineer, non-profit fundraiser, and autistic as heck. (she/they) @jessica_schalz