Blind

It has been a while since I’ve worked on in-person conferences, but with events starting back up, conference planning has started up again as well. I recently chatted with someone about improving diversity in speaker lineups. This is a very difficult topic with no easy answers, but it is one that I love talking about. I’m serious. I want you all to know that if any of you are interested in improving the diversity of your speaker lineup, I’m happy to talk through your process and offer suggestions.

Back to the topic at hand, though, the issue this conference was having was that the speaker selection committee thought they had solved any bias issues by starting to make blind talk selection, and they didn’t understand why it wasn’t working. They were still ending up with the same old non-diverse lineup.

Blind talk selection is when you do not display the speaker’s name, employer, location, etc., while reviewing the talk titles and abstracts for talk selection. The purpose of doing so is to remove any identifying information so the talks can be evaluated solely on the merit of the talk itself. Blind selection is relatively easy to implement and has been a popular solution for addressing complaints of biased talk selection at an event. If you don’t know who the speaker is, how can you be biased against them? The answer no one likes to hear from me is, “So very many ways.”

There are so many flaws with a blind talk selection process, not the least of which is how many speakers put their own names or identifying information right in their abstracts. Even if you try to strip out speaker names, there’s no way to remove all references without having someone manually go through every abstract individually to ensure there are no recognizable references. A speaker’s name of “Elizabeth” on the submission form may be listed as “Beth” in the abstract, or you may end up with references like, “As the author of the Finally column for php[architect] magazine…” These kinds of references let anyone who is familiar with me know exactly who wrote the abstract, but it is very difficult to strip out programmatically.

Even if you have well-behaved speakers who are perfect at writing abstracts with no personally identifying information in them, selection committee members can recognize the tone, catch-phrases, or even the topics that certain speakers use. Many speakers reuse talks from other conferences, so the title of the talk may give away the speaker. Beyond identifying a certain speaker, abstracts can be used to identify a type of speaker, which can introduce bias. Consider these sentences:

  1. Pulling from more than ten years of professional experience writing high-level code for a wide variety of clients, I will teach you the best strategies to use to estimate the time it will take to complete a project and ensure that your projects do not go into the red.
  2. I’ve been a consultant for over ten years, and I have found a fool-proof way to estimate how long it will take to finish a project so you won’t be losing money while working.
  3. After 10 years of work, I’ve seen some messed-up projects, but I know exactly how long each job will take so I always get paid right.

These three sentences all describe exactly the same thing, but they are doing so in very different voices. There can be a lot of bias in manners of speaking, tone, and voice without knowing anything about who the speaker is. Blind talk selection just does not work. So as your local user group, trainings, and conferences start back up, make sure you are focused on bringing your biases to light. Everyone has them. It doesn’t do any good to refuse to see them. Engage in tough discussions, dig deep into how you are evaluating things, and constantly ask yourself why you think that way. Embrace diversity, not blindness.

Originally published in “Database Freedom”, the July 2022 issue of php[architect] magazine.