The #causeascene Guiding Principles to Do Less Harm in Tech

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 crippled 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 in tech teams – why is this even problematic?

Lack of Diversity 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.

Commentary Competition

Enjoyed the topic? Have a relevant anecdote? Disagree with the author? Leave your two cents on this post in the comments below, and our favourite response will win a $50 Amazon gift card. The competition closes two weeks from the date of publication, and the winner will be announced in the next Simple Talk newsletter.

The post The #causeascene Guiding Principles to Do Less Harm in Tech appeared first on Simple Talk.

from Simple Talk https://ift.tt/38EMMB0
via