原創不易，求分享、求一鍵三連
其實不算是投訴啦，更多是建議。
第一次離職，團隊是被解散的，組內有個老油子不停給我灌輸全部是Leader無能造成的，並且慫恿我離職的時候寫封郵件，年少輕狂，離職的時候真的寫了一封部門郵件......
工作幾年成熟後，才發現團隊解散其實是多方面因素造成的，Leader只佔一小部分，不應該對他過於苛責。
在工作場景中，有小概率離職員工會跨級給Leader發郵件暴露一些問題，我上週剛好就遇見了...
一個離職同學給老闆發了一封郵件，老闆隨後轉給我了，大概內容是：
老闆好，我是運維部XXX，主動離職，今天是我的lastday，感激這一年間，公司讓我有機會用自己的領域能力在本職工作上為公司的願景做出一點點的貢獻。在職期間感受到了很多積極行為，比如量化的OKR、年終的吐槽節目、全公司層面的微創新，產品研究結論權威釋出，甚至要求公司會議必須視訊線上等。
站在交付價值，讓事情變得更好的目的上；站在自己狹隘的認知和職位上，做出如下可能並不公正也不客觀的回應和離職反饋。
公司、團隊有太多太多好的優點和優秀的品質，但我感受到了一個缺點，團隊“領導者”的缺失，導致了IT從一個本來應該用IT能力來支撐業務的決策者，變了一個執行不到位的執行者，具體包括：
- 立場的偏離，員工目標與公司目標對立，負能量重；
- 領域能力的不足，並不能站在一個專業技術角度去理解問題；
- 管理能力的缺失，並不是端到端的考慮，人，職能，工作流，協同方式之間閉環邏輯，更多隻關注到了“做”這個具體的事情；
- 缺少投入，空頭支票，無效的承諾，或是根本就關心，事情口頭、上面上答應，但卻並沒有能力去做到；
- 缺少信任，沒人願意去表達；
- 小小的傲慢；
leader角色的缺失，可能導致了我現在的感受：這個不是一個團隊，而是“聚集在一起的人”，表示出來形式可能就是：
- 形式主義，資料不好看就關注怎麼讓資料好看；
- 公司說每人應該要去聽產品會，那我們就簽到走人；
- 很多應該懟事情的討論會，開成了表彰會；
- 做事做一半，技術重構本來能解決未來2，3年it成本和快速高質量交付問題，結果做了一半，導致事情更復雜，對上沒結果；
- 缺少領域能力，看事情可能只看開始不看全域性，比如人力外包，只考慮了外包人員如何登入，至於外包質量如何控制，效率如何管理，安全如何保障，公司其他部門如何協同，就不用去考慮拉，最後結果大概率是IT投了人，系統不用或是沒什麼卵用；
- 不考慮成本，更不會關注有價值的結果，只管做，加班加點做，至於ROI是不是真的高，是不是真的有用，好像沒人太關心；
這樣的問題可能在任何公司都有，但公司依然是個好公司，比較大的問題可能是看不到希望（可能有些小小的傲慢）。看不到為此在用心，用力，把事情引導向好的方向。
站在一個運維的職位上，想到的一些狹隘的建議：
- 把IT從執行變成決策參與者，讓IT用領域能力去支撐公司業務。阿里雲的人特別希望能有一次機會來北京給您當面彙報下，作為阿里雲，他們是如何用雲的能力去推動業務發展以及他們從資料維度如何看到行業的；
- 適當的放棄一些無效或是錯誤的量化指標，從定量到定性，減少一些無效的浪費和可能導致錯誤的引導；
事實上，該同學的出發點是好的，真的就是想提一些意見，暴露一些問題，但他的歸因跟我第一份工作一樣，做的很糟糕，認真讀下來感覺彼此認知差異巨大，於是便給他寫了一個回覆：
同學你好，很高興你對團隊表達的問題，面對你所提問題我覺得還是有必要作下回答。
首先我個人認為你所描述確實是開發部某個期間的狀態，公司其他部門或多或少都有這些現象。
但我當然不認為這是領導力的缺失，或者Leader的缺失，事實上其根本原因是開發部暫時的真空期，缺失一條主線，乃至是行業困境下公司戰略調整導致的主驅動力暫時還不足以帶動整個車隊，而我們公司只是大環境下的一員，雖然不好，但並不很差。
增長放緩導致了內卷，最終導致了矛盾擴大，這個應該是根因。而什麼導致了增長放緩，這個與疫情、網際網路寒冬、公司嚴肅的戰略選擇，再到進一步的HC緊縮、費用收攏、團隊合併等等都不無關係。
所以，開發部狀態差只是多種原因交迫的暫時結果，其中的領導力佔比真不大
增長放緩是結果，團隊力求創新是當前的策略，不斷的同步戰略資訊是表現，這也是你為什麼看到了《公司微創新》、《產品研究結論權威釋出》、《創作吧》等等戰略資訊透傳的節目在不斷髮生的原因。
但學習是反人性的，團隊提供的是資訊傳導工具，OKR提供的是上升通道工具，而這並不能保證每個人一定能進步，事實上我認為公司能有20%乃至30%的人脫穎而出就很不錯了。
當然，具體到實施層面，我們依舊想要更多人蔘與，所以會要求Leader強制上線，但類似“簽到走人”的情況是不可避免，甚至是正常情況。
另一個方面開發部一直是有CaseStudy覆盤機制，用來以“懟”求進，所以團隊是自省的，公司層面的覆盤也在推進，但機制推行都是系統性工程，很難一蹴而就，裡面存在認知博弈和時機權衡，過於激進的推進很可能機制淪為噪音，最後反而造成更大的浪費。
最後說回Leader的缺失這個話題，每個Leader處理問題的選擇是不一樣的：
- 有些Leader確實喜歡處理事情層面的問題；
- 有些Leader會嘗試用機制去解決問題；
- 有些Leader更希望由資源層面解決問題；
具體表現就是一些Leader喜歡跟員工打成一片，一些Leader張口規則閉口制度，一些Leader喜歡盤資源盤錢。
比如你描述的技術重構本來能解決未來2，3年it成本和快速高質量交付問題，結果做了一半，導致事情更復雜，對上沒結果
這個就是一個ROI問題了，我也知道全域性系統年久失修難以維護了，但是他的背景是行業寒冬、團隊合併、預算緊縮、技術棧不同這些困難疊加的情況，如果依舊要推行重構，那就是花1000w要買什麼東西的問題，理智的人不會把資源放到重構上。
所以，這依舊是個資源問題或者說資源投入問題，不是團隊不想把資源往這裡投入，而是確實暫時沒有那麼多資源。
再比如說外包，那真的是迫不得已並且不得不為啊，其中苦楚不足為外人道也，但這些都是過度狀態而已。
然後，感謝你的建議，技術變成決策參與者，這也是我們想要努力的方向，但阿里雲的人我見了很多次了，你可以認為他們更多是從事“商務活動”，畢竟大環境不好，商務活動只會更頻繁，並且公司的主方向是騰訊雲；
最後，沒有指標就沒有方向，無效的指標和錯誤的指標，也是一步步試出來的，這個場景要拉到公司角度，那麼多部門，都要不停的試資料，調模型，才能最終走向科學。
後來跟該同學還有一些其他方面的討論，但都感覺聊得有些空，不在一個頻道，就不再貼出來，但其中他一個觀點倒是引起了我的思考：
技術部門為何從一個決策者淪為了執行者？
為此首先問了自己幾個問題：
- 什麼是決策者
決策者是告訴團隊接下來做什麼的人，並且這個預測是正確的。
- 第二個問題，技術部門應該是決策者嗎？
技術部門當然不應該是決策者，至少暫時不是，將來某個時間段可能是，但長期來說，在我們的業務場景下不會是。
- 第三個問題：不是決策者有問題嗎？
財務是決策者嗎、人力是決策者嗎、法務是決策者嗎、品牌是決策者嗎、政府事務部是決策者嗎？
並不是誰都應該是決策者，在合適的角色做好正確的事情，就已經是一件很酷的事了，一個決策需要很多核心支持者。
所以技術部門在多數時候其實不適合做決策者，技術驅動的公司一般是阿里雲、神策、聲網，這種純技術服務驅動的公司。甚至外包公司都不是技術驅動的，他們可能是商務驅動的，我們對自己的社會角色分工要有一定理解。
最後，作為Leader大概率都會收到這種離職“告白”，其中有好有壞，有建議也有投訴，大家不要把他當一回事，也不要把他不當一回事，對於很多暫時不能解決問題的要提前向上預警，要有本質的認識和系統的解決方案，有認知、有方案，如果你只是認為是暫時性，過度性的困境，那麼面對突發投訴問題就不會慌了。
好了，今天的分享就到這，喜歡的同學可以四連支援：
想要更多交流可以加我微信：