In the last editorial, I wrote about how it is obvious from what we see and read that Tech is not neutral nor apolitical, how this has lead to a narrowing of perspective, and that empathy is not enough to replace the authentic lived experience and therefore the knowledge of a diverse group of people.

This realization is reflected in the first two of the #causeascene Guiding Principles, created by Kim Crayton:

• Tech Is Not Neutral
• Intention Without Strategy is Chaos

I experienced just recently how true that second statement is on a very practical level: When I took over a legacy project two and a half years ago, I intended to improve its quality. I started to write automated self-tests for any new or changed functionality and encouraged my co-workers to do the same. The intention was good, but I did not develop a clear strategy for what tests should be written, how they should be written and organized, how they should be measured, evaluated and managed.

It worked for a while, but there was a point where running the test suite took so much time that it significantly decelerated development speed. Tests were also flaky, duplicated or so broad that their failure didn’t tell anything useful except “something is wrong.” In the end, while my intentions were good, my lack of strategy damaged the quality of the project instead of improving it.

Let’s get back to the lack of diversity and inclusion in tech teams – why is this even problematic?

Lack of Inclusion is a Risk Management Issue

In a globalized market where our products reach thousands, probably millions of people, a lack of perspective will become a significant disadvantage. To create great products and services, we will need to include the lived experience of people that are different to us, especially: of the people that are closest to the impact of the potential issues in our products. They are the ones who will see the problems we won’t because these problems impact their lives.

We need the perspectives, skills and lived experiences of People of Color, of disabled folks, of non-cis genders, of older adults, of junior devs with backgrounds different than the typical tech-bro.

But to include them and use this opportunity, it will not help to buy a ping-pong table or setup an X-Box room. We have to make them feel welcomed, appreciated, and to “be included.”

To include them, we need to stop doing harm – on all levels.

We need to stop using terms with a racialized history like master-slave in our code; we need to stop using terms like “RTFM”; we need to deal with our internalized biases; we need to listen to the lived experience of marginalized folks – and treat those experiences as the quality data they are.

If we want to really improve our companies, our teams, our products and services, and even our code, we need to prioritize the most vulnerable – because only if we do so, everyone will be safe and able to contribute.

The knowledge and lived experience of these most vulnerable folks will then allow us to grow and create the products and services that help us create the world we want.