3 Ways to Celebrate Diversity in Engineering Teams
And why diverse engineering teams build better products
“What the hell does your gender expression or skin color have to do with how well you engineer software!?!”
On the surface, nothing. But, our experiences shape how we think about and navigate problems. Minorities engage life-issues, just like everyone, but context often forces them to venture forward with less traditional approaches. Black lives matter. Gender-neutral restrooms. Gay marriage. Women’s suffrage. Or even navigating immigration bureaucracy. Whatever our life experiences may bring, they become lenses through which we see the world.
So, who are you?
What a stupid question, as if there is only one answer. Do you mean where I’m from? Do you mean, what is the color of my skin? Do you mean who I love? Do you mean, what I’ve done? Or, what I fear? Do you mean, what I’ve lost?
Sometimes people refer to this stuff as “baggage.” I hate this terrible word. It brings a strong negative connotation that your more challenging experiences have stained you. A once pretty face dotted with scare tissue. Folks who fear differences may see their own diverse set of experiences as a liability to the group rather than the group’s advantage. This attitude is a foundation of self-prejudice, which leads to self-censorship. Sadly, we can be our own worst enemies. But if we project this garbage onto others, we precipitate bigotry.
We must dispel the “baggage is a liability” attitude to realize our true potential as engineers.
We must present our full, unfiltered self to others. And we must celebrate the occasions when others do the same with us.
Software is an organism: a Team’s Diversity and Authenticity safeguards its resiliency.
Software is not an organism in the traditional sense, but it has very similar evolutionary feedback loops. Feedback loops come in from the market, and select which features (mutations) are viable and not. When the market shifts, whether or not your product (or company) survives depends entirely on your team.
The first and hardest step is to see the shift. Something’s not working. Users meander around the product, disconnectedly. Customers ask questions that suggest “they don’t get it” or “don’t make sense.” Growth slows to a trickle, or, never actually picks up. Maybe regulations change, opening or closing entire markets. Entire books focus on “Product-Market Fit,” but all it comes down to is observing the real world.
Don’t be fooled; seeing the real world is incredibly difficult.
But we must stop. Breathe. Pull our heads up out of the code for 2 minutes, and look. Look at your customer. Look at your fellow engineers. Look at the competition. And ask yourself, is this the right way to build this?
Something amazing happens. Even when everyone looks at the same thing, everyone sees something different. We all have had this happen. And then someone blurts out the half-trolling half-serious question,
“Is this a bug, or a feature?”
The more diverse a teams’ collective experiences, the more varied our insights become. Overlap becomes reassuring. Contradictions become warnings. Together, the possibilities are flushed out (and their consequences to product-market fit).
Once all the perspectives are on the table, you get to pick one. Of course, it’s not a democracy. It’s not “design by committee.” It’s not a jury, no one is on trial for murder, and no, it does not need to be unanimous. It’s just software, relax. But ultimately, engineers must decide. Those deciding are the owners and own all of the consequences that the decision yields.
But wait, isn’t that a Product Manager’s job? Yes. But this process happens repeatedly, and at various levels, always, and continuously. Even something as simple as uint_64 vs. uint_32 may have drastic consequences on end-user experience, despite its seemingly inconsequential differences.
A PM is not always going to be around to nudge decisions down one path or another.
It is our responsibility as engineers to understand the spirit of the product’s definition and the needs of the market, customers, partners, and other stakeholders. Besides, engineers must understand the product better than anyone else — even better than the PM. After all, they have to build it.
(3) Celebrate vulnerable moments with empathy and appreciation.
Mistakes. We’re talking about mistakes. When people are comfortable enough in their skin to make mistakes in a public venue, such as a PR, we can reinforce team cohesion by approaching with a sense of humility and clam. Demonstrating empathy and appreciation in a public setting, by asking specific questions to better understand intent and context, instead of just assuming they’re wrong and you’re right.
No one has an anointed mission from the god of programming to inform all fellow engineers when they’re incorrect or suboptimal. Instead, we all have a responsibility to at least try to understand each other. This is important because,
you might be the one wrong
So, relax, and present specific and humble questions that help flush out the values + perspective that drive the “wrong” decision. Even if you disagree with the decision, respect the final decision, and thank the owners for taking ownership of the decision and the consequences.
(2) Celebrate the best question anyone can ask,
“I am so sorry, what are we talking about?” is perhaps the single best question anyone can ask. If one person asks, the odds are the entire group is not following. As a speaker, it indicates that your words are not connecting to the real world. You mine as well be talking to an empty room.
Asking this question not only needs to be respected but celebrated. It’s a call to stop talking, step back, and look at the bigger picture. Find common ground.
And start talking about the real world, not just what’s in your head.
The more heterogeneous your team is, the more often this will happen. But if it never happens, that should also be a red flag. If a team is so homogenous, that everyone’s perspective overlap, then you’ll surely be missing essential nuances and the product will be far less resilient to the test of time.
(1) Celebrate the gift of a disagreement.
One way to turn disagreements into a celebration of diversity is to give both parties two underlying assumptions: (a) that people are smart and that (b) people want to do the right thing.
Then, disagreement is an opportunity for someone to either (a) learn something new about the world or (b) see the world from another perspective or set of values.
The other side gets to (a) teach someone something new about how the world works, or, (b) gets to share their perspective that makes the tension melt away.
No matter what comes of the disagreement, everyone is better off. And the product is not the only thing that reaps the benefits of the conflict. When resolved with a sense of humility and respect, the team itself becomes more robust than the sum of its parts.
