集體提薪后,我的技術團隊還是散伙了……
最近有個粉絲問了一道大題:
小釵,我最近空降到一個小公司做技術負責人,感覺團隊士氣很低,同學們要么有力無處使,要么常規(guī)摸魚,這種一盤散沙的團隊該如何帶呢?
這道題我還真會!只不過這是一道大題,沒那么簡單,需要大家耐著性子讀完,這里先給出解題思路:
- 直面問題,分析成因;
- 目標確定,合理分解;
- 梯隊確定,獎善罰惡;
- 資源確定,糧草先行;
- 機制流程,抹平障礙。
接下來我們現(xiàn)身說法,依次分解。
一、直面問題,分析成因
1、頂層梳理
團隊為什么會一團散沙,首先要有自己的基本判斷,比如我們團隊的問題是:
1)團隊合并
去年有一次比較大的團隊合并,單就技術團隊算是150+120的合并規(guī)模,正常情況,這種合并效果都不會太好,加上互聯(lián)網(wǎng)寒冬,所以導致了第二個問題。
2)大規(guī)模裁員
后疫情時代,降本增效成了很多公司的主題,與多數(shù)公司一樣,我們進行了大規(guī)模的人員優(yōu)化,半年優(yōu)化量多達70%!
人員優(yōu)化倒是完成了,而服務規(guī)模卻未減少。單后端來說,當前103個服務無人維護;少數(shù)核心同學維護服務又超過70個,風險很大,卻又無可奈何。
3)人心浮動
幾輪人員優(yōu)化下來,剩下的同學不免人心惶惶,而這個時期負責人也難以打包票不會再發(fā)生,而且正常情況這時候應該有一波團隊激勵,但這次情況特殊,整個公司都鎖死了,于是糧草也不足……
人的問題盤點完,還要盤點事的問題。
4)雙技術棧
團隊合并導致的最大問題是兩套技術體系,特別是后端完全是兩個技術棧:Golang、Java,在后端整體人數(shù)受限的情況下,很難重用,直接導致戰(zhàn)斗力減半!
5)業(yè)務歷史債
至此常見的業(yè)務歷史債就不多贅述了,每個團隊都有,就看嚴重程度了。
6)總結
所以,雙技術棧加上幾波裁員情況下,30%團隊要維護原來100%的業(yè)務,還沒加薪,這個團隊士氣不低就奇怪了!
自己有了初步判斷后,還得收集一線同學的想法。
2、基層視角
收集一線信息的方法比較簡單,發(fā)一個調(diào)查問卷,再找?guī)讉€關鍵人聊天即可:
- 你覺得當前團隊最大的問題是什么;
- 你覺得產(chǎn)生這些問題的原因是什么;
- 你覺得該如何處理;
由此可以形成一個腦圖:
可以看到,一線同學看到的點跟我們的認知還是統(tǒng)一的:
- 激勵不足;
- 氛圍不好;
- 業(yè)務拉胯;
- 目標不清晰;
- ...
貌似這個比我們兩年前遇到的問題更糟糕了:
比較有意思的是,其中一些問題之前已經(jīng)解決,但是過一段時間后又回來了,所以這個過程總是循環(huán)往復啊,那么如何解決呢?
二、目標是什么:選題
這里的選題,就是把自己的疑惑,將業(yè)務中碰到的問題,整理成一些課題,將這些課題指派給團隊的“專家組”進行研討,找到答案形成方案,選題的重點有二:
- 找準問題;
- 問題切割;
工作中問題很多,不能眉毛胡子一把抓,要發(fā)現(xiàn)主要矛盾是什么,要有優(yōu)先級,所以一定要找準要解決的問題,集中資源解決;找準問題后要做問題切割,問題大了資源不足做不了,問題小了沒有效果。
思考選題時要卷入足夠的資源、足夠的意見,但不要被輕易帶偏,要有自己的堅持,自己的主見,選題能力就是戰(zhàn)略能力。
所以,現(xiàn)在有那么多問題,我們要先解決什么,后解決什么,光說不練假把式,一起來實操下吧!
1、糧草問題
俗話說得好,兵草未動,糧草先行,如果人心不穩(wěn),就算有明確的目標也沒人想做,所以第一步是穩(wěn)住人,眾所周知,穩(wěn)住人最好的辦法是給他錢或者幫他成長能賺更多錢。
前面說了,今年情況特殊,想要加錢是比較難的,但比較難并非不能實現(xiàn),只不過這種時候要站在公司角度思考問題:
- 我為什么要給你錢;
- 我應該給誰錢;
怎么證明這筆錢花得值;
公司事實上也不是一毛不拔的,畢竟還要維持運營,但公司需要識別誰是團隊可用之才,并且需要證據(jù)鏈,這種時候由于屁股問題,不能聽負責人的一面之詞了,所以我們需要準備證據(jù)鏈,做兩個事:
- 識別團隊人才;
- 證明人才的ROI;
如何做呢,有一個簡單的解法是,證明人才同等時間做的事情更多更好就行了,而高級程序員的效率相較初級程序員確實會高不少。
所以,我們這里第一個要實現(xiàn)的目標是:找出團隊不可或缺的20%,并證明他們優(yōu)秀,想辦法說服公司給予激勵。
第二個目標是幫他成長,那么對應的梯隊建設,上升通道以及人才運營機制需要重新設計并維護起來。
2、目標問題
糧草只能暫時解決人才焦慮問題,遠大的目標才能讓所有人走得更遠,關于目標問題有幾個點要注意:
- 技術團隊難以影響業(yè)務團隊目標,所以不要妄圖技術驅(qū)動業(yè)務;
- 現(xiàn)階段技術基建資源會很有限,所以不可能有太多資源投入技術基建;
- 新的目標要可達成、有成就感、并且技術說了可以算;
總而言之,要讓技術有尊嚴,最好能解決安全感問題,那么這只有一條路可以走:創(chuàng)造營收,甚至自己養(yǎng)活一部分自己!
如何做呢,這里有個“比較擺爛”的策略:
- 開展外包業(yè)務;
- 開展技術培訓業(yè)務;
也不要看到外包就難受,如果跟業(yè)務方撕逼的時候真的將自己當外包團隊,很多問題可以迎刃而解:別跟我扯犢子,什么排期我都行,只不過得加錢!并且,外公司都是這么給錢的!
這里有幾個點:
- 搞定老板,讓他同意;
- 真要外包,最多解決團隊10%的人力成本就行,有個證明就行,不用占比太多;
- 搞培訓的話,優(yōu)先抓大學生,有好的苗子可以留下培養(yǎng);
事實上把自己當外包團隊是個很妙的想法,團隊內(nèi)部的關注點都會逐漸轉(zhuǎn)移至:如何養(yǎng)活自己;團隊外部對于一些不認可的業(yè)務方,便可以堂而皇之的降低其需求優(yōu)先級了。
具體效果,等我試過后跟大家聊,這里有個一定要注意的點:不要把主業(yè)務搞崩了,注意尺度。
綜上,這里可以給團隊設定第三個目標:技術團隊承擔人力成本的10%!,具體賺的錢可以跟公司分賬,具體怎么分要聊。
但是為了保證生存,依舊要有保證核心業(yè)務的目標,不然就真做成外包團隊了...
3、成長問題
前面提了一下成長問題,但公司級的上升通道建設,職級體系還是得有,如果公司這塊不成熟,需要推動建設。
為什么職級體系很重要呢,因為升職一般伴隨著加薪,所有人都看著的呢,需要規(guī)定做了什么工作可以獲得什么成就。其實只要職級體系做得好,可以解決很大的問題。
團隊需要做的是將培訓和分享做起來,特別是針對Leader層的干訓班,具體怎么做后面有介紹。
綜上,第四、五個目標是將團隊的職級體系搭起來,其次要把內(nèi)部培訓分享搞起來。
4、環(huán)境問題
解決了主觀能動性和目標問題,接下來就要解決環(huán)境問題,要去實地考察當前環(huán)境中什么流程是多余的,什么是割裂的,多的流程要去掉,沒有的流程要補,所以第六個目標是:核心機制流程補足。
5、總結
最后總結一下,為了解決我們的問題,我們提出了以下目標:
- 找出團隊不可或缺的20%,并證明他們優(yōu)秀,想辦法說服公司給予激勵;
- 梯隊建設(職級體系+分享培訓體系);
- 技術團隊承擔人力成本的10%;
- 核心機制流程補足;
- 接下來依次說說每個目標的實現(xiàn)思路。
三、人才識別
第一步依舊是要想辦法要錢,這里第一個問題就是如何證明我優(yōu)秀,這里的實操思路是:統(tǒng)計每個人每周/月完成了多少任務,步驟是:
- 周會、項目日會等會上提出待完成的任務;
- 將任務分給不同的人;
- 任務完成后,進行簡單任務定級,存檔;
任務一般是一周以內(nèi)的工作,任務過大應該被設置為OKR,然后在OKR的基礎下再分解任務,所以一個周期結束,可以看到所有人完成的任務以及完成了什么樣的任務。
理想的情況下還可以對任務定價,那么一個人一個月賺了多少錢可以計算出來,最后任務賺來的錢/員工工資,ROI就出來了...
當你拿到所有人的所有任務,并可以細化到每個人的ROI去找老板聊天的時候,相信我,他首先會給你錢,其次會讓你把這套工具復用到整個公司。
衍生一下,如果以任務為單位的形式運行的好的話,是可以算出業(yè)務方的需求價值的,如果業(yè)務方的需求沒有外包的需求價值高,還可以反向PUA。
縈繞很久的效能度量問題,結果被市場經(jīng)濟運作下的外包模式解決了,我真的是醉了!
四、梯隊建設
這里的梯隊建設核心圍繞著上升通道(職級體系)與分享培訓體系展開。
上升通道首先必須拉著HR玩,讓他定義清楚當前部門的職級,并且每年什么時候達成什么條件可以升級,升級后的匹配獎勵是是什么,沒有這個東西,大家都只能抓瞎!
關于團隊成長還是首推三件事:
- CaseStudy;
- 干訓班培訓;
- 技術分享;
其中技術分享不多說,說下CS與干訓班:
1、CaseStudy
針對平時工作中爆發(fā)的工程或組織問題,需要責任人寫CS(CaseStudy)文檔,每周二下午,相關人一起做復盤的機制,旨在杜絕類似問題產(chǎn)生。
關于如何做CaseStudy的文章,之前復盤時候介紹了,這里不展開。
2、干訓班
一路打怪(做項目、OKR)升級,如果”運氣好“成為小leader,那么就進入了干訓班輻射范圍,干訓班事實上更多是面向經(jīng)理的”福利“,幫助經(jīng)理建立管理認知的培訓實踐課程,比如就會涉及以下信息:
- 跨部門溝通的訣竅,我為什么要配合你;
- 從理論到實戰(zhàn)的差距是什么;
- 如何用數(shù)據(jù)說話;
- 系統(tǒng)性解決問題,豎井效應與內(nèi)卷;
- ...
這些培訓一般由幾種元素構成(不是每個案例都會完整覆蓋):
事件案例 -> 案例分析 -> 觀點闡述 -> 理論、機制形成 -> 討論(辯論)
如果案例本身比較經(jīng)典,再進一步會考慮:
要不要納入團隊機制 -> HowTo -> OKR -> 執(zhí)行人 -> 形成團隊案例 -> ......
每個公司案例不盡相同,大家不可完全套用。
五、營收思路
技術話語權弱,也是一個長時間縈繞心間的問題,其實想要話語權只需要做兩件事:
帶來營收;
證明自己跟營收有絕對聯(lián)系;
之前我的想法是自己跨出圈子去做業(yè)務方,這樣就能帶來營收了,但是轉(zhuǎn)念一想,這個其實只能證明我能帶來營收,并不能證明技術團隊能帶來營收;而強行跟業(yè)務方拉關系,分他們的營收蛋糕,無異于低人一等,都不是好的解決方案。
但是,如果將自己作為外包團隊,在市場經(jīng)濟下,似乎情況又有所變化,我們只需要說服老板:我們可以自己養(yǎng)活自己。
接下來的操作就是,所有的業(yè)務方跟技術團隊提需求,我們先說好一個需求多少錢,你如果不滿意可以真的去找外包,這么一來的話,技術團隊其實是處于公司的外包團隊,我們可以選擇不接有些需求:對不起,你那個需求太爛了,錢也少,我們不做,你去找外包吧。
所以,我們是用自身的技術能力賺取服務費用,我們自己養(yǎng)活了自己,當然,不可避免可能會談崩幾次,導致賺錢的費用不足以覆蓋所有技術的人力成本,這個時候就只有兩個方案:
- 裁員;
- 接外包;
站起來肯定要付出一些代價,但越做越小肯定不是我們的初衷,所以真實的方案只有接外包一途,這里要注意:接外包不可太過。
外包帶來的營收不要超過團隊的10%,或者能夠保證不裁員就好,不要接太多,因為多少還是有點不務正業(yè)的,嘗到甜頭樂此不疲可能真的演變成外包團隊,那不會是團隊想要的。
至于如何接到外包,這個是個商務問題,大家自己去思考吧。
六、流程機制
大目標定了,如何讓目標執(zhí)行的更順暢,這就需要流程機制的匹配了,比如:業(yè)務團隊如何采買服務能力,如何定價,財務如何結算等等都需要有一套完整的流程,并且需要系統(tǒng)化!
也就是我們需要一套內(nèi)部管理工具來匹配這些目標,我這里的思路是:實現(xiàn)了一套以任務為核心的OKR系統(tǒng),具體系統(tǒng)如何,使用過后再拿出來分享吧。
結語
最后回到問題本身,如果當前團隊一團散沙,首先要思考錢的問題,沒錢的激勵人們很難有啟動的動力;
團隊初步啟動后要思考目標的問題,找準當前問題的核心,和當前環(huán)境最適合解決什么;
目標落定后要解決環(huán)境問題,匹配對應的流程機制,讓目標更容易發(fā)生,具體到目標實現(xiàn)的時候,一定要注意目標切割,先打造小案例,實現(xiàn)小目標,激勵大家的信心,一步一步,后續(xù)就會順暢很多。