領導者的重要任務之一-創造一個安全可互信的環境

賽門．西奈克(Simon Sinek)在《在一起，更好》，以及他之最知名的TED演說為什麼優秀的領導者讓你感到安全中反覆的提到一件事，那就是：

領導者的重要任務之一，就是為團隊創造一個安全可互信的環境。

這句話其實在不同人的解讀中，會有不同的結果，而我是這麼看這件事的，所謂安全的環境，

是一個可以安心說真話的環境，不會有人因為說了真話而受到傷害；

是一個可以信任身邊的伙伴的環境，可以放心的將背後交給夥伴；

是一個可以把大多數時間花在達成目標，而不是花在政治攻防上；

是一個不會因為犯了點錯，就會被宰殺的環境。

一個緊急事件帶來的啟發

在網路公司工作，系統基本需要維持7*24小時不中斷，一旦系統發生問題，公司內的緊急處理流程就會啟動，在自動化機制健全前，最早發現問題的往往是客服部門或業務部門，因為他們總會接收到客戶第一線的客訴電話，然後他們便會將這個異常資訊發到公司內的SOS群組，群組內大多是各部門的主管，以及能處理問題的技術人員們，而我們公司也有這樣一個群組。

當年一次重大的系統當機事件，影響了上百位客戶，客服部門主管在群組內不斷的更新最新的狀況，然後業務部門，甚至公司的CXO level的主管也開始關注這件事情的處理進度，群組內一時之間沸沸揚揚，所有人都在等待處理的工程師到底搞定了沒。

此時，因問題發生已超過30分鐘，客服主管在群組內發了一則訊息：「請回報處理進度，快，現場客服接電話接到手軟了。」

此時處理的工程師可能被逼的也急了，回了一句：「可以等等嗎？我還在追問題。」

這句話一出來，登時惹火了客服主管，群組內頓時炸鍋了，不只客服主管，業務主管，GM們全部跳出來譴責這位工程師，認為他態度不對，怎可如此？

這位工程師也很有個性，他就直接不回了，其他主管見他不回應，就開始@他主管，主管出來道歉，也在公群內直接修理了這位工程師。

沒多久，問題被處理好了，該主管出來回報問題已被解決，這個事件看似就此平息了。但事後，那個工程師被懲處了，沒多久，這位工程師也離職了。

當時我剛進公司沒多久，還不是維運負責人，該區塊的業務也不熟悉，但我觀察這個處理過程，其實我是看到挺多缺陷的，或許站在各方的角度都沒有太多問題，各有各的道理，但在這過程中，其實所有人都感受不到任何安全感。

是的，所有人。

工程師的不安全感在於他正在處理問題，卻還要一邊回覆群組的訊息，稍微慢一點就要被跟逼，而其他工程師看到這種處境，很容易形成寒蟬效應，大家都不敢也不想在這個群組內回訊息；

客服部門主管的不安全感在於她一線承接所有客戶跟客服人員的壓力，她非常急迫的想要解決問題，但卻得不到理想的回覆，也沒有任何的workaround可以先排除客戶的問題，又感受不到工程師同等的急迫感，一急之下情緒自然上來；

業務部門的不安全感其實源自於擔心客戶因為這樣的問題會產生退款，也擔心市場口碑受到影響後業務開發難度會提高，或許還有一部份是源自於跟客服部門同屬於前線單位的同仇敵愾。

針對這樣的問題，請問身為領導者應該如何解決？

何時才是真正的安全？

思考這個問題，我們很容易陷入要保護看起來受傷最重的那個人-工程師，所以很直覺的認為客服主管與業務主管這些人不應該如此對待工程師，而研發主管應該跳出來保護工程師。

在這種思路下，我們終於幫工程師創造了一個安全的環境，但我要請大家記得一件事：

當所在的組織中，有一方是處於不安全狀態，另一方也不可能安全。

試想，你在一個村落中，四面都有猛獸出沒，當你只想著獨善其身，將自己的住所以圍牆鞏固起來，你確實安全了，但其他村民並不安全，平常相安無事，但若有一天一群猛獸襲擊了村子，村民們抵禦不住，紛紛翻過圍牆進到你家，又因為不敢離開，開始搶奪你的食物。

讓自己先感覺安全不是太大的問題，但要記得，這並沒有讓你真正感到安全，因為問題並未被解決。

所以，光是保護工程師，讓工程師感覺安全是不夠的，我們必須讓其他部門也感到安全才能真正解決問題。

真正的安全，是當組織內的其他人也感到安全時。

領導者的重要任務之一，就是為團隊創造一個安全可互信的環境。

記得，安全的前提是彼此可互信，我不用怕你會刻意要害我，所以我不用老是防備，我也不用擔心你會檯面上說一套，檯面下另一套。

如何讓大家都感覺安全？

經過幾次的事件觀察後，我正式接下了維運負責人的工作，前期幾乎沒有什麼人願意值班oncall，也沒什麼人會主動在SOS群組中回報進度，所以初期大多是由我來回覆，然後再私下找其他人處理，一邊跟進進度，一邊回報到群組裡。

前兩週，其實我還沒找到妥適的處理方法，但我回覆的速度算很快，對上或平行間的溝通也大致還可以，大家雖然不願意到群組內回訊息，但都挺幫忙的。

如果出問題，我會先到客服部門的現場去了解狀況，一開始大家也沒給我好臉色看，這我完全能理解，但我並沒因此迴避到現場去了解跟安撫一線客服的情緒，在現場也會跟客服的主管們聊聊，也因此大致了解了他們的壓力來源，聊著聊著，彼此之間也漸漸有了些微的信任感。

他們只是沒有安全感。

跨部門的信任感稍稍建立後，群組內的肅殺之氣似乎沒有那麼強烈了，此時，陸續有些夥伴跟我表達了一起輪班的意願，但大家還是希望不要直接在群組內回訊息，不過總算是前進了一大步，這前後花了約一個月左右的時間。

建立標準作業流程

往後的一個月，我們花了比較多時間討論在異常事件發生時的處理流程，包含什麼樣的問題找誰、誰負責接球、誰負責回覆、多少的時間內得到群組內更新進度、多少時間內要排除問題、如何確保問題不重複發生、若問題沒有被根本解決後續的跟進機制為何(減緩、自動排除或修復)…

建立這些SOP大概花了我們三四個月的時間，但愈來愈順手，我們解決問題的時間從原先的30–60分鐘，縮短到5–10分鐘，在SOS群組裡回覆問題也愈來愈精準。

漸漸的，發生問題時，大家在群組內急躁能難免，但說話的語氣討論多於追究，溝通多於責備，有些工程師也從我回話的內容中找到有效描述現況又能表達同理心的方式，所以除了我之外，有些工程師也會開始主動回覆訊息，而我若覺得某個工程師或PM能精準地回答問題，我會先跟他溝通怎麼回，然後在群組中@他來回答，這麼做的目的有二：

1. 示範給其他人看，除了我之外，其實還有其他人也能回覆而不會被修理
2. 為其他人建立credit，讓其他部門知道除了我之外還有別人也能解決問題

漸漸的，我開始退居二線，一線的問題全部都由各系統負責人承接，後來我更直接將一二線的責任全部交付給他人，而這個機制也愈跑愈順，我們較健全的維運機制就在這樣的背景中建立起來了。

在這樣的機制下，客服部門感到安全了，他們知道有人能同理他們，而且問題處理的效率也大幅提高，而那些短期無法被解決的問題，我們也會想辦法減緩，並且找出root cause限期解決；業務部門感到安全了，因為他們知道辛苦成交的訂單不會因為這樣而掉了；研發部門感到安全了，因為他們不用再被無禮對待，能就事論事溝通，工程師的需求就是這麼樸實無華且單純。

大家都感到安全，這個環境才是真的安全。

幾個給管理者的建議

第一，身為部門管理者，我們很容易把部門成員當成自己人，而把其他部門的人視為外人，所以很容易忽略其他人的感受，你們安全了，那我們呢？當你願意把「自己人」的範圍覆蓋到公司內，而非部門內或小組內，通常你對安全感會有新的定義。

第二，別流於情感面或人際面的喬事，建立制度才是解決問題的正確方法，不建立制度，卻每次都用workaround或喬事解決的主管是個不稱職的管理者。

第三，我不是要你無情，你還是該挺團隊，若你感覺這個環境的安全感不足，身為領導者你得先承擔下壓力，並做好溝通與建立制度，但永遠不要以「保護」的心態來做事。相較於保護，大家更期待你能創造一個安全的環境，讓所有人都擔負起必要的責任，承擔一定的壓力，團隊才會成長，別剝奪其他人的成長機會，你只要確保他們犯下的錯誤不會致命即可。