如果我是一線技術主管，那我可能是團隊曾經綜合實力最強的，我可能會被時間支配而不能再天天寫程式碼，並且，團隊充滿各種挑戰。
如果我是一線技術主管，依然是每週要寫週報，每年要寫績效，想晉升，想加薪、想人生巔峰等等。
如果我是一線技術主管，在團隊只有五、六個人的情況下還好，如果是十幾個人的團隊的話，會希望有人可以站出來幫我。
如果我是技術主管，我更希望：
不抱怨
如果我是一線技術主管，我不會喜歡團隊有喜歡抱怨的同學：
1. 主管每天也很忙，聽抱怨很消耗時間；
2. 團隊有人抱怨，說明團隊自然是有問題了，需要花一定的時間梳理出問題，需要及時給出解決方案，甚至要安撫對方情緒；
3. 一個喜歡抱怨的人會影響整個團隊的士氣。
其實大部分開發抱怨的工作內容很相似，團隊成員不配合做事，PD 提了無理的需求等。
大促中我們的後端主管說了些很好理解的話：“看到大促有這麼多問題，我很激動，這種情況很好。問題越多說明機會越大，如果都是穩定健壯的系統、完善的流程、合作良好的團隊，那麼，要大促 PM 幹什麼呢？”
如果問題都是機會的話，那就沒有抱怨的必要。但是，如果真的就是有問題，還不能說了嗎？
向上管理
一個管理十幾人的團隊主管很難有精力做到面面俱到，去了解所有人的細節，給大家找出合適的方向和機會，甚至認真讀完每個人的週報都要用一個下午，很難做到你有一個不錯的想法的時候，主管就有時間找你聊聊。如果我是一線主管，我更希望團隊同學主動找我聊。
作為主管每天既要處理大量一線資訊，又要領導團隊做出正確的決策，還要照顧團隊的每個成員，做出健康的梯隊建設計劃等，大部分人是沒有這個精力的。
剛開始工作的時候，我們誤解主管和下屬的關係就是領導與被領導的關係，但其實主管也需要被下屬管理，這也就是“向上管理”的由來，簡單來講就是主管也需要下屬的協助和推動。
主管大部分時間很忙，這就要求下屬在向上管理的時候要尤其注意高效、有質量的溝通，如果我是一線主管，我更希望團隊和我交流的方式是讓我做選擇題、判斷題，而不是問答題、思考題。
很多雞湯文提到老闆訓斥高管：我請你來不是告訴我為什麼不行，而是告訴我怎麼實現我的構想。在主管不是拍腦子就做的決定的時候，困難肯定是已經想過了，更希望得到的是下屬的幫助。
如果我是一線主管，我希望下屬這樣幫助我：
1. 主動承擔團隊面臨的挑戰，給出合理的解決方案；
2. 及時向我反饋經過整理的資訊和資料，甚至是結論，輔助決策；
3. 主動關心同事，組織學習，幫助大家（包括我）進步成長。
除了面對面的交流，和主管最多的溝通機會可能就是週報，這是向上管理的重要途徑，然而很多同學把週報當做一種負擔，寫的極其敷衍，就是一週的流水賬，傳送出來都是浪費自己和收件人的時間。
團隊不會有人認真讀完所有人的週報，讀誰的取決於週報的質量。個人習慣粗略瀏覽組內所有人週報（週報有 highlights 多重要），堅持幾周就能識別一些需要關注的週報，然後會針對這些人的週報設定郵件規則，必須認真看的，遇到不理解的還要過去問的，其它人的週報就被自動過濾掉了。一個普通員工都是如此，更何況一線主管。可見這麼寫週報可能在無意中浪費了許多次向上管理的機會。
每天忙不完的業務怎麼辦
還有一種抱怨的聲音是：自己每天很辛苦，想拼命忙完業務後做一些技術的東西，造個輪子什麼的，但一個需求還沒做完，另外一個需求就安排過來了。
如果我是一線主管，我會把團隊面臨的問題分一下級：
1. 重要&緊急，不能按時完成，則都是失敗；
2. 重要不緊急，是個很好的機會；
3. 技術想法，很好的撬動業務的點；
4. 單分析只是個業務需求，看不出明顯的興奮點。
團隊的人可能也有幾種特性：
1. 能力強，在某領域是專家；
2. 能力一般，有潛力，但是非常有積極性；
3. 能力一般，主動性一般。
其實不用特意說明就知道大部分主管分配任務的思路：
1. 重要&緊急的事情只能交給能力強的人去做，意願上如果有問題，也要說服對方去做，因人成事，可見能力強有多重要；
2. 重要不緊急的事情就可以借事修人，如果做得好，這個人以後就有信心了，團隊多了一員干將，做不好也有能力強的人給保底，不會造成業務問題；
3. 技術想法也可以交給有積極性的人做，這必然佔用一些時間，那麼這個人手頭上無關痛癢的事情只好交給能力一般，主動性一般的人來做。
實際上按照這個向上管理的思路，需要主管去分配任務的時候，你就已經輸了，甚至主管來找你問進度的時候也已經輸了。
當然每個合格的主管都需要發現、解決團隊人才培養的問題，不可能放任問題發生。
什麼樣的人有積極性
能力強的人很好識別，那什麼樣的人才是有積極性的，看過一個 AE 快速升 P8 的同學寫的文章，他有個很好的習慣。
無論大小難易，永遠不滿足於做出來指定的事情，一定要給人驚喜。
如果我是一線主管，我不會憑空把一件重要的事情交給某個人去做，我會更期望：
1. 團隊同學來教育我某件事情很重要，想去嘗試；
2. 在很多微不足道的小事情上做出了驚喜，有理由相信這件更大的事情也可能做出驚喜；
3. 我被分配了純業務事情怎麼辦？
上面也提到了簡單分析只是業務需求，近五年在阿里將見了太多事在人為的案例，每個人身邊肯定也有不少這樣的案例。
我們以為自己在做業務，很多時候是因為兩個誤區：
這不是技術專案：沒有什麼所謂的技術專案，所有的技術專案除非是顯而易見的專案，否則肯定脫胎於業務，只有業務一線的同學才可以抽象出來，做業務需求不是壞事情，拿著完成任務的心態做業務才是最要命的。
沒目標：所有做的事情都要契合自己的目標，而自己的目標大部分時候應該和團隊目標 match。今天讓我開發一個前端元件，我要看到的是這個需求反應了我營銷體系對某個分類能力的缺失，需求歸納到我營銷視覺化體系完善的目標中，在阿里這種人才濟濟的環境中目標不清晰的人和鹹魚沒什麼區別。
怎樣才算業務負責人
很多小夥伴已經是實際的業務負責人，和三、四個小夥伴一塊解決特定業務領域問題，但尷尬的是級別相同，在分配任務的時候會不好意思，覺得對方也有自己的"技術專案"要做，我得求他把這個業務需求做一下。
這種其實不算真正的業務負責人，如果業務負責人僅僅是分配任務，那麼任何人辛苦一些都可以做。業務負責人的核心特質應該是有一條是瞭解業務的發展、引導相關人的個人目標。
這樣可以把業務需求轉換成每個人目標中的一環，和上面提到的自己做事情思路是一樣的，無非就是寫程式碼的那個人不自己。其實即使主管也不可能命令團隊成員去做某事，採用命令那樣的方式，團隊早晚散夥。
最後，如果我是一線技術主管，我希望團隊的業務負責人時刻在兩個方面提醒自己：可衡量、可體系化。