iT邦幫忙

2021 iThome 鐵人賽

DAY 28
0
IT管理

邁向Tech Leader的成長之路系列 第 28

27. Tech leader的重要戰略

前言

這篇的講者很nice,直接講了這篇演講很適合給這幾種人看

  1. 剛成為TL
  2. 還不是TL但你覺得你會成為TL
  3. 已經是TL但想變更好

總之就是給tech leader看的一篇演講XDD。

演講總結

這篇顧名思義就是在講tech leader的一些戰略。

就像我說的(絕對不是偷打廣告,歐飛),tech leader是個很模糊的詞。我們通常定義為此:

項目裡技術願景的擁有者,與項目團隊裡的技術領導人。

有時候我們會把項目經理(Project manager,PJ)與TL搞混,PJ其實著重的是GTD(Get Things Done)而不考慮技術細節,但TL卻要在意這些事情。

但講來講去,TL在不同的公司與地方還是有著不同的意思,與不同的工作。所以如果是這樣,豈不是沒有一套規則要怎麼當TL呢?其實也沒那麼悲觀,因為大家的共同目標都是一樣:「與團隊一起創造好的軟體」。根據這樣的目標,我們可以簡單討論TL的幾個重要的工作:

一、協調(facilitate)

也就是幫team完成應該做的事情。身為TL,你永遠要想著「下一步」。

幫助團隊移除路障(roadblock)是最最基本的。但是你更該練習的是,先預測未來的路障並且先消除它。後面這件事更重要是因為

  • 可以讓團隊成員感受到inclusion。
  • 可以減少未來處理事情的不確定性。
  • 可以練習你的前瞻性。
  • 可以練習你的同理心。

而要成為好的facilitator,你要把計畫事情,並把事情切小切細,所以你就可以更好評估什麼時候會發生什麼事。

這裡講者講到,雖然大家都很不喜歡工作時打斷,但身為TL,你的工作就是要被打斷,因為團隊隨時會需要你的幫忙。當然你未必要知道所有的事情,但你必須要知道「要如何找到答案」。

二、主張(advocate)

(其實我沒有很懂這詞的精華)身為TL,你必須要知道哪些是重要哪些是不重要,所以你不能全然接受別人叫你做的事情。你要練習跟其他人說No,並且給出好的理由為什麼是No。有時候別人不理解context,那你要跟他們解釋背景;有時候是別人沒看到某些事,所以你要先想到可能會造成的問題。

而要成為好的advocater,你要把事情寫下來,留存的紀錄便可以確認大家理解相同,也避免其他人未來偷偷改變心意。

這裡有講到工程師是個很喜歡做對的事情的生物,而大家常常犯的一個錯是過度工程(over-engineering)。

大家喜歡寫可重用的code,但沒人喜歡重用別人寫的code。

身為TL你必須要有sense每個項目的scope在哪裡,然後讓大家聚焦投資時間在重要的事情上面。

三、驅使(motivate)

雖然很不想承認,不過TL無論如何都是一種管理。而既然是管理,最重要的關鍵就是leader的態度。如果你每天各種抱怨,對各種事情都很悲觀,新不在team上,那大家也會備受影響。

而當你身為TL想要大家做事情時,你會需要的能力就是讓大家有動機做你想要他們做的事情。關於動機,大多時候我們會想到的都是用外部的方式給於他人動機,例如給更多錢、請客、更多福利等等,但研究指出這些外部動機通常不夠強烈也無法持久,更重要的是想辦法讓他們發自內心去感受到被感召,這也是最難的部份。

講者說有一個技巧叫 passive-aggressive white-boarding(sorry我完全不知道該怎麼翻譯這個= =),意思就是說,當你難以說服一個人走錯路的時候,嘗試問他多點細節,叫他把他想像的過程在白板上寫出來,那他自然而然就會發現問題所在。而這種由內而外的覺醒,也是更強烈的動機。

四、風險管理(mitigate risks)

最後一點是關於Tech leader的悖論:雖然code都不是你寫的,但是你卻要為這些系統所負責。

所以在這裡risk management變得非常重要,你必須要有能力去看到project中容易被忽略的那10%,然後嘗試去降低風險。而在降低風險中你要做的其實很簡單:

  • 去理解那些你最不熟悉、最害怕的事物。
  • 然後嘗試去找出處理這些事情的答案。

個人心得

雖然這場是講TL,但與之前的文章重複性好像沒這麼高,有幾個我覺得蠻有感觸的點,這裡來講講:

關於見聞色霸氣(誤)

在facilitate的部份講到了,在別人遇到問題前先把問題解決,這個能力我覺得其實是大家應該都要培養,而非TL要有的,或者說更多應該是在成為mentor之前應該就要開始練習的能力。因為先想好未來要走的一步或一百步,本來就是工程師的職責,畢竟我們寫code要寫的好,或架構設計好,就是在預測未來的行為。

先思考路障對自己做事的幫助,有更多是你可以平行的處理事情,就有點像是coroutine,你知道對於「與別人溝通的操作」可能不會很快速的得到回覆,或者需要比較久的時間討論,那你就應該早點開始,不然sequantial的處理到最後就會變成瓶頸都在等待時間上。

移除路障的兩難

不過這裡有個兩難是,我們是否真的應該移除路障?還是應該讓團隊成員碰壁,自己去練習移除路障?關於這點我自己的答案是,要回到delegation的初衷:「delegation的目的,是為了利用下放任務而讓他人達到學習的方法」。所以路障是他未來所需要的技能,我可能就會讓他自己去撞壁XD。但如果只是one time effort,或者他早已習得這項技能,那我可能就自己偷偷做掉。

舉個小例子來說如果做task的時候要apply server的permission,這種路障對於新人就可以讓他們自己去碰碰看,但如果是老人(?)要開server,我可能就直接幫他們弄了,也可以省點時間。

不過這裡有個重點是,「偷偷做掉的事情」也要跟他們講,以防成功者偏誤(success bias)產生。


上一篇
26. 如何淘汰萬年遺毒的code
下一篇
28. 團隊成功的要素是什麼?
系列文
邁向Tech Leader的成長之路30

尚未有邦友留言

立即登入留言