First, something about brains: In our brains, everything that goes in, what we see and hear and read, forms a pattern in our neural connections. Later, when we see something similar, those same neurons are activated and we recognize the situation. It is like Content Addressable Storage, except that it doesn't need an exact match; close is good enough. Storage and retrieval with pattern matching thrown in for free -- it's memory and processing at the same time!
As a consequence of this, two brains with different patterns produce different output for the same input. Patterns come from experiences, so no two brains are the same. Two people presented with the same problem will ask different questions, try different solutions, come up with different names for concepts.  Experience changes not just what we think, but how we think. The more different the experiences, the more variety in ideas.
Consider geeks like me. The typical geek grew up watching Star Wars, Star Trek, and Monty Python. We played D&D. We read books about our future in space. We were unpopular in high school, but now we have our own subculture where we fit in. Lots of us now work as programmers.
Bonus for us: at work we're all a bunch of geeks, so we have all this shared experience. This lets us communicate efficiently, because we can speak in XKCD references and Lord of the Rings analogies. But what is that costing us?
In design meetings or pair programming, we look at a problem and separately we all come up with the same idea. We say, "Yeah! We must be right, because we all agree!" But are we missing out?
The more shared experiences, the more similar patterns, the more uniform our ideas. We don't even know what might occur to someone with completely different references. Someone who loves history and gardening, or someone raised in a different religion. Likely there are a few people like that on our team, but they don't speak up much. They're in the minority, always voted down. They get quiet after a while.
This camaraderie we enjoy, this snuggly monoculture, it's costing us ideas.
More about brains. When presented with a hard question, such as "Will this candidate be a good programmer on our team?" our brain does some magic. Without consulting us, it substitutes an easier question: "Does this candidate resemble other good programmers I know?" and then also without asking us, it answers this question with easily obtained data, such as "Does he look like the other programmers I know? Does she laugh at the same jokes? drink the same beer? Does he have a beard?"
This is how our gut makes decisions. 
Some managers call this "hiring for cultural fit." Is this the culture we want?
Teams are built on shared values. It's easy to get lazy and base our shared values on the Force, "that's what she said," and good beer. This takes away from values like solid code, abstract thinking, or responsive UIs. Team members who don't fit in can pull the team's focus toward the stuff that matters.
Bruce Watson, manager of Atomic Object's office in Detroit, has seen this many times.
"Change the gender mix and behavior immediately changes to a greater focus on work, different perspectives are introduced, and side trips are more social than derogatory.Monoculture limits ideas and distracts from values that matter. Let's take the "cult" out of culture.
This effect is not exclusive to women joining all male teams. I have seen behavior change when men join an all women's group or when races, beliefs, and orientations mix."
How? Apply a design principle: separation of concerns. Separate being a geek from being a programmer.
Geek is a subculture, but programming is a profession. Right now the terms are used interchangeably in many circles. Geeks are mostly white and male, and this is fine. Programmers are mostly white and male, and this is a detriment to our industry. We're missing out on other brain patterns, and we're not optimizing for teamwork.
The problem is: programmer == geek. Nerd, to those outside our circle. Gender is a symptom, and racial uniformity is a symptom. The US is 50% male, and developers are 90% male. The US has 30% black and Hispanic people, and development has ... hardly any. Gender and race we can measure, so they are the metrics for general diversity. Count the women, count the skin colors, count the ideas your team has access to. The real goal is diversity of minds.
A child growing up as a girl, or a black person or Latino, why would they picture themselves as a programmer? They're not a geek.
I'm a woman, but I make fun of team members who don't read the right webcomics, and I wear this "geekette" shirt to present at user groups and conferences, and I make penis jokes. I'm part of the problem.
What can we do about it?
- Seek out the team members you're least comfortable with. Ask them design questions. Draw them out if necessary, because they may not be used to it.
- None of us, even those who identify as geeks, are defined by this label. Share the parts of us that don't fit the stereotype. At work, at user groups and conferences, talk about topics that are unique or important to you. Talk about books the others probably haven't read. Politics, even. Not your kids -- that's too safe. Tell the stories that changed your outlook on life. Surprise each other.
- One way to get new patterns for our team is to get new patterns in our own brains. Go do something you can't picture yourself doing. Dance, climb, speak an obscure language. Run for office. Join a band. Be the diversity we seek. Listen to a kind of music you've never liked. Go past where it feels good, and you might find where it feels wonderful.
"As a leader, I know that the more mixed the group, the easier it is to get a stronger focus on teamwork. The stronger the teamwork, the better the software, and the better the software the greater the sense of contribution among all team members." -- Bruce Watson
 For more info, look up Sparse distributed memory.
 "Different men confronting the same range of phenomena... describe and interpret them in different ways." "The particular conclusions he does arrive at are probably determined by his prior experience in other fields, by the accidents of his investigation, and by his own individual makeup.... An apparently arbitrary element, compounded of personal and historical accident, is always is always a formative ingredient of the beliefs espoused by a given scientific community at a given time." -- Thomas Kuhn, Structure of Scientific Revolutions
 Substitution heuristic and representativeness heuristic. Daniel Kahneman, Thinking Fast & Slow