What's in a name?

Women face a number of barriers in science-based endeavors, perhaps more so than in other fields1. This matter is not really even open for debate. What is up for debate is whether or not it's justified and whether or not we will actually do anything about it.

Much debate surrounds the causes of the gender disparity evident in many fields. Some argue that girls and women do not pursue STEM2 educational programs and therefore either show a lack of interest in the topics or aren't generally qualified to pursue the programs. This is, almost certainly in part, due to traditional gender roles, but it cannot be limited to that as the limitations based on traditional gender roles have decreased as time has passed and societal norms have adjusted.

Another portion of the lack of pursuit of STEM programs by women is almost certainly self-inflicted doubts. This can be seen in a (1946) conversation between Einstein (yes, that Einstein), and a South African girl named Tyfanny. In corresponding with her, after she revealed her gender, Einstein said,

I do not mind that you are a girl, but the main thing is that you yourself do not mind. There is no reason for it.3

Einstein recognized, in Tyfanny's words, the self-doubt resulting from generations repeating the societal refrain "you're a girl".

These problems are significant, and we must fight tenaciously to overcome them; however, these facts alone are not enough. These are facts of history - facts that society has dealt with for years and yet, one might argue that while female representation is much lower in STEM-related fields, it is significantly imbalanced in many fields4. Why is this? Why are we not convinced that especially science, technology, engineering, and mathematics are about ideas and not something as trivial as gender? Are we really so blinded to not be convinced that women can think as well as men?

I refuse to believe that it is something in our conscious behavior, and I posit that our bias goes much deeper than we originally thought. Even though we have convinced ourselves that even if the larger populace does not subscribe to a meritocracy those of us in STEM-related fields are well into a meritocracy, we have deceived ourselves.

In what should have been a mind-blowing study written more than a decade ago, Rhea E. Steinpreis, Katie A. Anders, and Dawn Ritzke revealed that both men and women demonstrated gender bias in hiring recommendations.5 The subjects for this particular study were all PhD-level psychologists - people who should recognize that science is about ideas and not gender, people who should recognize trivial and non-trivial information for what it is. In a similar study, written just last year, it was demonstrated that even among science faculty at research-intensive universities, gender biases favor male students.6

What these two studies illuminate is that our gender bias is so thoroughly ingrained that even individuals who are trained to deal directly with data, identifying what is trivial and non-trivial on a daily basis, are incapable of suppressing something as trivial and unreliable as name-based gender bias. Before anyone starts with the 'academia vs. real-world' arguments, a cursory search regarding this topic yields some very interesting anecdotal evidence that supports the same hypothesis.7

We are, like the characters in Shakespeare's Romeo and Juliet, using names as a priori judgments. These two studies also speak volumes about our decision quality, our hiring and staffing policies, our integrity and values, our knowledge about our ability to evaluate people and ourselves, and even our ability to manage diversity.

When otherwise qualified candidates are eliminated from the process based upon their name it's easy to see where a significant portion of the disparity originates. We can work to correct gender stereotypes and eliminate gender roles from early education, we can do a number of things to encourage girls to enjoy and pursue STEM education and programs, we can even build gender-based groups that encourage and promote not just gender balance, but women in the work-force on university and work campuses across the country. None of our efforts to increase education, ban words, or anything of the sort will mean anything until we address eliminating the gender bias that is demonstrated to occur at the first step in any selection process.

Of course, one of the worst parts of this situation is that even though this has been a known issue for more than a decade, we've done nothing to change the situation even though it is incredibly easy. How easy? Here are four simple policies that every organization could adopt with little to no impact to their schedules or bureaucracy, which would alter the landscape significantly:

1. Publicize the existence of gender biases in relation to CV's and resumes and what is being done to compensate for it or correct it.
2. Replace names with unique codes on all CV's and/or resumes that are submitted prior to their being screened.
3. Restrict access to names and codes during the selection process
4. Identify discussion of a candidate's name as especially problematic and a punishable offense

As a bonus, when these policies are introduced, other name-based biases will be reduced or eliminated as well - the most notable are race, nationality, and religion, because when Juliet, in Romeo and Juliet, asks...

What's in a name? That which we call a rose by any other name would smell as sweet.

Romeo and Juliet, Act II, Scene II

...as it turns out, there's more than enough information, and if you don't believe me, just ask Romeo.

Notes and references. Links in the notes and references list open in a new window

1. You can find the research regarding the types of barriers women in science face, published by AAUW in "Why So Few? Women in Science, Technology, Engineering, and Mathematics", at http://www.aauw.org/research/why-so-few/
2. Science, Technology, Engineering, and Mathematics
3. This tidbit is revealed in "Dear Professor Einstein: Albert Einstein’s Letters to and from Children" by Alice Calaprice, along with views on gender's relationship to the study of science that were far ahead of his time - i.e. it doesn't matter.
4. One recent edition of philosophers' sound-bites (Philosophy Bites, by David Edmonds & Nigel Warburton) references 44 males and 8 females - a paltry 15%.
5. The study is called "The Impact of Gender on the Review of the Curricula Vitae of Job Applicants and Tenure Candidates: A National Empirical Study" and you can easily find it online and read it in its entirety - which I recommend.
6. The study is called "Science faculty’s subtle gender biases favor male students", by Corinne A. Moss-Racusin, John F. Dovidio, Victoria L. Brescoll, Mark J. Graham, and Jo Handelsmana. You can read it at http://www.pnas.org/content/109/41/16474.full.pdf+html.
7. In the blog post "I understood gender discrimination once I added 'Mr.' to my resume and landed a job", an individual seeking employment in a non-STEM-related field relates how self-identifying as a male on his CV made a positive change in the response rate to his inquiries.

One last note: If you follow this blog, you might have noticed that I've been missing of late. To offer explanation (not justification or apology) I will say that sometimes personal lives get very busy, we have a temporary shortage of creativity (e.g. writer's block), and we need time to work up the courage to say what we need to say how we need to say it rather than just exclaim "WTF!" and be done with it. For me, it's been a mixture of all of these as I've seen my oldest niece married, contemplated my daughter's education, and ruminated regarding how to address gender disparity in hiring for quite some time, even discussing the policies that will correct this with women in technology companies before writing this post.

Fear is the birth of cruelty and the death of reason, wisdom, and finally, action. (Robert's Rule #26)

Fear, as our 'leaders' have discovered, is a powerful motivator. For most people, one of the most powerful fears is of losing their job, in fact, for some people, the fear of the loss of their livelihood is even stronger than their fear of death, because it means something very significant to those who depend on them. Because of the power of this fear, employers the world over become some of the most powerful entities known. However, this fear comes at a price, for fear is the birth of cruelty.

When you, as a manager, threaten someone's job and engage this powerful motivator, your 'direct report' will likely tow-the-line. They will likely become quite complacent. They will also likely quit innovating, start protecting their assets to the detriment of the team, and start looking for a place of employment where they believe they will be respected, which means their productivity will generally plummet and they will become a drain on morale. In short, what you will have created is a negative reinforcement cycle that will likely spiral out of control.

On the other side of fear, however, the lack of fear is an equally strong motivator. The lack of fear can be the result of either having nothing more to lose or a true feeling of safety.

The lack of fear that is the result of having nothing to lose - that finds its origination in desperation - is dangerous in the extreme, as The Art of War notes. It is the recognition of this fact that has led companies to treat terminated employees as criminals as they are escorted from the building, often without even being given access to their personal effects. The creation of this type of 'enemy' is a mistake of the highest order and you should always try to maintain the appearance that even those discharged have something more to lose. Helping them move on to another position (if that is at all possible) is a good start. After all, just because they don't fit in with your organization that does not mean they would not fit in quite well somewhere else. If you can honestly, objectively review their contribution you will (nearly always) find some benefit they provided to the organization that you can leverage as they look for another position.

On the other end of the lack of fear spectrum - when a person feels safe in their job - people are more likely to take risks, stretching and growing. They are also likely to innovate, be more relaxed and positively affect team morale, in essence become a powerfully positive asset. It is the creation of these positive reinforcement cycles that we need to create. One of the most powerful effects of these positive reinforcement cycles is the energy they contribute to the team, as study after study has shown that 'winning' begets 'winning' and nothing so strongly counters winning than fear and trembling, because fear is also the death of reason, wisdom, and eventually, action.

If people aren’t getting a point, use smaller words or a louder voice - it’s patronizing but they won’t get that either (Robert's Rule #23)

Engineers are generally thinkers. There are those times, however, when we are certain we've thought a problem through and really don't want to be annoyed with the facts. In times like these, meetings where there are more than one point of view - meaning my (right) point of view and the (wrong) point of view everyone else has - can be difficult

In those meetings it's important that a few things occur in order for you to be successful. First, if people aren’t getting your point, you should use smaller words or a louder voice - it’s patronizing but they won’t get that either. Second, you must keep your composure. If you lose your composure, nothing else will matter, because most will dismiss you as emotional (as opposed to rational). Third, you must monitor the quality of any decisions you make in a heightened state of agitation.

Remember, you're facing a serious threat in these heated meetings, these are serious dangers. A misstep in this area is one of the most effective means of destroying any image you may have as a politically savvy team-player as well as a thought-leader.

I know it seems obvious, and you probably wouldn't believe the stories of meetings I've been in that have descended into shouting matches, or worse, into cold, dismissive, condescending, passive-aggressive olympic-quality events.We, as a member of a team, can only be our best when we not only are contributing but also recognizing how all of our teammates look up to us.

Ok, enough channeling Machiavelli's Prince.

There will be times when you are the big fish in a little pond and your teammates will look up to you as the expert. There will be many more times you will be the medium (or more likely, small) fish in a large pond and doing anything other than keeping your composure and working together to resolve the conflict will get you derisively labeled a 'big fish'. So, keep the rule if people aren’t getting a point, use smaller words or a louder voice - it’s patronizing but they won’t get that either (Robert's Rule #23) in mind as well as keeping in mind that the rule that is really an anti-pattern, unless you really want to be a 'big fish'.

Too often 'we can' erroneously becomes 'we should' and 'we will' (Robert's Rule #17)

[Tweeted 2011-06-03]

Once upon a time I was in a meeting in which we discussed a web application that was scheduled for deployment in the immediate future. As we were working out the implementation details, we came upon the issue of needing to access private, restricted, highly confidential information.An additional wrinkle was the need for the database to be maintained by the system of record, which was on the internal network.

As we were discussing the options, one person (I'll call him n00b) suggested that we could easily solve the problem by joining the server to the DMZ and the internal network simultaneously. My response was an immediate "no, we can't do that". "Oh yes we can", the n00b replied. "All we need to do is install two network cards and use one for the DMZ and one for the internal network." In honesty, I was not the first one to laugh out loud, my manager was.

The n00b was insulted and said that he had used this approach for one of his clients (outside of work) and so I ended up telling him that what such a plan would do is create a bridge between the DMZ and our internal network, making not only the database server vulnerable, but the internal network as well. The n00b had a few more, equally appalling suggestions, but in the end the group, collectively, brought him to a measure of enlightenment.

Of course we had the technical ability to do what n00b suggested, just like I've had the technical ability to do hundreds of other blatantly stupid things and several more that weren't quite blatantly stupid (even if they were of equally questionable value).

Perhaps more disturbing than a n00b fighting for a bad idea is that if the n00b had been higher up on the food chain, rather than the n00b he was, the situation might have turned out differently. I've certainly been in situations where I've known what was asked was a bad idea and would even likely turn to bite me in the nether regions, and still I've had to implement the bad idea because 'the decider' made the decision.

We all face such situations; in fact, they're far from uncommon. This is why Rule #17 states that too often 'we can' erroneously becomes 'we should' and 'we will'. Robert's Rule #17 is simply a recognition of a sometimes disturbing truth we, as technologists and engineers, live with every day.

Past performance does not guarantee future value (Robert's Rule #4)

[Tweeted 2011-04-28]

A while ago I was in a job managing a team of software engineers. This team was a mix of people; both in terms of experience and in terms of relationship to the company (i.e. some were full-time employees and some were contractors).

Now, I tend to consider myself more detail-oriented and data driven than the average person, so it made perfect sense to me to relate software features to be developed, and all the project management related data (estimates, dependencies, etc) to my assessment of a developer's skill level and also relate the defects found to the features. In hindsight it was, perhaps, a tad more complicated than it should have been. On the positive side, it gave me quick insight into how effective my assessments were and how likely we (as a team) were to hit our projected development milestones.

One of the problems I faced was when developers took up a different task or a different language. Software development, as a discipline, is fairly straightforward. There are language skills (computer languages are made up of nouns and verbs and have direct and indirect objects just like other languages) and general concepts (like data normalization rules and network/communication protocols) that apply to all feature development, so a good developer is a good developer, right? Usually.

Usually good developers get better, but practice doesn't make perfect and a developer that handles one language with ease may not be able to make the switch to another language. Such was the case when one of the developers on my team attempted the switch from COBOL to an object-oriented language. When he popped the clutch on his paradigm shift (yeah, I started that saying back in '93) his development shuddered like an old car. In a car, if you pop the clutch, you can stomp on the accelerator and rocket off or you could try to coax it along and kill it...I believe that in theory it works the same with people.

This experience led me to conclude that "past performance does not guarantee future value" is just as true for people as for the stock market (Robert's Rule #4). This developer chose to try to coax his development along rather than immersing himself in the new technology. I don't know where his career has taken him in the years since, but it's most likely out of software engineering.