Mentor系列-技術/商業雙主修的最佳體現

這次要跟大家分享的對象是TutorABC的COO暨CDO Arthur Shen,他對我在TutorABC的任職期間給我很多的指導,我也從他身上學習到許許多多管理與經營的思維,是一位我未來仍願意合作或效力的對象,今天便跟大家分享我從他身上觀察與學習到那些獨到之處。

別因為工作量而降低找人的標準

在我剛進公司的那段日子裡,公司正進行RD團隊的大規模擴張,手邊有許多重要的專案需要趕工,與此同時還有更多operation的庶務工作要處理,而這些庶務型工作幾乎吃掉團隊80%的能量,因此找人就成了關鍵任務。

那段時間團隊幾乎一個禮拜要面試1–20個人,而面試的錄取率也大約只有1/10不到,中間有好一陣子都挑不到喜歡的,在補人的進度不如預期時,我曾降低了我錄取人的標準,認為反正有很多的庶務工作要有人處理,那就找一些初階的人進來幫忙消化這些工作吧,讓資深的同仁可以把時間投入在專案開發上。

就在一次我送了一張晉用申請單,錄取的對象在工作經驗與背景上都不是挺優秀,比較可取之處是他的工作與學習態度良好。這張晉用申請最後被駁回了,Arthur打了電話給我,語氣有點不悅且嚴肅,他問我:「為什麼你要錄取一個經歷與專業技能都不到團隊平均水平的人?」

我如實回答他:「我們有很多庶務型工作需要有人幫忙消化。」

我記得他是這麼回答我的。

「你搞錯了,過去我們就是用了很多經驗不夠的工程師,系統才走到今天這個狀況,你應該聘用厲害的高手進來,並要他們把這些架構問題徹底搞定,否則我們永遠都會suffer在這種狀況下。」
「此外,你為何要錄取那種明顯排在團隊最末位的人進來?這個人如果進來後你團隊的平均能力是下降的,那這人進來可以為團隊帶來些什麼?」

這次的溝通不算太愉快,但事後我對此事作了深刻的檢討,也讓我後續在招聘時更加的小心與謹慎。

其實這個觀念並不是太新奇,讀過管理書籍的人應該也都知道找人要寧缺勿濫,但沒有真的碰過、想過,對此事的體悟就不會太深。這陣子跟許多中小企業主聊人才的話題,我都會直接建議他們,找人務必謹慎,不要隨便降低標準,也不要覺得自己公司規模小,很難找到好人才。即便真的如此,你也要問問自己:「這人進來是能幫上忙,還是你要花更多時間在他身上?」

別人不看好你,你要做的比預期更好

在公司內,因為有許多部門的會議我們都會共同列席,在會議中,我並沒有因為是高階主管就可以免去被究責的權利,Arthur對於我團隊的問題還是會追根究柢,不斷的提問與確認,確保相關人員都明白問題且能掌握現況。

有時語氣比較兇,態度也比較強硬,許多對Arthur認識不深的人都容易被嚇到,但對我們這些相處較久的老部屬來說,我是完全清楚原因的。

消極的原因,與其等著被別人修理,不如自己先打一頓;積極的原因,則是希望大家能不斷地拉高對自己的標準,把團隊的使命感與ownership做出來,所有的事情應該是團隊自發的想要把問題解決,而不是來到會議室時兩手一攤,沒有任何的計畫或方案,靜候老闆裁示。

RD自己不爭氣,就沒辦法怪別人不尊重我們,若要他人看得起自己,只有先做到別人沒話說,當我們對自己的要求比別人對自己的要求高時,不用別人逼,你總會做出超預期的成果。

「你們自己不在意,那誰都會想過來踐踏幾下。」

擔負起責任,同仁的成長才會加速

我接手維運的那些日子裡,因為每週有個固定的跨部門會議用來檢討前一週所有的異常事項,而這個會議我們部門原先都是由我負責報告,後來我逐漸將工作移轉給其他部門主管,這一來是要讓大家擔負起責任,二來則是要逐步培養能接手我工作的幹部。

有一次因為發生了較大規模的維運異常,當週的會議大家針對此事做了重點檢討,此時Arthur問:「負責處理的人有在現場嗎?」,我回答:「沒有。」,Arthur表示,以後這個會議要讓負責的同仁出席參與,他要負責解釋問題發生的原因,以及當下他如何處理,並說明往後如何避免以及行動計畫是什麼。

會後我私下跟他說:「Arthur,我讓各部門的leader來報告就可以了,請同仁們來我怕他們會覺得壓力過大。」

Arthur說:「我想還是要這些人親自來參加,我的目的不是要罵他們,我只是要確保所有負責我們重要工作的那些人,都清楚自己在擔負了什麼樣的責任,唯有清楚這些,他們才會更專注,不存僥倖地把每件事情做好。」

「他們如果不知道這個錯誤所付出的代價,也不清楚你們這些leader們所承受的壓力,那他們就很難成為傑出的員工,讓他們擔責,會有助於他們的成長,而你們也才有機會把權力真正下放到一線去。」

這個觀點我過去的文章其實提過多次,但也是在這過程中我真正按著這個做法去執行,才深刻體會到,被信任,而被授予權力跟責任的人,他們的成長速度往往超出你所預期,而團隊能走多遠多快,就看團隊中有多少這樣的人存在。

別抱持沒有功勞也有苦勞的消極想法

在我剛進去的第一年,我們正在處理一個系統的重構專案,那是我們第一次發動跨部門的人力,全心投入一個老舊系統與架構的改寫,專案過程遭遇了諸多的問題,幸運的是團隊配合度很高,我們逐一克服了。

最後一個環節,就是要把改好的代碼更版到production環境,因為異動的範圍廣,且改了不少底層的代碼,更版本身就具有一定的風險性,當時我們訂了一個詳盡的更版計畫,包含代碼與配置的處置順序,以及負責處理的人,將時間與人都招集了,並事先演練過更版的程序,並在午夜時啟動了更版程序。

更版的過程很順利,所有的功能都正常運作,大家歡欣鼓舞的下班了,但就在大家離開後的幾小時,我接到大夜同仁的oncall電話,他說:「James,系統掛了,應該是因為你們晚上的上的版,快找人處理。」,根據描述的情境,我馬上找了當時負責的工程師確認,後來發現是有段程式少判斷了一種情境而導致,當下立刻請CM將程式退回舊版做修正。

事後我與Arthur談及此事,我表示這個團隊敢於面對這樣的困難的任務,且排定了縝密的計畫來確保一切順利,雖然最後還是出了一點小差錯,但瑕不掩瑜,算是值得鼓勵了。

「James,如果今天是在實驗室裡,或者站在技術研發的角度看,我同意你說的,但今天我們是在真槍實彈的商場裡打仗,做到99分,最後卻因為1分的疏忽而搞砸了,那什麼都不是了,我們不能老是用苦勞來邀功,要就要做到100分才說嘴。這次我們就差一點點,但那一點點是很大的分野啊。」
「你能鼓勵他們,但你不能讓大家誤以為我們已經做得足夠好了。」

這觀點很棒,其實就是這番對話引發了我寫了昨天那篇文:微小的分野,大大的差別

技術與商務兼具的腦袋長怎樣?

Arthur是個技術人,從工程師做到CTO/CIO後轉任COO,他對技術仍有一股熱忱,也非常喜歡跟我們討論技術相關的問題,而這也意味著,你很難在技術問題上唬弄他,他的經驗比我們多數的工程師都來的多,能想到的解決方法一般工程師還不見得想得出來。

但他真正厲害的地方或許是他不只熟悉技術,對於商務也有很深刻的理解,我自認已經是個通才,熟悉的領域算很多,但很多時候我與Arthur討論事實或閒聊,他總能比我更精準地把問題描述清楚,對不同領域的知識也都陳述的十分到位,如果有不懂的地方,只要跟他提問,往往能很快地得到一個可行的方向。

在公司工作的兩年多時間裡,我跟在一個雙主修技術與商業的高手身邊,不斷的見識到兼具兩種專業所能帶來的疊加效應。很多問題你從技術或商業面來看都是有所缺漏的,但若你能同時從技術+商業面一起看,解決方案就呼之欲出了。在那兩年,我實在見證了太多次,而這也督促我自己,應該要更努力的讓自己跟上這樣的水平。

其實在兩年多的時光裡,我們打過很多艱辛且漂亮的仗,Arthur的言行舉止足可做為我輩的楷模,以上幾點觀點,分享給大家。