PS：此文為個人認知，不足處請多多批評。
近期在一線leader（經理）身上發現了幾個case，然後又回想起前幾年自己做的一些傻事，可能都屬於明面上leader不會說什麼，但私下會有情緒的型別：
Case 1：下游背鍋——聲量小的成本。
有一次作為技術負責人跟一個產品線leader（某一條產品線負責人，非總產品負責人）去開會，討論我們是否需要採購一套系統。
首先，系統各種資訊，對面公司都不願意透露太多細節引數，所以很難做判斷，然後對方明確表明不會提供原始碼，只願意開放API對接，而我們自己業務方甚至有些二五仔的一直催著趕緊上系統。
作為老司機，我當然微微一笑，類似這種不明不白的系統採購進來絕對是坑自己的技術兄弟，但是技術層面一般來說沒太多決策權，只有風險預警和方案選擇建議，於是便push產品leader正面回絕。
誰知這個產品犢子（產品果然是技術永遠的敵人），說了幾句“不合理”、“不合適”、“有衝突”、“我們有這個功能了”，之後便全程被業務方蓋住了聲音，於是產品埠的控制權便旁落給業務方或者產品埠開始事實上的缺位了。
我見勢不妙，急忙說了幾個實施難點，以及準備了一個清單，讓第三方準備，不愉快的結束了會議，不做任何承諾，先擱置。
事後質問產品leader為什麼不硬剛，你知道接進來成本多高的時候，那狗犢子來了一句，我已經說了啊，他們不聽，我有什麼辦法，我懶得跟他們爭......
這傻犢子，不知道他的所謂不爭會導致技術團隊好大的坑......
Case 2：事不關己高高掛起。
某條線的業務方（非上述業務方），之前著急忙慌的跑模型，非要去外面採購一套系統自己運營。
一段時間後，找著我們CTO（我的leader）哭鬧，說是外面系統太不穩定，效能也差，資料稍微上量後便各種卡，外包團隊的意思大概是伺服器有問題，他們沒法解決。業務方現在希望部署回來，並且以後由我們維護迭代......
這個業務線並不是我們核心業務領域，屬於可接可不接型別，考慮當前資源情況，和後續的坑點，當然是儘量不接呢。剛好，這個事情又落到了上面那個產品leader手上，這癟犢子可能認為坑主要是技術團隊的，又是CTO傾向接住的業務，便又開始事不關己高高掛起了。
於是，得罪人的事情又落到了區區在下身上，這裡是直接闡述了該專案有哪些風險，以及我們當前的資源瓶頸，最終只答應幫忙部署到我們自己伺服器，但是維護以及迭代不會參與，由於態度有些強硬，我私下瞟了下CTO臉色貌似不太好......
最後，此事也確實慢慢無疾而終，沒產生什麼影響。
Case 3：無來由的鍋——好人我做，背鍋leader來。
這個Case來源於此文原型：【周覆盤】覆盤機制如何在新團隊落地？
這裡其實還有一段聊天記錄，大概是這樣的：第一次產品同學做CaseStudy，有點擔心是批鬥會，不太想參加，於是質效leader將這個鍋算是完全的拋給了其leader。
很簡短的對話中，其leader（區區在下）被連續當擋箭牌工具人用了兩次，而且類似這種案例在很多場景下發生......
Case 4：跟著躺平——一個團隊不能有兩個思考的人。
我這邊接手了一塊產品業務線，於是與原來該產品線leader說了下分工，大概意思就是我是過來學習的，也能給團隊提供更多的資源（技術資源也是資源啊！），初期我會有一些規劃，團隊內的工作你自己繼續管理，之前的規劃也繼續做，不要等我，於是在愉快（真的愉快）的相處下，進入到本週週會。
週會上，我發現一旦是該團隊有疏漏的地方，這位產品leader，自然而然、驕傲的說道，這塊XX哥會做規劃，這塊XX哥下來會組織，這塊我下來跟XX哥聊聊，聽聽他的意見，這塊XX哥說不需要提供......尼瑪，我馬上又成為背鍋俠了！
PS：這裡要注意，這個產品同學絕對不是因為不滿意我的存在而這樣說的！
總結下來，出現這種情況的主要原因是：
團隊中如果出現一個新leader（可能最強的人）後，那麼其餘人甚至是之前的leader，更傾向於停止思考，事事請示，躺平等待帶飛...
以上Case，如果對應權責利模型，其結果貌似又是很合理的，但都有點奇怪的是，這類同學在晉升，或重大機會來臨時往往不會被作為首選，甚至可能會被認為沒有擔當，責任心、有擔當對於往後的路，都是重要的特質，因為會遇到更多可做可不做的三不管情況，如果再進一步的時候，這種鍋該怎麼甩呢？
PS：這裡是說通用情況，不是針對上述同學！！！
其實上述同學能做到leader還是很聰明的，一定是其“本質”工作做的沒什麼問題了，專業知識不會有太大問題，但是有些“聰明”在很多模糊地帶，三不管地帶，甚至明確非自身領域的偏衝突地帶就會被著色，什麼“老好人”、“不得罪人”、“和稀泥”之類的法寶慢慢就出來了。
“事情到我為止”、“事事有回應，件件有迴響”也未必是完全正確的事情，我們要不要做一件事情，有一個標準；我們要把一件事情做到什麼程度，也要有自己的判斷。
有些事情，多做一點深陷泥潭；少做一點又滿盤皆輸，這個度便是各位leader要修行、要掌握的要點，這可能就是所謂管理的火候吧，需要知行合一，多加修煉！
下面提供一個日常案例結束此文，僅僅是拋磚引玉。
一個多方影響的Case
最近出了一個case：
在我們的業務中有【自營店】以及【合作店】兩種使用者觸點，自營店各方面成本最優、體驗最好，但不能保證總是有足夠的存貨，所以有時候依舊需要從合作店拿一些貨，這裡涉及到拆單，會產生額外的物流成本，使用者多次收穫體驗也不是太好。
對應銷售部門本身有成本壓力，不希望有這種成本浪費，於是反饋到產研這邊來了，處理的產品同學大概是這樣回答的（PS：這裡不方便透露業務詳情，只列概要）：
1）描述情況；（這點沒問題）
2）描述銷售部門期望情況；（作為簡報，這點也沒問題）
3）產出結果；（這裡問題就來了）
這個同學（我那條產品線的...）直接求助到產品負責人了，也沒提什麼具體的方案，就把作業全部交給leader了，我這裡當然是先噴啊（不能等別人罵）：
於是，下來找到該同學落實了下處理節奏：
1）詳細描述該問題出現的原因；
2）提供自營店、合作店近2個月的資料情況，合作店銷量的佔比；
3）綜合【成本】【毛利】【使用者體驗】【收入規模】等因素做出一個基礎的決策模型；
4）給出臨時短期方案建議；
5）給出長期方案規劃；
6）與供應鏈側達成共識，與銷售埠達成基本一致；
7）發出郵件，開始實施......；
這裡有幾個點要注意：
1）具體到產品線的某個領域，你的leader比你更專業的概率很低，你要提供相關的建議，以及支撐建議的相關論據，能資料化、多維度資料化最佳；
2）思考解決方案的時候，至少要思考多一步，比如上訴問題，首先是銷售策略問題，其次是產研設計問題，而最終可能是整個公司的供應鏈服務能力，要切實解決這一切，要從基礎的供應鏈側全鏈路優化；
無論從專業度還是“擔當”這個點來說，儘量不要讓leader決策，儘量不要拿leader當工具人（傻逼或者救世主），除非自己確實拿不準；
碰到具體事項時，儘量別讓leader幫你思考，也儘量別讓leader幫你背鍋，如果可以的話，請儘量別讓下游團隊幫你背鍋，提供你的專業意見，提供你的【決策模型】，提供你對當前事項決策所用的論據，最後跟相關方儘量做到資訊同步，再請leader拍板即可，這裡所謂的擔當更多的是對你自己，未必是對你leader。