深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!

MSUP發表於2019-04-29

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


導讀:阿里巴巴高階技術專家雲狄將為大家從管理的角度分享技術TL的核心職責,這其中包括團隊建設、團隊管理、團隊文化、溝通與輔導、招聘與解僱等,希望與大家共同探討、交流。


背景


網際網路公司的技術團隊管理通常分為2個方向:技術管理和團隊管理,網際網路公司的技術TL與傳統軟體公司的PM還是有很大的區別,傳統軟體公司的PM更多注重於對專案的管理包括專案任務拆解、專案進度以及風險等。對於多數網際網路公司而言,技術TL更多的職責不再侷限於專案角度,而是對業務與技術都要有深入的瞭解,就像黑夜裡的燈塔,能夠引導和修正團隊成員前進的航向。綜合技術和業務角度去深度思考問題,具備一定的前瞻性,並在技術領域投入持續的學習熱情,向團隊成員傳道,補齊短板,提高整個團隊的戰鬥力。


技術TL職責不僅需要制定日常規範,包括開發規範、流程規範等,推動規範的落地,以公有的強制約定來避免不必要的內耗,另外一多半的時間可能花在了開發任務分解分配、開發實踐、技術架構評審、程式碼稽核和風險識別上,剩餘的時間則花在為了保障系統按時交付所需的各種計劃、協作、溝通、管理上。


管理大師彼得·德魯克說:“組織的目的,就是讓平凡的人做出不平凡的事。”然而,不是任何一群平凡的人聚集到一起,都能做出不平凡的事。甚至一群優秀的人聚集到一起,也可能只是一個平庸的組織。大到一個國家,小到一個團隊,任何一個卓越的組織,都必須有一個卓越的領導者。領導者是一個組織的靈魂,領導者在很大程度上決定了組織所能達到的高度。


阿里有句土話“平凡人、非凡事”,技術團隊同樣如此,管理者的戰略眼光、管理方法、人格魅力等,都會給團隊的工作結果帶來決定性的影響。


其實每個公司、每個團隊的背景不太一樣,從管理學的角度探討一些問題,沒有統一標準的答案,本文中一些觀點僅是個人觀點,更多從我個人成長為技術TL一些觀點理念,同時我也是吸取了前輩們一些優秀的管理理念,包括我最為尊敬的通用電氣CEO傑克·韋爾奇、蘋果CEO賈伯斯、Intel CEO葛洛夫,國內我最推崇的技術管理者robbin(丁香園的技術副總裁)。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


團隊建設


從2014年開始帶這塊業務技術團隊,至今有5個年頭。回想起來,團隊管理中所有能遇上的問題都遇到過了,其中的磕磕絆絆數不勝數,完全是在實踐當中吸取教訓,團隊建設這塊在這裡和大家簡單分享一下,當然這裡面也有做得不夠好的地方。


在阿里每個人都能感受到擁抱變化,基本上每年組織架構都會調整,甚至有些團隊每半年都會調整一次。14年我也算是被分配到這個團隊負責這塊業務,這塊業務是集團收購一家子公司的業務,整個團隊文化和技術體系與阿里有很大的差異化。一般來說新官上任三把火,新的技術TL空降之後往往會大肆招人,快速推進改革,而且有些技術TL喜歡把原來的一些舊將搬進來。


當時我沒有急於這麼去做,沒有招過一個新員工,而是立足於穩定現有的團隊,主要基於以下原因:


  • 團隊和業務瞭解不夠深:對於目前的團隊的人員以及業務,我不夠了解,不清楚這裡面有哪些坑和陷阱,一旦初戰不利,領導的信任度被透支,在公司恐怕難有立足之地,更不用談論改造團隊,發揮自己的才能了。


  • 流程與制度:針對團隊現狀存在的一些問題,我初步判斷並不是人的問題,很多問題是一些組織、流程、制度上的問題。我認為只有好的制度才能造就好的團隊,在沒有解決現有團隊的痼疾之前招聘新人,不但不會帶來新的生產力,反而會造成團隊的混亂,應該先打下一個好的根基,再招人,才能事半功倍。


  • 團隊安全感:不想讓團隊現有的成員感覺一朝天子一朝臣,擔心自己在團隊中會被邊緣化,成為棄兒。另外一方面能夠讓現有團隊心理比較安全,可以安心地好好工作,不至於發生更多的動盪。


經過了幾個月的摸底瞭解,大概清楚當時團隊存在的一些問題和原因:


  • 業務配合不規範:產品、運營、研發部門之間配合沒有建立合理的工作流程,比如對於產品需求的PRD評審沒有標準,對於運營需求沒有量化指標,大家都是疲於奔命做需求,導致大家的積極性不夠高。


  • 跨團隊協作混亂:跨部門之間的工作配合毫無規範可言,部門之間相互推諉,隨便什麼業務人員都會隨時給研發人員下命令,長此以往,傷害了研發團隊的積極性。


針對以上問題,我主要把協作流程規範梳理了一番,制定了相對合理、規範的產品合作流程,同產品同學約法三章,明確了PRD輸出的標準和規範,運營的業務需求也統一由產品輸出,杜絕一句話需求。同產品、前端、UED、QA團隊的協作統一標準流程,下游對上游依賴方輸出的工作必須有明確的標準規範,口頭說的統統無效,拒絕合作。


針對跨團隊協作亂的情況,我特別想說明一下,由於研發部門不是直接創造收入的業務部門,而是承擔業務部門的服務者角色。作為一個服務者,往往站在一個被動和弱勢的位置上,很容易被業務人員舉著收入的大棒指揮你無條件的服從。業務部門人員隨便指派任務,隨意變更需求,團隊同學無所適從。這樣一來,部門內部無論怎樣合理的計劃都會被外部的力量輕易打破,讓團隊同學無所適從,導致大家的工作積極性不高,喜歡互相推卸責任。久而久之,員工就產生了自我保護意識,凡工作儘量往後退,凡責任儘量往別處推,不求有功但求無過。


為打破員工養成的這種自我封閉的保護意識,鼓勵員工更加積極主動做事情,我能夠做的就是把這些責任都扛在自己身上,親自去協調每項工作,讓團隊成員沒有後顧之憂,讓團隊同學相信我可以搞定他們擔心的事情,出了任何問題我可以來背鍋,給自己的團隊創造一個相對寬鬆和自由的工作空間,保護團隊不被外部的各種雜事傷害到。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


團隊管理


人往往會高估自己而低估別人,很多管理者都會覺得手下交上來的工作做得不夠完美,這裡考慮不周那裡做的囉嗦,但很多時候你只是看到了他人不擅長的地方,或者只是對方和你的出發點不同給出了不同的解決方案而已。很多時候,我們並不如自己想象的那麼強。管理者在充分理解一些管理的理念之後,不斷地在實際的管理工作中去實踐並收集反饋和迭代,這樣才能夠形成自己的管理風格,並找到最適合當前團隊的管理方法。


作為一個團隊的管理者,通常會有兩種風格管理策略,簡要概括為集權式的管理風格、放權式的管理風格。


  • 集權式管理:管理者的風格是偏細節的,定義清晰的工作目標,並且把工作目標分解得非常細緻,讓手下的團隊能按照整個計劃步步為營往前推進,這是一種風格,相對來講比較集權。


可以說我帶這個團隊的第一年是這種風格,我甚至會參加每一次需求評審,無論需求大小,會和研發同學一起去寫程式碼,對研發團隊我會做詳細的code review,親自帶領研發團隊做技術交流和分享,參與技術討論確認架構方案,這樣以來和大家建立起了充分的信任。


為了支援日益複雜的業務,Netflix一直都發力基礎設施。現在Netflix擁有分佈在190多個國家的1億使用者。早期公司的伺服器執行在自己機房,但這會造成單點故障和其他問題。在2008年8月,資料庫的問題導致了三天當機,在此期間在Netflix無法看任何視訊。Netflix工程師在2011年將服務遷移到Amazon Web Services。


  • 放權式管理:定義大的目標,把握大的方向,做關鍵性的決策。但是並不深入每個細節去管控手下團隊的執行細節,以結果為導向。


我到這個團隊一年後,業務流程已經清晰的建立起來了,骨幹員工在業務上能夠完全領會並且達到我的要求,這個時候放權可以充分調動團隊的自主性和創造性,多數技術人員他們喜歡被領導,不喜歡被管理。


以上這兩類管理風格沒有對錯之分,究竟哪種方式更適合完全取決於團隊的狀況。其實這裡我更想說一下關於放權式的管理風格,對於一個制度剛剛建立,流程還沒有跑順暢,團隊殘缺,骨幹員工業務能力不及格的團隊,採用放權式管理是錯誤的。你必須事無鉅細,從第一線的業務細節抓起,手把手的帶員工,教會他們怎麼正確的做事情,怎樣達到你的要求,手把手的培養業務骨幹,搭建團隊核心架構。


這些年我看到過太多的案例,管理層自己從不真正深入業務,也缺乏對業務的深刻理解,沒有找到問題的本質原因。總是寄希望於招人來解決問題,結果換了一茬又一茬人,問題永遠解決不了,而且從來不深刻反思自己是否親自嘗試解決業務問題。很多時候架構反應出來的問題,其實是組織、流程的問題。總之,作為管理層,如果自己沒有深入一線去發現問題,自己動手去解決問題的決心和勇氣的話,那這個團隊很難有新的突破和成功。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


團隊文化


在我剛參加工作的前幾年,就聽過一些關於團隊文化和企業文化的一些概念,並沒有特別深刻的印象。尤其我讀了《基業長青》這本書後,讓我感受到對於一個企業而言,決定短期的是技巧,決定中期的是戰略,決定長期的是文化。企業文化對一家公司來說真的很重要,同樣團隊文化對於一個團隊來說也很重要,我在帶團隊之初也曾經忽視了團隊文化的衝擊。


在帶領這個團隊之初,我私下找一些團隊同學做1on1溝通,我發現這裡面的問題還是比較嚴重的,很多人為了避免故障遭受懲罰,不敢去重構優化程式碼,把自己封閉到一個很小的圈子,也沒有過多的追求和理想,以前也沒有末位淘汰機制,大家覺得可以繼續吃大鍋飯。當時部門都是工作多年的老人,老的風氣和習慣已經形成了很頑固的不良文化,工作情緒受到很大的影響。


老的不良的文化包括:


  • 做事情沒有積極性;

  • 永遠不承認自己的錯誤,永遠找藉口推卸責任,永遠都是別人的問題;

  • 不求有功但求無過;責任心差,對待工作自我要求低;

  • 對工作安排喜歡討價還價;


在一個不好的文化氛圍下,優秀的員工會被排擠,團隊沒有向心力,也很難留住好的人才,員工流失率會非常高。我認為衡量一個團隊文化氛圍是否有吸引力,有一個很重要的指標,新員工的流失率:如果一個團隊氛圍非常好,新員工入職以後往往能夠快速融入進來,流失率很低;如果團隊氛圍差,新員工入職以後比較茫然難以融入,往往會很快離職,流失率非常高,實際上留不住新員工遠遠比留不住老員工更可怕。


接下來我希望給團隊樹立的文化是:


1、坦誠,公開,透明;

2、平等相處,消除等級感;

3、工作氣氛輕鬆,團隊關係和諧;

4、敢於擔當,主動承擔責任;

5、成就他人,樂於分享。


關於團隊文化這個話題其實很泛,可以單獨寫一篇文章出來的。這裡我主要基於團隊文化以上幾點,談一下我的一些個人的看法。


坦誠的力量


首先,我覺得坦誠無論對於一個 TL 還是團隊成員來說,坦誠也是一種價值觀,對於一個團隊的發展來說是非常重要的。作為一個 TL,帶領一支團隊,我覺得最重要的是 TL 本人必須做到坦誠的態度,只有對團隊坦誠,才能和團隊之間形成信任,只有和團隊形成了信任,才能成為一支默契的團隊。


通用電氣 CEO 傑克·韋爾奇說過:什麼是信任?當一個領導真誠、坦率、言出必行的時候,信任就出現了,事情就是這麼簡單。為什麼坦誠精神能行得通?很簡單,因為坦誠有化繁為簡的力量!


坦誠的性格是管理者最基本的要求,只有管理者坦誠,才能獲得團隊的信任,作秀式的演講和獎勵並不能夠真正獲得團隊的心,還是需要在工作中腳踏實地一點一滴去做好最平凡普通的事情。坦誠能夠讓你直面自身的缺陷,有針對性地改變自己,解決團隊的問題,造就一個互相信任的團隊氛圍。


我見過一個比較典型的案例,日常工作中主管對於下屬不夠坦誠,下屬與主管的平時一些工作溝通中,下屬做的不夠好的地方,主管不及時進行溝通與輔導,結果最後KPI 考核被打了低績效。換位思考一下,這個被打低績效的人是我,我也會不服氣,有問題你為啥不提前告訴我,讓我提前去改正。對待下屬要有勇氣,敢於指出他們的問題,對於表現不好的員工要敢於批評和管理,例如為什麼解僱你。這些談話和衝突往往讓人感到不舒服,我也承認每次談低績效是硬著頭皮的,但是你必須有這樣的勇氣,坦誠不僅僅要對那些表現良好的人,還要對那些表現糟糕的人。


蘋果創始人賈伯斯是一個對自己、對別人坦誠得可怕的人,坦誠的殘酷,直面事情最真實的一面。的確坦誠的態度在很多時候會讓別人感覺不舒服,賈伯斯粗暴的坦誠態度也備受爭議,但我覺得,如果你是一個結果導向的人,還是應該儘量堅持坦誠的態度,否則最終的結果可能遠遠偏離你的目標。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


允許你的下屬challenge你


其次,我再聊一下關於平等相處,消除等級感,這點我覺得最重要的讓大家感受到你的親和力,不是一個高高在上的領導。比如很多時候團隊一些技術方案的決策不是你一個人來決定,有時候還是要善於傾聽一下團隊成員的意見,要允許團隊成員challenge你。


其實,國內外要求下屬服從的企業文化很普遍,這不一定是壞事,特別是公司如果有想法的人太多,想法又無法統一起來,公司的整體戰略呈現精神分裂狀態,那基本上就離死不遠了。所以管理層統一公司戰略,一線員工強調使命必達。


國內的外企格外強調下屬的服從性,把這一點作為員工的基本職業素養來培訓,常用來講解的故事就是《把信送給加西亞》,強調上司安排一項工作以後,下屬不允許談任何條件,不允許challenge上司,必須無條件服從,克服一切困難也要完成工作任務,以解領導之憂。這種執行力讓上司感覺很舒服,而且公司管理實施難度也比較低。


多數管理者都喜歡比較聽話的下屬,認為順從的下屬更好用。心態上高人一等,不會放低心態傾聽下屬的意見,即使自己錯了也不會承認錯誤,一方面害怕自己的權威被挑戰,另外害怕向下屬認錯,覺得抹不開面子。我不是聖人,作為TL曾經也犯過一些錯誤,我也曾私下裡和個別同學道過謙。放開心態,不需要過多的太在意別人的看法,這些我覺得都是無所謂的小事。


從我個人自身的一些經歷來看,其實一味地要求下屬服從是有害的,要適當允許你的下屬challenge你。


如果一味地要求下屬服從,不能進行任何反駁,長時間下來會導致團隊的人缺乏思考,只是一味的按照 TL 的想法去執行,當下屬內心並不認可工作本身,僅僅出於職業性完成工作,成績最多是合格,很難達到卓越。同時會導致下屬缺乏工作積極性主動性,容易養成下屬逃避責任的習慣。


相反我覺得作為 TL 一定要鼓勵下屬積極主動地思考,讓下屬能夠自己設定成長目標,對工作擁有歸屬感和責任感;儘量給予下屬更自由的空間,不要設定過多形式主義的約束;要允許下屬去challenge你,參與你的決策,甚至質疑你的決策。用這種方式增加下屬對工作的歸屬感,工作責任心更強,更積極主動,能夠自我驅動。


當你的決策錯誤的時候,下屬可以幫你糾錯,集體的智慧畢竟高於個人,俗話說“三個臭皮匠賽過諸葛亮”。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


owner 意識


“Owner 意識”主要體現在兩個層面:一是認真負責的態度,二是積極主動的精神。認真負責是工作的底線,積極主動是“Owner 意識”更高一級的要求。


自私確實是人的天性,不是自己的東西,很難談什麼責任感,更不用說主動性了。因此,團隊管理就是要努力地培養大家的責任感,主人翁意識,想做到這一點,就需要增強團隊成員的參與感,讓他們知曉並理解所做事情的價值、來龍去脈,不斷地強化使命感。


例如可以將系統、業務範圍等根據團隊成員的興趣點、以往專案經歷等多種因素劃分給指定人負責,並明確賞罰機制。要清晰地傳達一種思想,那就是:這塊東西就是你的,幹好了評優、升職、加薪等都會優先考慮;幹不好,出事情了,你要負責,我也會負責。如果有一天你看到團隊成員像呵護自己的孩子一樣,去對待自己的工作,那麼你的目的已經達到了,他已經完全具備 owner 意識了。


建立學習型的組織


最後一點我要談的是建立學習型的組織,團隊成員要儘可能地分享自己的知識和想法,大家互相學習,也通過分享能夠總結自己學習過程中零散的知識點。如何建立人才梯隊的,其實就是要建立學習型組織,讓大家積極參與學習與分享。具體做法KPI裡設定一項技術分享與團隊貢獻,團隊內部輪流進行技術分享,一方面讓大家去學習、研究一些前沿技術,尤其是團隊可能會用到的一些技術儲備,如果他真的能把這個技術給大家講明白的話,那他就是真的掌握了,同時也讓其他人開始瞭解並學習這項技術,同時還能夠鍛鍊其演講與口才。


鼓勵團隊成員敢於去分享,樂於去分享,開放心態成就他人。把技術培訓和分享堅持下去,形成這樣一種學習型的文化以後,你就會發現整個研發團隊的技術能力的提升速度是非常驚人的,並且不會再佔用太多額外的時間。當你再招一個資歷較淺的新員工時,他也在能在這種環境中快速提升,通常半年左右時間就能達到非常好的水平。


當然,一開始的團隊可能沒有這樣的意識,就需要你作為管理者強行去推動,把要求列入KPI,很認真地考核他,慢慢地,團隊就會形成這樣的氛圍和文化。當然建立這種學習型的組織,也可以建立一些讀書分享會,把讀的一些書籍感受分享給大家,另外一點團隊的wiki知識庫一定要建立起來,讓團隊同學把一些日常的技術方案、專案總結、故障總結通過文件的形勢積累起來。


溝通與輔導


根據美國普林斯頓大學的調查報告,在所有對工作產生影響的因素中,溝通佔的比例高達 75%。而我們工作中出現的80%問題都是由溝通不當造成的,可見溝通的重要性。多數時候,我們只想著表達自己的觀點,只關注自己想說什麼,我們會盡量使用漂亮的PPT、華美的語言、一堆的資料、甚至引章據典,而不關心別人聽懂沒有,沒有思考別人是否想聽,別人是否聽得懂。


溝通在我們的工作中無處不在,你會發現尤其在技術這個圈子裡,能夠進行高效溝通的人佔比會更少一些。溝通按照溝通物件型別通常分為向下溝通(同下屬溝通)、橫向溝通(跨團隊溝通)、向上溝通(同老闆溝通),接下來只討論如何同下屬進行溝通,最為有效溝通方式:一對一溝通。


一對一溝通,又被稱作一對一會議、One-on-one 等,是網際網路公司常用的溝通方式。一對一溝通雖然被廣泛使用,但是涉及的文章卻很少,這裡我給大家推薦本書《葛洛夫給經理人的第一課》、《創業維艱 : 如何完成比難更難的事》,這兩本書有更多關於一對一溝通介紹。葛洛夫是 Intel 公司的總裁,成功帶領 Intel 公司完成了從半導體儲存器到微處理器的轉型,也是我非常欣賞的一位CEO。《創業維艱》的作者本·霍洛維茨是矽谷的頂級VC,投資了Facebook、Twitter等公司。


在《葛洛夫給經理人的第一課》一書中,葛洛夫對「一對一溝通」的介紹如下:


在英特爾,一對一會議通常是由經理人召集他的部屬召開的,這也是維繫雙方從屬關係最主要的方法。一對一會議主要的目的在於互通訊息以及彼此學習。經過對特定事項的討論,上司可以將其技能以及經驗傳授給下屬,並同時建議他切入問題的方式;而下屬也能對工作中碰到的問題進行彙報。


在我看來,技術研發同學多數比較內向,不輕易向別人表達自己內心的一些想法。一對一溝通的意義是可以使得資訊從下而上地傳遞,同時可以把一些疑問、想法、意見、問題、規劃等等和管理者做溝通,從而獲得在其它渠道不易獲得的資訊,保證透明。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


1on1溝通聊什麼


在《創業維艱:如何完成比難更難的事》這本書中專門拿出了一節提到了一對一溝通(1on1),具體聊那些內容給了一些建議,作為TL我通常會與團隊的人聊以下話題:


1、你有沒有認為自己的價值和能力被低估了嗎?為什麼?

2、你覺得在工作中能學到東西嗎?你最近學到了什麼?你還希望在哪些領域進行學習?

3、近期這段時間,對自己有哪些滿意、不滿意的地方?

4、目前工作中,有哪些困惑?希望我如何去幫助你?

5、對團隊和我的一些期待和建議。

6、在公司戰略和目標方面,你最不清楚的是什麼?


以上這些內容,除了在一對一溝通中交流之外,很難找到別的渠道來有效解決。通過這些1on1的溝通,真的可以得到很多反饋資訊,甚至得到的一些資訊令我感到吃驚,原來還有這些細節問題我沒有做好。一對一溝通構造了一個渠道,這個渠道自下而上,使得以上這些內容都能夠被傾聽,從而被解決。


1on1溝通的一些注意點


★ 找個私密的環境


找個空會議室或者別人聽不到談話的角落,不要在工位或嘈雜的環境中進行,因為私密的環境才能降低溝通中某些話被他人聽到的心理壓力,才能更輕鬆和真實的表達自己。


★ 最好提前告知1on1的團隊成員


一般需要提前1周把1on1溝通的話題、具體時間通知到團隊成員,這樣的好處是團隊成員可以提前準備下聊的內容,因為臨時性的溝通很容易出現因為人類記憶力的問題,導致一些想聊的問題在當時沒想到。


★ 定期進行


在《創業維艱》一書中,本·霍洛維茨認為一對一溝通需要保證至少一個月一次。而葛洛夫認為,需要根據部屬對工作的熟悉度,而進行不同程度的掌控。


另外,葛洛夫還認為,事情變化的速度也是影響一對一溝通頻率的因素。作為技術研發部門,我通常會1-2月進行一次1on1溝通。


★ 用心傾聽並行動


溝通要有效,用心傾聽、保持真誠是必要的前提,否則員工不可能將心中的問題提出來。


保持真誠需要不敷衍任何團隊同學提出的問題,不管這個問題有多尖銳。如果你也不知道如何解決這個問題,不妨和團隊同學一起討論討論,看看大家能不能一起尋找可行的辦法。切忌不要講空話和套話,一旦團隊同學發現這是一個無效的溝通渠道之後,「自下而上」的通道就被關閉了。


★ 適當引導


並不是每一個員工都懂得一對一溝通的重要性,也不是每一個員工都能主動傾述問題,尋求幫助。很多程式設計師的性格都是比較內向的,有一些甚至不善於表達自己。


所以,雖然員工是一對一溝通的「主角」,但是上司也是需要進行適當的引導。對於上司已經發現的員工工作中的困難,可以適當的主動提出來,以便於更好地討論,這也會讓員工感到很體貼。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


招聘與解僱


對於一個團隊來說,人才是最核心、關鍵的。招聘和解僱尤其對於一個新上任的技術TL,都是一個很大的挑戰,接下來我們重點討論這兩個話題。


招聘


招聘很多時候取決於公司在什麼發展時期,需要招聘什麼樣的人。在初創時期,本不太可能招聘到清一色的專家人才,這個時候活下來比啥都重要,態度和味道是重點看的。在高速發展之後,可能需要引進能帶來新思路的一些人才,這取決於業務、技術、組織三者的對齊。那麼這個時候,就是既要高技能,又要好的做事態度、習慣。


在搭建技術團隊招聘前,要先明確所搭團隊的型別,一般來說有三種不同型別的技術團隊,即專案驅動型、業務驅動型和技術驅動型,不同型別的技術團隊在招聘時也有很大的不同,比如技術驅動型團隊你可能需要一個在中介軟體、語言功底非常深厚、有大局觀的人,業務驅動型的團隊可能需要有業務sense,並且具備良好技術和業務架構能力的人。


在招聘這條路上,我也走過彎路,一開始我對候選人的背景、語言功底、架構能力以及運維、資料庫方面比較關注,希望能招到全棧的技術人才,後來發現我忽視了一個很重要的點溝通與協作能力、態度。後來導致新人來到團隊後,雖然技術牛B,但喜歡閉門造車,不喜歡和別人溝通,團隊協作能力不夠好,整體產出和效率不高。所以在招聘新人的過程中,不能夠只盯著候選人有什麼經驗,會什麼框架等技術面,也需要著重考量他們的綜合素質,一個領導力好的候選人,能夠非常快速地融入團隊,也能夠非常快的學習一些知識。


★ 招聘步驟:


1、根據搭建團隊的目標,做好招聘計劃

根據團隊自身的定位,招聘合適的人才。有幾點需要TL特別關注的,作為TL要對候選人的成長負責,切忌因人設崗、因單獨專案而招人,比如前端團隊招聘一些後端開發,工程團隊招聘演算法,這樣以來可能會導致候選人進來後很難融入到團隊,沒有存在感,長時間下來會導致新人離職。


2、確定招聘需求(定崗定責):列出每個崗位的職責、需要具備的技能及其他要求。

招聘需求歸根結底是需要什麼樣的人,與據整體業務和組織發展匹配。


3、合理利用人才招聘渠道

從我自身的經歷來看,人才招聘渠道多數通過網際網路招聘渠道以及朋友推薦更可靠一些,對於高階別的人才可以採用獵頭定向挖人。

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


★ 人才篩選:


作為技術面試官,對於人才的篩選也是非常重要關鍵的一個環節,要根據自己團隊的目標來選取合適的人才,設定完成的時間期限,將面試的重點放在專業技能、管理能力、價值觀(公司認同)等方面,一般要求如下:


1、和崗位需要的專業技能高度匹配:專業技術技能面試過關,定崗定責;

2、溝通力強:理解公司的業務,知曉管理層,瞭解公司的發展方向;

3、責任心:凡事有交代,件件有著落,事事有迴音;

靠譜並自帶正能量:不抱怨,主動解決問題,懂得紀律的重要性,一諾千金;

4、價值觀認同:認同公司,有目標有理想、有激情有衝勁;

5、背景調查:非常有用的一個辦法,可以大幅度降低選人風險,不用怕麻煩,這個工作的付出永遠都是值得的。


另外,我想說的對於技術面試官需要有一定甄別人才的能力,同時有意識地提高這方面的能力,我提供以下幾點建議給技術面試官:


1、如果對候選人有些猶豫和糾結,請你放棄這個候選人,你最擔心的問題往往很大概率上會發生。

2、明確我們招聘的候選人標準,比如後端JAVA研發:JAVA基礎和分散式領域知識技能考察是必須的,少問記憶性問題和太理論性問題,更多地從候選人的一些實踐經歷中,提取出對這個候選人的更有價值的判斷。

3、一面非常重要,要保證客觀、公平,後面的交叉和終面往往參考前面的評價反饋,我們今天不僅是為我們的團隊選拔人才,更是為公司選拔人才,還是要高標準的要求。從心理學角度講,必須要交叉面試,而且交叉面試官的給出的反饋往往是比較客觀、中肯的,而且要以交叉面試官的評價為主。

4、面試官切忌拿自己擅長的東西去考察候選人,需要認真的看候選人的簡歷,從候選人的經歷中去考察這個人的綜合能力。


一個團隊的健康發展,最重要的是核心技術人,所以招聘工作必須謹慎,一旦有人加入就等於在上了一艘船,其中的糾結、痛苦、歡喜都要一起面對。招募一個不合適人員的成本不僅僅是薪資那麼簡單。所以請一定要放過那些經驗不錯、資質不錯但是很猶豫匹配度、落地融入堪憂的面試者,其結局大部分都是彼此痛苦。


作為技術TL最成功的是招到比你更優秀的人,你不需要擔心自己會不會被取代,一是成就個人和成就團隊,作為TL應該抱著如何成就團隊的發展思路,不能讓自己成為天花板,本身技術就不應該是你最擅長的事情!二是相容幷蓄,發展多樣性。劉邦善用漢初三傑,單項能力不如韓信、張良。TL不要已自己的長短來衡量招聘的人,而是看團隊技能檢視的缺口和發展項。


解僱


解僱員工通常更多的是針對觸犯公司文化、原則紅線,或者持續無法跟上公司節奏的員工進行的處理。在阿里也有這麼一句土話:“如果你沒有開除或解僱過一位員工,算不上真正合格的管理者”,大多數技術管理者性格比較隨和,不喜歡開除員工。


但是出現觸犯紅線的員工或者跟不上節奏的員工,尤其是不認可團隊價值觀的同學,會把一些負面情緒、行為影響到團隊其他同學,因此需要殺伐決斷,當機立斷採用合適的方法讓員工離開。當然,如果只是能力跟不上的員工,你也可以推薦給其他公司適合的崗位,讓和自己一起奮戰過的兄弟有一個好歸宿,也會讓在職的員工會感覺溫暖。整體上“慈不掌兵”,在開人這件事情上,高階管理者不要過於猶豫,為了一兩個人最後影響整體團隊的士氣反而得不償失。


多數網際網路公司對於技術人員都有相應的KPI考核,對於達不到預期的人員會進行淘汰。解僱尤其對於新上任的技術主管還是有一定挑戰的,我相信人的本性還是善良的,作為技術TL不想讓團隊成員面對這一難題,包括我自己在內。


一家公司在成長,組織肯定要升級,人員的新老交替也是正常的。如果團隊成員的表現達不到預期,不通過 KPI 考核機制告訴他,也許他不會意識到自身的一些問題,他永遠不會成長起來,相對短期這些經濟回報而言,個人的成長更為關鍵重要。在阿里有這麼一句土話“不經歷3.25的人生,不是完美的阿里之旅”,當你處於發展的低谷時,經歷一次末位考核結果也許能夠讓他徹底清醒,認識到自己的不足,徹底激發自己的潛能,能夠觸底反彈。


心理學上有個著名的鄧寧-克魯格效應,又稱達克效應。大意是,人很容易對自我產生認知偏差,最簡單來說,就是會過於高估自己。達克效應的曲線圖:

深度好文 | 在阿里做了5年技術Leader,我總結出了這些套路!


上面的圖片上反映出,大部分人其實都處於愚昧之巔。人能夠成長為智者和大師要先從愚昧之巔,掉到絕望之谷,然後辛苦攀爬,積累知識和經驗,成為智者和大師。有擔當的管理者的一個重要責任,就是把下屬從愚昧之巔推向絕望之谷,至於能否爬上開悟之坡,看個人造化。


一個合格的技術TL必須要給團隊成員塑造一個絕望山谷,同時還要讓他看到一個開悟之坡,這樣員工會不斷突破自我。作為一個有擔當的管理者,我們不應該是一個老好人的角色,也要有冷酷無情的一面,阿里也有一句土話“心要仁慈,刀要快”,當團隊中出現一些達不到團隊要求的人,管理者應該主動去拉他一把,如果多次嘗試,最終達不到預期,應該請他離開。因為到了中途,再被殘酷淘汰,無論對組織,還是對個人,損失都更大。


每一位開發者眼中,都有自己理想中的技術管理者。你認為優秀的技術TL身上有哪些特質?歡迎在留言區討論,與大家分享交流。




相關文章