I’ve now read James Damore’s document about diversity at Google multiple times. James Damore is the 28-year old Google developer who wrote a long treatise in which he claimed that Google was an echo chamber of liberal ideas and that hiring women who aren’t good enough at coding, hurts Google’s mission. He was subsequently fired. I’ve been pondering what I have to say.

Many have written to clarify issues and express deep and real feelings:

• The Economist did a great job balancing the social science research and counterarguing Damore fpoint-by-point with references to other good articles. As it noted, it is well established that people are shaped by their genetics and environment. Genetics-only arguments are over.
• Yonatan Zunger, a former Googler, wrote eloquently about the collaborative nature of engineering and product development. No single great brain is enough in technology and product innovation.
• Susan Wojcicki and Donna Harris expressed the pain and anger that women and underrepresented people feel when told they are biologically deficient, not good enough, harassed, or dismissed in conversations. Words and nonverbals are hurtful. Professional behavior standards are a must for us to be a healthy thriving industry.
• Women have bewailed that there aren’t enough good women to pick from. That tells us to look at our educational practices — not to decide that women aren’t good enough. So bravo to CMU and others for near 50% gender balance in undergraduate CS classes. But this alone won’t “fix” things.
• Finally, it’s time to stop asking if diversity really matters — this ship has sailed. There is ample evidence that more diverse teams are more creative, make more money, and that companies headed by women CEOs thrive financially.

So, I don’t have to say these things. Instead, let’s face some real facts and challenges. Women in tech leave the field 50% more often than men. Making products is inherently collaborative. Products are developed worldwide, teams are geographically diverse and often working remotely, and yes, some women are now on teams and in management. Figuring out how to help diverse people work well together is simply a requirement for tech companies and product teams.

Change is here to stay. As more women, minorities, and underrepresented populations join the workplace, white men and all-male teams will experience significant change. Finally, companies must face that current diversity programs and parenting benefits are simply not enough to ensure that women and diverse workers stay and thrive.

Let’s take a step back and ask different questions.

What happened to James Damore?

What really happened with James Damore? Ignoring his political undertone and his reaction to being fired, I hear a young man who says he feels shamed, who doesn’t get to go to special career programs to help him like women do, and who experienced the diversity programs and unconscious bias training in Google as a scolding. Somehow, he ended up feeling like he is the bad guy — as many other white men have also told me they experience. (And they don’t know what to do to be good guys.)

We can also ask: Are Damore’s experiences a reaction to specific workshops at Google? Or has Damore worked with very specific women with whom he couldn’t work well? If so, how was this handled within his team or by his manager? Perhaps he loves his tech guy team and doesn’t want to lose it. Maybe he fears the change that diversity will bring. Whatever was going on with this young man, clearly no one picked up that something was wrong — that’s for Google management to reflect on.

Why don’t we know what to do to help people work together? What else can we do instead of offering workshops, networking, and the other current approaches that seem ineffective?

Facts and science cloak fear

In his writing, Damore cloaks his feelings in facts and words using a neutral tone of voice. Any of us who were there to introduce user-centered design will recognize this response to change. For 30 years I have worked and partnered with male engineers. I learned that engineers are a specific breed — they don’t do “feelings”. When engineers feel threatened by change, devalued, uncertain of their work or scared, they retreat into facts and logic. They try to drown you with science.

This happened early on when I was introducing Contextual Inquiry. Engineering men pushed back on the idea of going into the field to talk with real people. They objected with reasons:

• “Not enough time” really meant, as one engineer said to me, “I don’t want to find out my work isn’t good enough.”
• Resistance to going out into the field on a visit buried discomfort talking to people and knowing how to dress when meeting with customers. So we taught them.
• “No random sample — not a big enough sample” was resistance. I’d ask, “How many customers do you talk to now to be sure you are building the right product?” “None,” they said and hung their head.
• “How do you know that person isn’t one in a million?” came from fear of doing something different and maybe get it wrong. I’d say, “What are the odds that this person is that one in a million user?” They’d grin sheepishly.
• And the best, “What are the statistics proving Contextual Design really works?” (No one ever measures their process so this is not answerable.) This request comes from pure fear of change. I’d say, “How many weeks do you argue about the requirements? Are you still ripping code and arguing about what to build two weeks before ship because you can’t agree?” They laughed and started listening.

I never addressed their statistics or objections directly. Instead I talked into their experience, teasing them out of their fear. That’s how we got team after team to try something new. We were changing their practice; we were changing their world; we were introducing new roles and success criteria; we were destabilizing what they knew. Of course it was scary. (Remember men are full of feelings of self-doubt too. Being right and valued is core to their identity!)

Diverse teams are here to stay

Creating diverse teams — shifting how we work so teams work for everyone — is another big change. In today’s companies, men and women, white and non-white, older and younger, gay, straight and trans, Democrat and Republican, citizens of the US and citizens of many other countries — all need to work together to make great tech. Making this work well, as with the introduction of real customer data, means changed practices. And yes, it will shift power.

Making technology products and systems involves people working together, collaborating, talking together, presenting, helping each other, and otherwise dealing every day with each others’ differences. Every invention, every design choice, every review, every choice to share an idea or withhold it for fear of the reaction, every bit of code from the back end to the front is created by people working nose to nose every day. So it is not surprising that every dimension of the @Work Action Framework defining what women need to thrive is influenced by their everyday interactions with the people they work with — their teams or working groups. (Second to teams is their manager.)

We are Makers in a high-stress profession. We must interact, be creative, come to decisions and present our ideas to people every day. Critiquing and iterating those ideas come with the territory. At some level our ability to interact well, give and take, and be judged as part of the creative process is a job requirement. Working together successfully is far more than the quality of code or a design that an individual produces. What gets in our way — what has always gotten in our way even on all-male teams— is this interpersonal requirement.

A recipe for diversity in teams

Central to Contextual Design are techniques developed over 30 years for working with diverse product teams. As part of my focus on helping companies retain women in tech, we are highlighting these and developing new ideas to help diverse teams work together. Some of these techniques focus on putting structure into typical working design meetings. Other techniques have to do with how we form teams to use and balance soft skills and different cognitive styles often found on product teams. You can see my video for an introduction to some of the processes I briefly list here:

• Make the implicit explicit. Start every design meeting with rules of engagement so everyone knows what is about to happen, who plays what role, how decisions or choices will be made, and have a facilitator if you have more than four people. Creativity thrives in a well-run group working session.
• Make values explicit. Take a page from Agile and create a Team Manifesto that includes how you expect to work together and treat each other. This is your code of professionalism. We always start our teams by explicitly stating that we are one team, individual power is equal, everyone is skilled, and that everyone’s ideas matter.
• Structure every working meeting. A good working meeting defines the main topic of the meeting and its goals, how things are done and their order, roles people play, time expectations, and criteria of success. If you know what you are doing everyone just settles down and gets it done. Don’t assume it — say it out loud.
• Structure critiques. There is nothing harder for anyone than having their work critiqued, but that is core to all product design. List criteria of design, review and note issues, and evaluate based on design principles, customer data or requirements. Do not simply list what each person likes or dislikes if they can’t say why. This works for two-person conversations too.
• Do a Process Check weekly. List what is working and what is not based on your manifesto, rules of engagement, process, design criteria, interpersonal dynamics, and meeting deadlines. Fix what is broken, brainstorm solutions, and try it for a week. Then repeat. Become process aware.
• Make sure you have balanced teams. Form your teams based on more than job title and skill. Remember, a well-run team needs soft skills that make teams work. Be aware of temperament and cognitive style. You will always have individual difference — manage them.

And if you fall into chaos — interpersonal arguments, time-wasting discussions, hurt feelings, getting nothing done — check the list above. Are you doing it? Most of the time the answer will be no!

People think that working together is supposed to be smooth, everyone is supposed to get along, it should feel good all the time, and we should always feel valued. But any time you get people together you must manage it — at home, at schools, at work, in meetings, and in one-on-ones.

Tech is hard because makers have to work together to invent, be creative, and get things done. So let’s try a little more process, a little more conscious team management, and then a lot of the friction will dissipate. Not all — because that is being human — but a lot.

Start with the idea that everyone you are working with is a valuable contributor and add some structure, values, and process. That’s a good recipe for creating innovative diverse teams.