最近聽說了很多事，加之目前自己也處在被彙報以及需要向上彙報的狀態中間，迫使我開始思考向上管理（managing up）這個話題。這是一個有爭議的話題，很多人（包括曾經的自己）下意識的會將向上管理與徒有其表的討好或者迎合這類負面詞劃上等號。藉此契機在查閱了很多資料之後，才意識到它不過是一項職場軟技能而已。
先從這些事情開始說起，有些發生在我身上，有些是我聽來的，有些發生在很久以前：
如果你一時不太理解這幾個事例和向上管理的聯絡是什麼，沒關係我會在後文一一道來
首先需要澄清的是，這裡所說的「向上」針對的是大部分常規情況（average）——什麼是「大部分常規情況」？說白了就是你依然有意願和你的老闆（本文中代指所有你可能彙報的物件）進行溝通。我反對用「人無完人」的聖母論調否認壞老闆的存在，把工作中的摩擦都歸咎於自己。只不過有時候你需要區分壞老闆和壓力中的老闆兩類不同人群。
廣義上的向上管理可以涵蓋上下級間的種種事務，所以在哈佛商業評論網站裡向上管理的標籤下，你會看到諸如「如何與不稱職的上級相處」，「如何給你的上級提出反饋」等等內容。從這些文章裡你會學到針對每一類情況應該採用什麼樣的策略來應對。但本文並不是另一篇職場危機的化解指南，因為在我看來對症下藥解決的功效實在有限。總會有前人無法預見的問題出現，總有問題需要你獨自解決，如果你清楚的知道問題背後的問題是什麼，處理起來會更得心應手。本文想討論的便是向上管理背後的出發點，以及有哪些普適原則是可以參考的
我想我們都同意，向上管理的目的是為我們贏得更多職場上的機會，這裡的機會包括但不限於你想做的事情、擴充你的團隊、你想要的職位等等。之所以想明確指出這一點，是因為當我在查閱有關向上管理資料的時候，有很多其他目標也被提出，比如為了讓你工作更加順利，為了影響上級對你的感觀，為了維護和上級間的積極關係等等。但是在我看來這些更像是手段，或者階段性里程碑：難道你付出了種種努力只是為了營造一個完美人設嗎？不，終有一天你需要將它兌換成職場資源。
也就是說當我們在談論向上管理的時候，大部分時候談論的是方式方法，但各式各樣的方式方法又難免讓我們落入到按照具體情況具體分析的圈套中——於是我才把本篇的內容限定在「入門」這個範疇內，我想我們可以找到一些易操作的低成本手段解決儘可能廣的問題。
向上管理的根基的溝通，這點我必須要首先強調出來。大部分工程師似乎自帶一類認知：我只需要默默把工作做好，然後用結果和成績來替我說話就好了——很可惜這類想法已經無法完全適應當下。
首先從個體出發，那類程式設計師拿到需求之後埋頭苦幹一個月然後上線的開發模式早就不復存在了。一方面我們看到專案開發中分工傾向於細化和專業化；另一方面之方面市場瞬息萬變要求團隊快速響應。兩者看似不相及，但背後都指向了對同一技能的高要求——溝通。如果你無法準確通過溝通及時瞭解到需求變化，如果你無法通過溝通了解到目前工作的阻礙在哪，如果你無法通過溝通了解到你需要聯絡誰來進行推進下一步工作，你的工作則無法完成。有效的溝通能夠幫助你從0到1完成工作，而向上管理則是錦上添花。如果你連溝通的意願都沒有，向上管理則無從談起。
回到本文開頭的例子，為什麼同學 B 會認為他負責的 bug 可以被推遲修復，本質上是因為他對 bug 的影響面和優先順序理解產生了偏差。解決這類問題最好的辦法是好奇心，在我看來這也是向上管理的核心。
請保持好奇心去了解你工作的全貌，瞭解你老闆的工作，瞭解你客戶的工作。雖然這裡「瞭解」這個單詞被不斷重複，但好奇心才是重點，它是你推動一切問題的核心。
再比如我們再看看 C 同學的例子，他對於工作內容的理解過於純粹了：我只需要把程式碼寫好即可。
「程式碼需要寫的多好？」，「程式碼需要寫的多快？」這是兩個需要想通的最根本問題。我理解每個程式設計師都希望成為能夠細心雕琢程式碼的工匠，並且討厭被當作螺絲釘，但很抱歉在面對跑馬圈地的網際網路的競爭的時候，絕大部分時候快比好更重要。我並不是說交付相關和非交付相關就一定是二元對立的，對程式設計師成長有益的技術難題就必須被犧牲掉。我們可以採用更靈活的方式處理這類問題：比如採用其他技術方案繞過問題來優先保證上線，然後再爭取更多的資源來回過頭解決這個問題。我的經驗是「時間」是解決「難題」的最大敵人，在 StackOverflow 上提問，向 GitHub 提 issue，做 demo 驗證你的猜想都是長線工作。
值得一提的是 C 同學的反面也並不少見，想象一位 D 同學被公認為團隊裡的好好先生，任何人有問題第一時間會想到他，他也有求必應。很可能他一天的工作下來的結果是幫助大夥解決了不計其數的難題，但是自己的程式碼絲毫沒有進展只能晚上加班寫。同學 C 和同學 E 身處不同的場景但是都犯下了同樣的錯誤。
你的工作絕不會僅限於程式碼，一定還包括解決方案，技術選型，以及彙報等等。這些任務最終結果的好壞取決於你對任務背後問題理解深刻與否，甚至取決於你對提出問題的人的理解深刻與否：方案針對的業務問題是什麼？彙報物件想聽的是什麼？我曾經聽說有人提出過工程師是否需要了解業務的疑問——提出這種問題的人不是蠢就是壞：業務是問題目的技術是達到目的的手段，如果你對目的都還不清楚如何選擇手段。還有一類對理解工作帶來的益處常常被忽略：有助於你在更大範圍內推進工作。和人打交道的工作比程式碼更難，但無法避免。因為在大規模共同作業無處不在的今天，你的工作大概率需要依賴他人來完成。如果你需要的後端資源遲遲不到位，甚至不配合怎麼辦？你應該聯絡誰，在說服他的過程中應該給出什麼樣的理由，也依賴你在專案中的上下文。
截至目前我還都是在討論「我」，至於「我」和「向上」的關係，則是我下面要聊的內容
我們時常需要解決高優先順序的線上問題，這類問題需要我們 24×7 小時工作在上面直到修復完成。因為問題對業務的影響面巨大所以各方都非常關切，客戶或者專案經理會不停的詢問你進展細節。對於正在一線解決問題的工程師來說，因為這不僅在打斷工作節奏，還對解決問題毫無幫助。
如果我們換一個視角看待問題，事情也許就說的通了：確保功能穩定是他們的工作職責，他們也有自己要負責的甲方。但弔詭的地方就在於，通常對於此類非技術人員來說，他們承擔著更重大的責任，能做的卻微乎其微，這可能是他們介入問題的唯一方式。所以你不能簡單粗暴的告訴他們別管了來單方面的解決你的困惱，問題矛盾在於我們既要保證他們的工作職責得以履行，也要保證以工程師工作不被打攪，通常緩和此類問題的恰當方式是，工程師可以定時向上更新工作進度，尤其是在取得重大突破的時。
工作中的「不對稱性」時常被我們忽略：我們會因為視訊會議另一端的某個人每天在同一個會議上出現，以為我們共同承擔同一份工作職責。並由此產生抱怨：「為什麼他沒有參加今天的站會？」，「為什麼我們發給他的郵件他還沒有回覆？」——因為我們完全不知道對方所處的商業機器是如何運作的，我們只不過一廂情願的在給自己的優先順序打分。我們完全沒有意識到我們打交道的雖然只是一個人，但他可能代表的是一個組織，在一些我們認為「匪夷所思」的決策上，可能他只不過是意志的傳聲筒而已。
拉回身邊，例如你認為你所在團隊 Tech Lead 的職責是什麼？我沒法告訴你它是什麼，但是我可以告訴你它不是什麼：如果 Tech Lead 每天100%的時間都在和你做一模一樣的事，那他一定不是稱職的 Tech Lead。這種認知的轉變是非常重要，當你意識到他的工作中心並不在你身上，甚至不在程式碼上，這會迫使你開始考慮你和上級的合作以及溝通模式。如果他無法隨叫隨到，無法第一時間響應你提出的問題，那你需要想辦法不要讓他成為你工作的單點依賴。
我在前一篇文章《關於時間管理的一點建議》裡，提到了一類經理常常陷入的反模式：來者不拒的解決下屬提出來的所有問題。正確的做法是，經理可以提供建議，可以商討後續可以採取的行動，但問題應該最終歸還給下屬自己獨立解決。為了達到這個目標，需要在團隊內明確主動性，鼓勵團隊成員採取儘可能高的主動性，禁止低主動性。主動性從低到高可以分為5類：
所以對於經理來說最理想的團隊工作模式是，團隊內的成員主動去發現問題並且解決問題。再說的再直接一些，我們應該儘可能減少上級的工作量而不是增加他們的工作量。如果上級每天都在擔心你的工作，甚至迫不及待想替你完成手頭上的工作，這對大家都不是好事。這一切的前提便是上一小節強調的，你需要清楚的知道你要做什麼。我想不少人聽說過一個類似職場技巧：提出問題時同時也給出解決方案，或者至少可以邁出去的第一步——它背後的原理就是如此。
你可能會問，如果在徵求上級意見之前提出的方案是錯的怎麼辦？果真如此的話，我會把它當作一個對齊你我之間想法的機會。說實話我作為 Tech Lead 最擔心的就是，當我在給團隊成員講解需求或者方案後，沒有任何人提出任何問題。有分歧、有偏差、有不同意見很正常，一致的沉默讓人害怕。
在 2019 年的 QCon 大會上，曾任 Etsy CTO 的 Kellan Elliott-McCrea 進行了一次有關向上管理的分享 Getting Real about Managing up，在這次演講中，他對向上管理進行了如下定義，即向上管理其實是讓你的上級更好的幫助你把工作做好。：
……I'm going to shift some of that load to you. You're welcome, you've been deputized. Good news, it means I'm giving you some control over your destiny……what we mean by managing up is making it easier for your manager to support you in doing great work. That's our definition of managing up
我對此非常贊同，想辦法讓我們自己做好主角，讓上級做好的配角就夠了。
你想知道向上管理「落地」是什麼樣子的？前幾天剛好在極客公園一篇關於 Meta 裁員的報道里（《Meta萬人裁員親歷者自述：小扎嚐到了降本的甜頭》）看到了 Meta 裡是怎麼做向上管理的
Meta 的特別之處是員工非常善於向上管理，做 manager 似乎比 IC (Individual Contributor) 輕鬆。enigneer 要給自己找方向，需要驗證自己的方向是大方向。領導最大的工作，就是保持下面 enigneer 的工作動力。
我的 manager 在這裡工作多年，我會告訴他我想做什麼。他會告訴你一些個人看法，告訴你他覺得這個方向怎麼樣，指點一下。如果他覺得合理，他就會說你去做。他覺得不合理，會再給你一個方向，讓你去想一想。但如果你輪到別人給你方向，這可能不是個好方向。Meta 的哲學是，你自己找的方向會有動力去做，等別人給你方向你就會隨便做做，那對你自己不好。
我們究竟在解決什麼問題？
在東東槍老師的播客《宇宙牌電飯鍋》裡，他提出了這樣的一個觀點：
我們講甲方乙方……不管你做乙方是做什麼業務，廣告也好，諮詢也好，甚至是老師也好，你以為幫他解決了一個商業問題，你以為幫他解決的是一個需要專業技能的問題……你解決的是他個人在職場上，在他的職位上要面臨的一個難題，而且你的解決方式很多其實是情感式的，你讓他自信了，你讓他安心了。
這是非常厲害的洞見，他提供了一種完全不同的視角看待你的工作：你以為你本質上提供的是專業技能，但實際上你帶來的是心理慰藉。考慮到我們每個人本質上都是在以乙方角色在工作，仔細想想，你很難說他是錯的。
至於高階技巧，有機會以後再聊
你可能會喜歡