為什麼研發團隊中的管理者往往佔比過高,研發管理的效果提升並不明顯?
一個 300 人 的研發團隊中,大概有 20-30 名 脫產的管理者。他們從技術轉管理,號稱要把自己的能力複製出去,卻變成了發號施令、脫離生產實際的人。
思考一下: 為什麼研發團隊中的管理者往往佔比過高?為什麼企業非要讓技術精英轉型管理? 為什麼轉型管理之後會從技術脫產?
我們都知道, 管理當中最難的部分是和“人”相關的部分, 因此早些年很多技術團隊會 傾向找一個“懂管理但不懂技術”的人擔任管理職位, 可這就出現了bug:
一方面,團隊成員會覺得和不懂技術的領導溝通成本太高,並且相當一部分研發人員骨子裡有一種驕傲,對這種領導難以信服;
另一方面,不懂技術的領導在做決策時,必定會對下級給出的建議和指導產生很大程度的依賴,這樣一來就為員工“欺上瞞下”提供了機會。
吃虧吃到爆,於是技術管理人才的選擇就走向了另一個極端: 找技術大牛來擔任,一個人苦練技術,練到一定級別,就開始帶團隊、學管理。
看上去完美解決了前一種模式產生的問題,然而——
“程式碼寫得好,不如和人打交道”
really?
技術人從事管理工作,又出現了新bug——當開始和人打交道,相對於埋頭鑽研技術來說,他們會發現這真是個輕鬆的活兒。隨著人越帶越多,攤子越來越大,從技術組長,到部門負責人,到技術總監,到CTO…… 一個技術人,自開啟始走管理路線就開始脫產,到了部門負責人基本上就全脫產。
這時,彼得現象就開始在研發團隊中不斷出現、累積。
所謂彼得現象,是由管理學家勞倫斯·彼得(Laurence J.Peter)提出的,也稱“向上爬”原理—— 在一個等級制度中,每個職工趨向於上升到他所不能勝任的地位。 出現這種情況時,對個人來說,失去了繼續晉升的機會,對組織來說,則會引起效率滑坡。
當技術人上升到管理者,他們一般會把所有的工作都分給下屬完成,自己一般是參與各種評審,給大家把關。儘管有些CTO會強行要求技術管理者們每個月至少要寫一些程式碼。但坦白說,效果極其有限, 這些管理者寫的程式碼,由於距離生產實際太遠,往往還不如員工寫得好。
既然管理(尤其與人打交道)是件相對輕鬆的事情,技術管理者就 不再去面對種種技術攻關和挑戰,這些事都可以甩給手下的技術人員; 他要做的,就是跟人打交道,甩鍋、撇責任、參加一些論壇和會議,這是作為技術管理者最輕鬆的狀態。這樣的人,就叫做 “技術官僚”。
一個技術人,轉管理的過程,就是官僚化的過程。 “官僚化”這個過程會一直伴隨到這個人升到合夥人級別, 只有當他身上的管理職責下降到一定程度時,才有可能持續精進於技術和業務,繼而關注戰略和經營,
技術官僚成了“壓艙石”“腫瘤君”
在組織當中,隨著規模增加,會逐漸開始形成大量的“技術官僚”。這些人原來是最核心的技術骨幹,當他們升到管理層,完成官僚化,整個研發團隊實際上已經空心化了。
這些技術官僚,從功能上說,只能扮演壓艙石的作用,佔地方、沒營養,唯一價值是保持大船的穩定;而且,更值得注意的是,隨著企業規模的擴大,“技術官僚”會像腫瘤一樣不斷增長,原因是—— “帕金森定律”(Parkinson's Law)。
帕金森定律是官僚主義或官僚主義現象的一種別稱,被稱為二十世紀西方文化三發現之一,源於英國曆史學家諾斯古德·帕金森(Northcote Parkinson)1958年出版的《帕金森定律》一書的標題。帕金森在書中闡述了機構人員膨脹的原因及後果:
“一個不稱職的官員,可能有三條出路:第一是申請退職,把位子讓給能幹的人;第二是讓一位能幹的人來協助自己工作;第三是任用兩個水平比自己更低的人當助手。”
第一條路萬萬走不得,因為那樣會喪失許多權力;第二條路也不能走,因為那個能幹的人會成為自己的對手;看來只有第三條路最適宜。於是,兩個平庸的助手分擔了他的工作,他自己則高高在上發號施令,他們不會對自己的權力構成威脅。兩個助手既然無能,他們就上行下效,再為自己找兩個更加無能的助手。 如此類推,就形成了一個機構臃腫、人浮於事、相互扯皮、效率低下的領導體系。
根據方雲君的研究, 一個300人的技術團隊,大概需要養20-30名脫產的技術官僚(他們的title可能還在技術序列)。 這些人基本都已脫離生產,他們的程式碼都沉浸在當年的故紙堆裡,他們維護了一個組織基本的制度、流程和穩定,守護著組織的底線。
很少有人還記得,他們原本是研發團隊最核心的一群人,他們加入最早、最懂技術、最懂業務,對組織最忠誠、最有創造力……然後他們開始轉管理,號稱要把自己的能力複製出去,卻變成了 發號施令的人、脫離生產實際的人。
數字化研發管理
大幅精簡技術官僚佔比
人的精力畢竟有限,只有相對少數的人才能做到技術和管理兩手抓,因此, 優秀的技術管理者(既懂技術又懂管理)是非常稀缺的。
戰略大師加里·哈默爾(Gary Hamel)曾在一篇名叫《Bureaucracy Must Die》的文章中提到: “如果一個組織想要超越未來,個人需要自由來改變規則,承擔風險,繞過渠道,進行實驗,追求自己的激情。”
百特國際執行長喬·阿爾梅達 (José Almeida) 將 消除官僚主義並與公司各級員工建立聯絡作為自己的使命, 儘管公司規模龐大—— 包括 60 家工廠和 12 個研發中心。 在接受《財富》雜誌採訪時,他表示:“消除層級的原因不僅是降低成本,還在於能夠與整個公司的人建立聯絡,這些聯絡也為冒險和尋找創新機會創造了舒適度。”
隨著企業的不斷髮展壯大,隨著技術團隊的發展,技術官僚化幾乎是所有技術團隊的必然。 數字化時代為打破這一魔咒提供了可能性, 用技術化的手段取代傳統的研發管理,讓技術管理者從與人打交道的繁瑣事務中解放出來,繼續與時俱進地鑽研技術問題。
當這些技術大牛, 只需要投入10-20%的精力進行管理工作,他們便依舊是組織中最懂技術、最懂業務、最忠誠又最具有創造力的寶貴資源。 有這樣一群核心骨幹的加持,企業要尋找自己的“第二曲線”,也就容易多了。
方雲智慧:
參考資料
1、MBA智庫百科_彼得原理。
2、維基百科_帕金森定理。
3、Gary Hamel, “Bureaucracy Must Die.” Harvard Business Review, November 04, 2014.
4、Susie Gharib, “This CEO Believes That Innovation and Culture Are One and the Same.” Fortune, February 15, 2018.
文丨瑞祺
責編丨babayage
題圖源自Pexels,基於CC0協議
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70015357/viewspace-2884990/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 帶研發團隊後的日常思考1 初級管理者的困惑
- 產品團隊管理 - 統一研發環境,提效研發過程
- 天天加班,為什麼團隊研發效能還是那麼低?
- 20人研發團隊的管理與發展規劃概要
- 產品研發管理和研發專案管理的區別是什麼專案管理
- 小團隊產品研發管理V0.0.1
- 研發過程中的文件管理與工具
- 如何解決百人研發團隊的管理問題?
- Go工程管理 20 | 協作開發:模組化管理為什麼能夠提升研發效能?Go
- 管理:為什麼不能用工時來考核研發的工作
- 精益六西格瑪,研發團隊提質增效的管理神器
- 研發團隊溝通困難 誰的問題?
- 如何定義研發KPI:以團隊速度為標準KPI
- 卓越研發之路 MOT技術管理者課堂
- 如何用研發效能搞垮一個團隊
- 為什麼華為研發這麼看重FMEA分析?
- 關於研發效能提升的思考
- 軟體研發之道:微軟開發團隊的經驗法則微軟
- 為什麼雷軍說“華為不懂研發”?
- 忙到飛起卻進展緩慢?聊聊小團隊提升遊戲研發效率的方法遊戲
- 技術團隊:研發中的短跑衝刺和馬拉松遊戲遊戲
- 研發團隊資源成本優化實踐優化
- 如何使用Git提高研發團隊工作效率?Git
- 研發團隊是該制定OKR還是KPI?OKRKPI
- 聊一聊在阿里做了 8 年研發後,我對打造大型工程研發團隊的再思考阿里
- 當自研自發成為另一種出海的標配,作為小團隊如何從零到一組建發行團隊?
- 研發團隊管理:IT研發中專案和產品原來區別那麼大,專案級的專案是專案,產品級的專案是產品!!!
- 張馳諮詢:為什麼要做研發也要做精益管理?
- 提升團隊工程交付能力,從“看見”工程活動和研發模式開始模式
- 對話巨杉核心研發團隊:分散式資料庫自研之路分散式資料庫
- 管理者權力的探討:資深團隊管理者的視角
- 從恰如其分的架構到研發團隊建設架構
- 研發團隊資源成本最佳化實踐
- 李彥宏:百度的研發佔比常年在20%以上
- 選擇合適的專案管理系統來支援專業產品研發團隊專案管理
- 團隊管理者最重要的是做好計劃管理
- AI DevOps | ChatGPT 與研發效能、效率提升(中)AIdevChatGPT
- 研發管理流程 - 需求管理