庆祝一下_庆祝工程团队多元化的3种方法

庆祝一下

“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.

第一步也是最艰难的一步就是看到转变。 某事不起作用。 用户不停地在产品周围徘徊。 客户提出一些问题，提示“他们不明白”或“没有意义”。 增长放缓到trick细流，或者甚至从未真正回升。 也许法规会改变，打开或关闭整个市场。 整本书着眼于“产品与市场的契合度”，但是归结为观察现实世界。

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?

但是我们必须停止。 呼吸。 从代码中抬起头2分钟，然后看一下。 看你的顾客。 看你的同事工程师。 看比赛。 并问问自己， 这是构建它的正确方法吗？

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.

但是，等等， 这不是产品经理的工作吗？ 是。 但是，此过程会反复发生，并且在各个级别上始终且连续发生。 即使uint_64与uint_32之类的简单内容也可能对最终用户的体验产生巨大的影响，尽管它们之间的差异似乎无关紧要。

A PM is not always going to be around to nudge decisions down one path or another.

PM并非总是会围绕着一条路径或另一条路径来推动决策。

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.

作为工程师，我们有责任了解产品定义的精神以及市场，客户，合作伙伴和其他利益相关者的需求。 此外，工程师必须比其他任何人都更好地了解产品，甚至比PM更好。 毕竟，他们必须建造它。

(3)以同情和欣赏来庆祝脆弱的时刻。 ((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.

错误。 我们正在谈论错误。 当人们的皮肤足够舒适以至于在公共场所(例如PR)犯错时，我们可以通过保持谦逊和lam的态度来增强团队凝聚力。 通过提出特定问题以更好地理解意图和背景，在公共场合展示同理心和赞赏，而不仅仅是假设它们是对的而且您是对的。

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)庆祝任何人都可以提出的最佳问题， ((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)庆祝分歧的礼物。 ((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.

将分歧转化为庆祝多样性的一种方法是给双方两个基本假设：(a)人们很聪明，并且(b)人们想做正确的事。

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.

然后，意见分歧为某人提供了一个机会，可以(a)学习有关世界的新知识，或者(b)从另一角度或一组价值观看待世界。

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.

另一方可以(a)向某人传授有关世界运作方式的新知识，或者(b)分享他们的观点以消除紧张气氛。

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.

无论意见分歧如何，每个人的境况都更好。 而且，产品并不是唯一从冲突中获益的东西。 当以谦卑和尊重的态度解决时，团队本身变得比其各个部分的总和更强大。

翻译自: https://medium.com/swlh/3-ways-to-celebrate-diversity-in-engineering-teams-59aee7a91d7

庆祝一下