I’ve been thinking about writing about equality in the technology industry for a while now, without being able to figure out something worth saying and what tone to use. Somehow broadcasting legend Larry King, being interviewed on the occasionally epiphanic and frequently interesting podcast “WTF with Marc Maron,” finally showed me the way forward.
“We only need one rule to live by,” he said, “and that’s ‘Do Unto Others.’ That covers everything else.”
Applying Do Unto Others to the issue of equality in tech, I came up with one rule, a transposition of the original that remains universal: Be Inclusive.
No (I hear someone objecting (Hey! That someone is my rhetorical straw man!)), this rule doesn’t solve the whole problem. No, it doesn’t address other behaviors or conditions that one can reasonably argue are part of the problem of inequality in technology. But objecting to any suggestion to change human behavior for the better on those grounds is both true and trivial.
Because no social change is a complete solution, and given the complexity of the domain (the whole world), it is arbitrarily complex to even define what “complete solution” means. Rather, what is empirically evident to me about the social change I have lived through is that change happens incrementally. As sentient software developers in 2013, this is a concept you are likely familiar with and perhaps have internalized enough to have stopped noticing it; we call it Agile. The insistence that a comprehensive solution to inequality in tech is the only worthwhile solution is waterfall thinking. Instead, look at it like this: Be Inclusive is on the backlog of work items we need to implement to provide equality in technology. It’s a big project, with an unknown release date, and we can have interminable planning meetings about what else needs to go on the backlog. But we also know that doesn’t stop us from pulling this item off the backlog right now and starting to work on it, because there is a clear path to implementation and it clearly provides value.
In fact, it’s simple to explain how to implement Be Inclusive: every time you are considering a decision that has a dimension of inclusivity/exclusivity, just ask yourself, “Am I being as inclusive as possible?”
Just like time spent fixing bugs in your software, you’ll need to budget ongoing effort for Be Inclusive. Exclusiveness manifests itself as many bugs affecting the correctness of our systems of interaction and collaboration. Be Inclusive is time spent fixing those bugs. And it’s helpful to frame the problem and the response this way, because doing so highlights that just like software systems, we will keep discovering social exclusivity bugs. We are at least as fallible as the software we create, so we should expect to keep finding bugs.
This is not to be feared. Bugs are fortuitous discoveries of improvements to be made. Change happens incrementally, through the efforts of all of us.