Learning

多元、平等、包容

這年頭的每家公司都在追求這樣的組織建構理念:多元、平等和包容(Diversity, Equity, Inclusion,簡稱DEI)。藉著發表在此領域的進展報告爭相比較看誰做得比較好(Google),在自家的徵才網站(Amazon)與職缺說明(Meta)裡不斷強調自己有多麼地在乎與保障DEI。

你目前所在的公司也提倡DEI嗎?

DEI的理念源自於美國,旨在保障少數族群的權益。這個理念透過美國的跨國公司與組織傳遞到了世界各地,但每個國家有著不同的文化與社會背景,該國的企業組織在實行上又會有些許差異。有些公司或許是真心想做到,還替自己設下了一些目標;有些公司是因為為了做到「政治正確」而被迫追隨標榜,但其實並不清楚該怎麼做;也有些公司是說一套做一套,掛羊頭賣狗肉。

Diversity, Diver City… 抱歉有點冷XDD

DEI這個理念的出發點是好的,但近年的發展則更偏向為一個政治正確的口號。我在日本的幾間(假)外商工作十幾年,每間公司對DEI的看法與作法都有些許不一樣,底下跟大家分享幾件事例。

Diversity

我在X社工作時,公司很想要提高工程部門裡的女性員工的比例,採取的推行手段甚至到了有點詭異的地步。

在資深軟體開發工程師(Senior Software Development Engineer)的世界裡女性佔的比例相當低,當時在我們團隊裡只有兩個男性的資深軟體開發工程師。上面的大頭為了鼓勵我們工程團隊裡也能有一位女性資深工程師,特地在年度人事預算外另開找財源開了一個「bonus職缺」。美其名為「diversity hire」(多元雇用),實質上只開給女性應徵,只能錄取女性,也就是,只能做不能說。

Hire and Develop the… Diverse @ Amazon川崎FC

長期以來在軟體工程界裡一直都是男多於女,而且多非常的多。追朔回我大學念資訊工程學系時,班上的男女同學比例大約是80%比上20%,後來在碩士班,以及在業界的幾個工作裡,男女程師的比例幾乎都是這個數字,尤其在資深職位上比例更是懸殊。

這個職缺開了之後陸續有幾個女性應徵者,但不是履歷的工作經驗與背景不適合,就是面試的表現不理想。我們並沒有為了想達到目標而改變我們的面試錄取標準,過了好久最後這個職缺沒有找到適合的人,也就被關掉了。

公司也會舉辦只針對女性工程師的徵才活動。例如,公司曾經舉辦過大型的女性工程師招募活動,直接在海外尋找女性工程師,並在通過首關面試後提供機票住宿,讓她們飛來日本進行數日的集中面試。另外也很常做的就是,邀請尚未畢業的女學生來公司參加講座,透過其他現職女生工程師的演講來了解工程師的職涯發展與建議,冀望能引起多一點她們的興趣,鼓勵她們進入工程師世界。


一眼望去男女比例懸殊 @ Plato Elevate 2024, San Fransisco

大家或許會覺得這樣的作法過於激烈,但有時候不這麼做的話等個一二十年也不會有顯著進展;有些國家甚至透過立法規定企業一定要雇用某個比例以上的女性工程師,此時這些企業不有點「創意」也不行了,可能降低錄取的標準,可能透過高薪挖角,只求在期限內達標。

這樣的過程或許不盡完善,或許製造了另外的不公平,或許影響了企業的運作效率。但最終他們達到了數字上的目標,建立了一個性別更平衡的職場環境,也讓在學的女學生看到了未來職場發展的希望,也間接吸引了更多女生投入科學工程領域。對某些國家來講, 想要改變男女極度不平衡的就業市場與職場,或許只有採取這樣激勵的做法才能在短期內看到一定的成果。

Equality

我在Y社工作時,負責招募一個工程師,由於我對這個職缺沒有特別要求日語能力(我也不想在工作上講日文XDD),有不少非日本國籍的人來應徵。其中有一個履歷感覺還不錯,但仔細一看應該是個俄羅斯人,當時心中閃過一個念頭,因為我的團隊裡剛好有一個烏克蘭人的工程師,姑且稱他為S。

心頭一驚,我看到北斗七星旁的死兆星了嗎?!

當時俄羅斯已經入侵烏克蘭,我內心不禁猜想,來自這兩個國家的工程師能好好和平共處嗎?但我當時的想法是,公司標榜DEI,我不能因為任何個人的特質與背景(性別、種族、性向、國籍、文化、宗教、語言、年齡、健康等)而給予不同待遇。另外,大家是來工作然後領薪水的,不應該讓自己的個人情感與觀點影響到工作。每個人都不一樣,就算他是來自俄羅斯,不代表他就一定同意俄羅斯政府的做法,不應該在別人身上套用既定的印象亂貼標籤。再說S也已經是很資深的工程師,他應能了解身為專業人士該有的就業態度,一碼歸一碼。

於是在通過我的第一關面試後,我便請recruiter安排接下來的技術面試,而S也會是面試官之一。

recruiter寄出面試邀請後,S馬上在Slack上的團隊群組裡問我:「你覺得找一個俄羅斯人來我們團隊可行嗎?」我當下隱約知道S在想什麼,但我想了解他究竟在憂慮什麼,便想跟他約時間聊聊。沒想到S直接在群組裡說明了:「戰爭就是我的憂慮。」看來事情已經很明顯了,但我還是想要了解他的內心想法與期待,以及表達我的立場與期待,然後看我們該怎麼辦。

結果S似乎是放棄溝通了。先是開始請病假,然後沒有說明理由就拒絕了recruiter的面試邀請,之後在群組裡回我說:「我不知道有什麼好討論的,我已經很清楚地說明問題在哪裡了,難道你還要想辦法錄用這樣的人嗎?你想討論什麼?」在跟recruiter討論過我們的對話後,recruiter說,我應該要跟我老闆報告了,recruiter也會跟人事部門裡負責的同事報告這件事情。至於之後的發展則是更出乎意料之外,值得另寫一篇文章討論。

不想Communicate只想Fight?這不是解決事情的好方法 @ Computer History Museum

Inclusion

在Z社工作時,團隊成員的組成非常多元化,成員來自十個國家,各自有不同的工作經驗與文化背景,每次在討論事情時總是鬧哄哄的,有時候也很花時間,但這就是強調多元的目的:希望透過不同背景的人提出的多元意見,盡量讓團隊能考慮各種選項,經過一番討論與比較然後做出更佳的團隊決策(team decision)。

這時候可能會有兩種問題,一個是,某些人的廢話意見特別多,對於每件事情都要插上一句話,對於每個決策都要抱怨一下,說好聽一點是積極參與討論,說難聽一點是刷存在感。另一個問題是,某些人不喜發言,可能是個性上害羞,可能是語言的隔閡,可能是不善於他人爭論,又或許是真的沒意見。這兩種人都參加會議時,會議的主持人就需要抓到平衡點,讓話多人的人有適當程度的空間發言,另外製造機會讓話少的人發表意見。

開會(桌上的酒是……?)時,總是有幾個人話特別多,大部分人都安安靜靜地聽 @ Microsoft Japan

類似的情形也會發生在開會上,比方說一個會議裡,有從會議室裡參加的人,也有從線上參加的人。面對面的討論方式還是比起線上要來的順暢,於是很容易地在會議室裡的人就會進入熱烈討論,而忽略了線上的人。此時主持人就要巧妙地在適當的點「劫走」會議室中的談話,並提醒會議室中的大家也一起來聽聽線上的人的看法。

像在story grooming1的會議上,針對同一個story總是會有人給很大的story point,也有人會給很少的story point,比方說大家投完票後的story point點數結果是1, 2, 3, 3, 3, 3, 5。這時候scrum master便會先挑選這些給1, 2, 5點的成員們,問他們是怎麼思考的給出這樣的數字(因為這些人們可能有考慮到其他給3點的成員沒考慮到的一面)。然後也會從這些給3點的成員們裡挑一個來聽聽他們的說法。厲害的scrum master就會故意挑一個平常不太發言的人,給他們製造發言的機會。最後會再重新投票一次,如果還是沒有達成共識的話便會再討論一次,或是直接以多數意見為主決定該story的story point。

團隊聚餐時也是,需要考慮到每個人不同飲食習慣(Diet)。或許很難滿足每個人的飲食喜好,但至少在個人的飲食習慣上要能盡量配合。有人可能因為對某些食材過敏(例如對小麥過敏而無法享用麵食),有人可能是素食者,要讓每個人都能吃到自己能接受的食物。

聚餐帶大家去吃buffet(aka自助餐)就對了!

把Inclusion翻譯成「包容」有一點意義上的誤差,「包容」含有接受或是忍受(tolerate)不一樣的意見,inclusion的實務上作法是:Make sure everyone is heard,讓每個人的意見都被聽到,而聽到並不完全代表接受。當意見有衝突時就是要花足夠的時候溝通,如果最後意見還是喬不攏的話,那就是讓那個承擔最終責任的人做決定,而這個人也通常是位階最高的那個人。

結語

在理想上我們希望DEI這三項目標能夠自然達成,但現實中不主動做點事情的話是很難達成的。而這些提倡的手段又需要拿捏得恰到好處,以免產生「逆性歧視」的問題。

在處理這些問題有感到些許疑慮時,一個簡單的判斷方式就是抱持同理心(Empathy)重新思考。設身處地,站在對方的角度看,想想如果自己是對方的話會有什麼感受?如果換成別人會怎麼做?怎麼做是對整體最有利的?我想凡事沒有完美解答,但求多方面考慮,決定好了就勇往直前,畢竟很多時候是不做不知道的!

女子高生野餐中;鴿子也想分一杯羹--請你們互持同理心! @ 芦屋川

你有不同的看法嗎?歡迎來討論!


1.當代流行的專案執行方式,是將專案裡每件需要執行的工作項目寫成一個個的story,裡頭詳列了為何要做這個story,以及預期的結果。在執行story之前所有的團隊成員一起檢視story內容與優先度,並投票決定大略需要花多少工夫才能完成,這邊用所謂story point的一個數字來表示「所需工夫」的程度。這個檢視過程叫做story grooming,由scrum master主持這個檢討會議。

Leave a Reply

Your email address will not be published. Required fields are marked *