李昊:從技術到管理,如何實現螺旋上升?

李昊:從技術到管理,如何實現螺旋上升?

作者 | 李昊

出品 | 《新程式設計師》編輯部

從開發者到技術管理者應該如何提升能力?在李昊看來,開發和管理之間的“鴻溝”並非很難跨越,他將從“深入理解基層技術管理崗位角色、糾偏對技術管理者的認識誤區,以及透過日常執行層真正做好管理”三個維度,給初為管理者的開發者一些入門指南。

自Marc Andreessen在2011年提出“Software is eating the world(軟體正在吞噬世界)”,十餘年來,在“軟體+網際網路”的驅動下,各個產業實現了深度融合。對於開發者來說,透過深入產業的大量實踐,其設計硬體、編寫軟體、擴充套件架構等技術能力獲得了迅速提升,甚至在一些核心技術上取得突破性的成就,讓國產IT技術從趕超者變成了引領者。

然而,在各產業面臨進一步轉型升級的當下,我卻產生了很強的憂患感,我們急需精進技術管理能力,但不得不面對人才稀缺,特別是基層管理人才缺失的危機。

對於剛入行管理的開發者來說,最缺乏的還是基礎管理技能,這取決於對崗位的理解是否透徹、如何處理技術與管理之間的關係,以及如何正確認識管理工作。如果尚未把這三點思考清楚,很可能忙碌一天發現自己只是在處理各種被動的突發情況,很難有主動的創造性。長此以往就會有種只是在“打雜”,而非真正把控組織的管理提升之感。

我從開發崗到管理崗,也經歷了一段適應期。我自己的感受是,開發和管理之間的“鴻溝”並不難跨越。一旦理解自己是管理新手,並認定這是我選擇的新職業通道,就可以很好地和“我今天啥也沒做全打雜了”的感受和諧相處,進而開始認真學習管理,練好“聽、說、讀、寫”的基本功,讓自己看明白、說清楚、做正確。隨著自己管理的團隊取得不錯的成績,我獲得了比只是寫程式碼更大的成就感。

李昊:從技術到管理,如何實現螺旋上升?

李昊,曾在IBM、Ericsson、Myriad等公司從事嵌入式、伺服器端和客戶端系統的研發及團隊管理工作。2013年創業,先後在TestBird、貨車幫、西瓜創客等公司擔任產研負責人、CTO等技術高管角色,目前在FITURE負責增長。

作為過來人,我也想把自己的思考與心得分享給更多管理新手,透過分析技術管理者這個角色的核心痛點、難點,結合我近十年在管理不同規模產研團隊過程中得到的經驗和教訓,為大家總結從個人貢獻者到基層技術管理者的職業轉變中需要了解的相關知識和技巧,希望能幫助大家把管理之路的第一步,走穩、走好。

本文節選自《新程式設計師004》 『紙質書+電子刊』已開啟預售

如何正確認識從開發者到管理者的角色轉換

在進入主題討論之前,我先簡單談談自己的經歷。

我是技術出身,進入管理崗前,在外企做到了Principal Engineer(首席工程師)。之後意識到如果想研發出更具創造性的技術必須從更多維度去了解產品和業務,於是我就開始做技術管理。一段時間之後,又轉回了研發崗,就這樣在做技術和做管理之間轉換了幾次。

後來,我發現如果真正想把產品和業務做好、做通,作為管理者最重要的是釐清技術與管理之間的關係,而首要的則是深刻理解技術管理者的角色。

理解基層技術管理崗位角色

萬事開頭難。作為工程師踏上管理崗位的第一站,可能會對基層技術管理工作的供需兩端都存在誤解。

在供給側,大家進入管理層的機緣和意圖是多種多樣的。有些人因為專業能力強,在團隊有話語權被推向了管理崗;有些人因為渴望服務於他人的成長而從事管理崗位;更多人則因為世俗的原因:升職,會有更多權力和收入的預期增長;甚至有些人進入管理層只是因為厭倦了被低水平的人管理,堅信自己做管理者可以做得更好。不管起心動念是什麼,和以前作為個人貢獻者相比,決定成為管理者的工程師將進入一個全新的、充滿挑戰的職業通道。

事實上,技術人在初入管理層時會面臨這樣的現象:只有少數公司真正願意對管理能力進行投資和培育,特別是基層管理。它的起因主要在於有效的技術管理既需要技術能力,也需要管理能力,而這兩種技能的培養需要大量的時間。於是就能看到很多企業會因為基層管理者的管理能力問題,小到出現各種各樣的糾紛和摩擦,大到高層制定的技術戰略無法被正確地分解和落地。

因此,要做好基層技術管理者這個崗位,首先要理解這個角色究竟意味什麼。做技術管理者不是晉升,而是切換到一個全新的職業通道上,要對自己作為新手有足夠預期,及時學習和補充欠缺的管理必備技能,包括:怎麼提高團隊效率;怎麼考核團隊績效;怎麼選、育、用、留人才和打造工程師文化;怎麼分配自己的時間;怎麼做好向上和向下的管理。每一個話題都很艱深。

技術管理離不開技術

基層技術管理的另一個難點在於軟體開發的複雜度:可能在某個給定的時間點處於平衡,但長期來看軟體開發仍然是動態變化的。比如,近年來容器技術帶來的變化,並非出現了顛覆性的技術突破,只是一個微小的變化引發另一個微小變化,當一系列變化集中湧現時,一個新的生態系統就產生了,並被各種場景廣泛使用。因此,和很多傳統的工程領域相比,軟體開發本身就是一個動態平衡的過程。

然而,軟體開發人員很容易迷戀某種特定的技術或方法,甚至會形成技術棧的鄙視鏈。但現實世界中的軟體構建並非二元選擇,而是在各個細節上不斷權衡。比如,後端用Python、Ruby這樣的動態語言還是Java?CI/CD用自建的工具鏈還是現成的雲服務?資料的採集、清洗和儲存透過什麼方式完成?要不要拆微服務,還是就做一個單體應用?這些問題都沒有適用於任何條件的最優解,管理者必須有足夠的技術判斷力,才能根據專案、團隊和資源的現狀,選取合適的折中點來達到業務目的。

因此,要成為合格的技術管理者,不能沒有紮實的技術作為保障,否則很難獲得團隊信任。只有讓自己成為領域專家,才能參與設計討論,發現計劃中的差距或評估錯誤,從而解決技術衝突。同時,技術管理者還要很好地理解團隊正在做的事情,並在工程師不在場時向其他人,特別是管理層闡釋團隊產出的價值。

還需要注意的一點是,技術管理者不一定要成為架構上的決策者(通常架構師做這件事情),但他們必須知道何時介入,以及由誰介入,便於推動問題的解決。

管理不只是“工作的一部分”

基於技術的重要性,很容易產生的誤解是把“管理”當成技術管理工作的一“部分”,特別是基層管理者通常因為技術上異於常人的優勢而被提拔。選擇做管理之後,會有一段時間發現自己每天都被各種人和事打亂工作計劃。每天精疲力竭地回家,卻感覺一天下來沒有做一件“有實際意義”的事,非常惶恐。這樣一來,不少人會為尋找意義而回歸研發一線,透過解決一個個具體問題而獲得舒適感,結果讓自己的管理工作變得更加脆弱,最終進入一個負迴圈。

這是一個沒有正確理解管理工作,不具備管理技能帶來的大問題。

初做管理時我也有類似的問題。於是,我記錄了自己的時間分配,並且在時間塊旁邊記錄當時的狀態。很快我發現,自己還是花了很多時間參與編碼,當我參與甚至負責核心模組,或者是解決阻塞性的技術問題時,我的感覺非常好。而當我花時間完成管理相關的工作,無論是按照商業目標分解團隊目標,把戰略分解成戰術,積極推動、執行、落地,還是花時間理解員工的需求,評估員工的能力,為他們分配有挑戰但又夠得著的任務,打造他們的上升通道,總會感覺到疲憊,甚至是沮喪。

然後,我就開始有意識地調整自己的時間安排,一方面,系統學習管理的知識和技能,預留足夠的時間完成管理工作;另一方面,逐漸退出核心模組的編碼工作,只寫工具或修補漏洞來保持對系統的瞭解。一段時間後,我發現領導團隊有了更好的效果,大家都感覺到了成長,團隊的成長也讓我很有成就感,這就形成了正迴圈。

總之,管理不是技術管理工作的一部分,而是它的全部,一定要全心全意地投入支撐和服務團隊的工作中來。

如何做好基層技術管理

在瞭解到基層技術管理崗位的角色含義後,如果你仍然有興趣做管理,接下來需要做的就是具體執行。

從我自己做管理的經歷來看,最初的問題主要是基礎管理技能的缺失。可能一整天都會在安排團隊工作、自己寫程式碼,以及在各種提出意見、覆盤、確認中手忙腳亂。

在這種情況下,一定要走出編碼的線性思維,不能遇到什麼做什麼。究竟應該怎麼做?我認為,分五個部分:確定時機;制定“標準動作”日曆;做好一對一溝通;練好“聽、說、讀、寫”的溝通基本功;沿螺旋軌道上升。

確定時機

基於專業知識的必要性,從事技術管理不宜過早。在我自己管理的技術團隊中,P8及以下級別不單列管理崗位。假如你處於還未成為管理者的階段,並有志於成為管理者,還是有很多事情可以做的。

首先,你可以讀一些管理方面的書籍,比如Camille Fournier的The Manager‘s Path。然後,帶著這些背景知識去識別自己所在團隊管理者的管理風格和手法,從中學習。如果條件允許,你可以考慮加入公司內口碑較好的管理者所在團隊,近距離學習這些管理者的管理技巧。與此同時,你還需要花時間瞭解公司的文化和成長階梯,就像本文開頭所說,不是每個公司都會重視基層管理者的培訓。如果你發現公司搭建的通道和你想要的不太符合,要早做選擇。

當你認為時機比較成熟時,就可以主動表達自己的意願了。這裡的竅門是不要等機會來了再表達,在你覺得自己準備好了的時候就可以說明。和上級大大方方地講自己的想法和計劃,同時也留意公司內其他團隊的機會。

制定“標準動作”日曆

成為管理者後,你的時間會被切割得很碎。這時,一定要在日曆上制定一些標準動作,如每天、每週、每月的標準動作。完成這些動作後,你的管理質量就有了基礎保障,就可以放心大膽地利用其他時間做其他的工作,特別是應對各種突發狀況。

基層管理工作在組織、績效、跨部門合作等方面參與較少,因此這些標準動作主要是關注流程和團隊,可以按照時間段的短、中和較長期來劃分。

短期:每天

瞭解團隊每位成員的工作計劃、進度和困難,可以透過站立會,也可以透過程式碼稽核,當然也可以透過聊天的方式來完成,無論用什麼方法,必須做到位。

參加至少一個技術討論,看是否能理解並發表觀點。不要組織或參與冗長無功的討論,如果還處於定義模糊的階段,最好線下面對面地討論。

解決所有成員提出的問題和困難,這裡的“解決”是說指明方向,而不是手把手教授。

檢視團隊成員提交的程式碼和文件,明確是不是在做“有用功”。

以身作則流程化,整理並跟蹤所有的需求、結論、思路,多寫文件。其作用是給自己捋思路,推薦用英文寫技術文件,這樣更簡單明瞭,畢竟多數人的詞彙量沒有大到能夠通篇“廢話”的程度。

做好負載均衡,把事情均勻地分配給團隊成員,確保沒有人同時負責太多併發任務。每個人應該專注在一兩件事情上,如果發現有人停滯不前,應該主動疏通調整。

以上這些事情因為要每天做,所以最好藉助系統工具來完成,如“Jira+Confluence”或“飛書+Notion”。

中期:每週

審視整體進度,根據實際情況增加或延後任務。

和產品經理協作,做好任務的拆解,包括提前準備線框圖等,確保所有人對任務的理解一致(包括介面細節)。

週報不要長篇大論。週報必須有結構,包括本週完成情況和歸因分析、下週的計劃目標,以及關鍵依賴或需要什麼幫助。

較長期:兩週

找到感興趣的系統細節,深入瞭解和思考其中的邏輯,與負責這部分的成員深度合作,或者在自己完成框架的基礎上找到這部分負責人繼續完成其他細節。

做好一對一溝通

和員工定期一對一溝通,就像開車出遠門檢查油箱還有多少油一樣,非常重要。但員工身上沒有儀表盤讓你能夠讀數,那麼,一對一溝通具體怎麼做呢?

一對一溝通總體有兩大類,一類是跟直接彙報給自己的人溝通,一般每個月都需要做。當公司有重大變化時,則不拘於頻率,按需溝通。

另一類是跨級的,這對你的管理也非常重要,特別是針對新員工和即將轉正的員工。不同的溝通物件要準備不同的內容。有兩個核心技巧:第一,搞清楚由誰主導對話。大多數時候你要有自己主導對話的準備,但也有些時候員工想要說更多,就應該讓他們盡情表達。從一個輕鬆的話題開始,看看他/她是不是有表達慾望,如果有,那麼本次溝通應該是你傾聽為主。第二,以下我列出了一些適用於溝通的問題,但都只是綱要而不是“臺詞本”。你可以圍繞這些問題發現背後想要了解的內容,自然輕鬆地聊天,同時,一定要仔細記錄和跟進對方的反饋。

對所有人都適用的問題:

你狀態還好嗎?進展是否順利?

在做事的層面,有什麼是我可以幫忙的?

在和其他人協作的層面,有什麼是我可以幫忙的?

對於剛加入的新同學:

你遇到過什麼問題嗎?

入職流程有什麼可以改進的地方?

有沒有想法想分享給所有人?

對於即將轉正的成員,除評估工作進度外,核心是建立溝通模式:

哪些事情會讓你覺得狀態不好?

我可以透過什麼辦法知道你狀態不好?

在狀態不好時我可以怎樣幫助你?

此外,還有針對入職一段時間的成員可以提的問題。

每次都可以提的:

• 我觀察到你在做的事情,我有一些建議。

• 你的合作方對你的工作有這些反饋。

• 哪些地方做得好/不好,可以怎麼改進。

• 什麼樣的1:1更有價值。

每個月可以提的:

• 有沒有好奇或擔心的變化需要我解釋?

• 有沒有聽到或感受到的事情需要我確認?

• 讓我告訴你一些可能會影響你和你團隊的資訊及決定。

• 讓我們討論更廣泛的組織發展目標和方向,確保你的目標和公司的目標一致。

每個季度可以提的:

• 今年的目標是什麼?最近三個月的目標是什麼,完成得怎樣?

• 需要從我這裡得到什麼幫助?

• 需要從團隊得到什麼幫助?

• 需要從團隊外部得到什麼幫助?

學習和成長主要有四個目的,包括有新的且更具挑戰性的事情可做、能夠主動和團隊交流及溝通互助、營造公平向上和開放進取的團隊氛圍,以及定期定時、清楚明確地進行績效反饋,確保進展順利。

這裡我需要再強調一點,一對一溝通成功的前提是雙方有信任感和安全感。如果關係不熟,可以先從愛好、感受、未來規劃等事情開始聊,不要強行問上面的問題,會讓溝通物件有壓迫感,也不會得到他們真實的想法。相信我,只要把上面這些工作做到位,你已經是相當不錯的基層技術管理者了。

練好“聽、說、讀、寫”的溝通基本功

在管理中有一個“第一團隊”和“第二團隊”的概念。

很多初做管理的人可能不知道,自己的平級以及彙報物件才是“第一團隊”。而彙報給自己的人以及他們的下屬其實是 “第二團隊”。如果記錄你在這兩個團隊中花費的時間,往往會發現,花在第二團隊的時間佔絕大部分。而實際上,能不能和第一團隊對齊目標、協同作戰,真正做好第一團隊和第二團隊的銜接,是在做管理崗後職業發展通道的第一道坎。

怎麼邁過這道坎?我認為最重要的是提高自己面對衝突和壓力的能力。大部分做基層技術管理的同學花過多時間在第二團隊,說白了,是因為自己在樹狀結構的頂點,在裡面待著比較舒適。而成熟的基層管理者,不僅要主動解決組織中的衝突,甚至常常刺激良性衝突發生,以促進組織目標的達成。

要完成這樣的轉變,首先要練好“聽、說、讀、寫”的溝通基本功,提高自己獲取、過濾、篩選資訊並把觀點簡明扼要表達的能力。然後,要對如何提問、傾聽、表達,以及高效達成共識等方面進行刻意練習。在這個過程中,要增強對情緒壓力的認識和了解,體察自己及同事的壓力和情緒狀態,真正把衝突和壓力轉變成充分表達想法並形成團隊合力的機會。

總之,只有走出自己的舒適區,與第一團隊充分溝通,瞭解公司的戰略、戰術方向,清楚各種決策的上下文,才能有針對性地推動第二團隊做正確的事,正確地做事。

沿螺旋軌道上升

回顧我自己和很多朋友的職業發展道路,我還想給基層技術管理者一個建議,就是技術管理和技術專家兩條職業通道並不是對應關係。也就是說,並不是做了基層技術管理者,就只能沿著這條路走到黑。

正好相反,最好的工程師往往是做過一些管理工作的,因為他們更懂得溝通,更有成本意識,更注重交付。最好的管理者往往有2-3年在一線做技術的經驗,因為他們更有技術手感,能和團隊良好溝通,也能做更高質量的判斷和決策。

因此,好的技術管理者和好的技術專家,發展都是沿著螺旋軌道上升的,看起來可能一會兒往西,一會兒往東,在兩個通道中來回切換,但因為兩部分的知識和技能都得到了紮實的發展,整體前進的潛力會更大,步子也會更穩。

當然,想要有這樣的心智,在信奉“學而優則仕”的環境中不太容易。如果你從心底接受管理不是晉升的理念,就很容易接受從管理做回工程師不是“降級”。相信經過兩、三個這樣的螺旋上升,你就可以成長為駕馭複雜團隊和系統的成熟管理者了。

結語

目前,我在公司內部的管理角色從產研切換到了增長,我將主要的管理規劃稱為“打通三套語言的目標管理體系”。實際上,無論在哪個公司,我都認為一直存在著三套語言:客戶視角的語言(需求、痛點、體驗);產品視角的語言(特性、流程、版本);業務視角的語言(獲客、留存、轉化、利潤、收入)。

我曾有幸管理過大量異構團隊,希望能透過一些方法和工具,在公司內讓大家從需求的產生,到產品的設計,到最終商業結果的達成,形成一套完整的目標管理和執行跟進體系。

從微觀到宏觀,對於每一位想要成為技術管理專家的開發者來說,都需要從底層認知開始挖掘。本文主要面向初入管理崗位的基層管理者,該階段需要習得很多知識和技能,也伴隨著焦慮和壓力。

作為一篇通識類技術管理文章,首先希望幫助大家理解管理崗位的特點和難點。然後從時機選擇、日常管理動作,以及如何進入第一團隊等方面,給出了一些具體建議和行動指南。

技術管理作為一門發展了上百年的學科,要融會貫通,需要相當長的學習和實踐。但我相信,只要在從事基層管理時就有正確的認知,經過不斷努力,每個人都可以成為一個成熟的管理者,在職業發展中收穫豐碩的成果。

— END —

本文節選自《新程式設計師004》,從MySQL之父、MariaDB創始人 Michael “Monty” Widenius,到PostgreSQL全球開發組聯合創始人Bruce Momjian、阿里巴巴副總裁賈揚清、指令集創始人兼 CEO潘愛民、著名科技作者吳軍,再到 Vue。js 作者尤雨溪……《新程式設計師004》以「我們的技術時代,我的程式人生」為主題,與多位國內外知名的技術先鋒和新生代程式設計師代表進行了深度對話,希望行業優秀人物的技術之路與人生感悟給大家帶來啟發。

新程式設計師讀者俱樂部限時開放,歡迎大家掃碼入群!

頂部