Diversity in Silicon Valley, Series 3/5: How to Build an Engineering Culture that Celebrates Diversity?
As engineering leaders, our behaviors and values reinforce and steer culture. Whether we intend to influence others or not, it is crucial to recognize that we significantly contribute to the culture around us. As such, it’s not appropriate to complain about the attitudes we surround ourselves with — because they reflect ourselves and our attitudes, values, and opportunities. As such, it’s best to embody the culture we wish to see around us and march forward with confidence.
Which leadership behaviors exemplify an engineering culture that celebrates Diversity?
(5) Celebrate vulnerable moments with compassion 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 calm. Demonstrating empathy and appreciation in a public setting by asking specific questions to 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 + perspectives 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.
(4) Celebrate the best question anyone can ask
“I am so sorry. What are we talking about?” is perhaps the best question. 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 group is so homogenous that everyone’s perspectives overlap, you’ll surely be missing essential nuances, and the product will be far less resilient to the test of time.
(3) 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) people are smart
(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. Not to mention, your customers benefit from a better, more informed, and inclusive decision.
(2) Celebrate how we got here
No matter where we started or what challenges we faced, we got here because of the past successes that brought us to this point. Those who came before us did not place the challenges we face today to spite us. They were the constrained best efforts to launch the company into future success. Our salaries, RSU, and option packages reap the benefits of these pressure-cooker decisions that came before us.
Instead of throwing those that came before us under the bus as “still learning how to do this,” let’s redeploy the tools we learned from (3) above. The complex and imperfect technical decisions that came before us were “the right thing to do” given the context and constraints of a younger company. We get to deliver the solutions for the next 10x. But we should never forget gratitude and compassion for the past teams and constraints that came before us.
So, why is this important for Diversity? Because it’s an acknowledgment that the team that got us to today is perhaps not the team that will get us to the next 10x. It’s not that one is better than the other. Both types of teams (and decisions) are necessary. Both types will face complex challenges that we must overcome to achieve success. Instead of the message of, “ok, look, I think this is a heaping pile, but could we please buckle down and fix it,” let’s celebrate the Diversity needed to both 0 to 1 and then 1 to N a company.
(1) Celebrate the opportunity to build something better, together
“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 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 strongly implies that your more challenging experiences have stained you. A once pretty face dotted with scar tissue. Folks who fear differences may see their own diverse 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 entire, 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 safeguard its resiliency.
Software is not an organism in the traditional sense but 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 it comes down to 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 yells out the half-trolling half-serious question,
“Is this a bug or a feature?”
The more diverse a team’s collective experiences, our insights become more varied. Overlap becomes reassuring. Contradictions become warnings. Together, the possibilities are flushed out (and their consequences on 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 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 the consequences that the decision yields.
But wait, isn’t that a Product Manager’s job? Yes. But this process repeatedly happens, at various levels, constantly, 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.
If it weren’t for diverse teams given an opportunity to build new things, none of this would be possible in the first place. Celebrate our difference by embracing the challenge to build something new together.