在Google管理一個軟體團隊

老碼農發表於2013-04-22

伯樂線上注:2003年到2010年期間,原文作者 Matt Welsh 是哈佛大學工程和應用科學學院的電腦科學系教授。 2010年加入Google。

在我離開學術圈之後,我常常被問及我在Google的工作是怎樣的。我猜想從終身教授到軟體工程師的轉變聽起來像是個巨大的落差。拋開職位不說,我現在比起前面在哈佛的8年,工作更快樂也更高效(譯註:至於為什麼更快樂更高效,可以看看 Matt 的這篇作息對比博文:《我在Google上班的一天 vs 我在哈佛上班的一天》),儘管做教授和管理軟體團隊有很多相似之處。

我在Google的西雅圖分部領導了一個團隊,負責移動網際網路效能方面的一批專案(想了解更多有關我的團隊的工作背景,請檢視我更早的有關部落格)。其中之一是最近宣佈的為Chrome Mobile提供資料壓縮代理支援的專案。我們還承擔了PageSpeed 技術套件的研發,它是專門針對移動網際網路優化的,此外還有一堆很酷的東西我現在還不能說。

我的正式頭銜只是“軟體工程師”,這是在Google最普通(也是最令人垂涎的)角色。(我說到“令人垂涎”是因為大部分的重要決定都是工程師們拍板的)在非正式場合,我的角色是所謂的“技術主管經理”,其含義是我不僅要負責團隊的技術方向,也要承擔人員管理工作。(有些人用另外一種調調說成“上頭的技術主管”,不過對我來說這個說法有點變味了)技術主管經理在Google不是一種常見的角色,大部分團隊都有單獨的人來承擔技術主管和人員管理的工作。我之所以雙肩挑是因為我們在西雅圖上班,要讓我的團隊向一個可能在山景城總部的經理彙報工作不太靠譜。而且我也很願意做這兩份工作,喜歡這種多樣性。


像個老闆

我工作的四個主要方面是:

  • (1)規劃整個團隊的技術性方向,並確保我們能夠實現;
  • (2)寫我自己的程式碼;
  • (3)作為我們團隊和Google其他小組之間的聯絡人;
  • (4)進行團隊的人員管理工作,諸如招聘、業績評估、提升人員等等。

學術圈同行們馬上可以發現這裡和做教授類似的地方。在一個科研小組裡,教授規劃小組的技術範圍,並且輔導和指導研究生們的研究工作。這裡有個很大的區別就是我不會像教授看研究生那樣,把團隊成員看成是我的“學徒”。實際上,在我團隊裡的大部分人都是比我更強的軟體工程師,在開發穩定可靠的軟體工作上,我非常需要仰仗他們的努力工作。我的工作是為團隊裡的工程師們排除干擾保駕護航,讓他們在工作中獲得成功。

當然在這裡和學術環境有很多不同之處。我無需像教授那樣總是要跑經費才能讓專案維持進行。我也很少分心於應付各種委員會、差旅、寫推薦信和漫無目的的會議。當然,我也不用教書。(我喜歡教書,不過要教好書,吶所要做的工作量是相當的大哦。)最重要的是,我的團隊成功與否不再需要通過那種隨意而且往往是低劣的同行審議過程來決定,而這種過程在學術圈裡所有重要的事情上都是繞不過去的。這是最好的一點。只要我們進展順利併產出有影響力的產品,我們就贏了。我們不再需要通過調整提交論文中的字型間距來讓三個脾氣暴躁的課題委員會成員感到滿意。呃,我是不是跑題了……

我用50%的工作時間寫程式碼。我每天都需要幾個小時連貫的時間用來寫程式碼,這樣才能保持思路清晰。因為我沒有團隊其他人那麼多的編碼時間(而且會被打斷的次數更多),我傾向於承擔那些更通俗的任務,比如寫MapReduce程式碼來分析服務日誌並生成效能報告。實際上我很喜歡這種工作,因為它意味著和海量資料打交道,用各種有意思的方法去切分它們。目前我也不需要展示我英雄般的程式設計技巧來得到提升,所以我會讓那些更強的黑客們去實現性感的新功能。

對於我們團隊的技術方向,諸如整體設計和架構方面,我的確發揮了很多影響力。主要是因為我在考慮系統設計方面比我團隊裡的一些夥計們要更有經驗,雖然這也意味著在很多我不熟悉的實現細節上我需要服從那些寫具體程式碼的人們。我工作的一大部分就是確定優先順序,並在我們為了解決某個問題而被迫在幾個不理想的選項中進行抉擇的時候作出決定。(這也意味著,如果我做出了錯誤的決定,被放在火上烤的人也是我。)

我想我承擔的人員管理工作是業界標準的:我定期給我的直接下屬做業績評估,參加薪酬規劃,參與招聘新人加入團隊,在團隊成員申請升職時幫他們說話。當然我也會和我的每個直接下屬定期面談,幫助他們確定優先順序,清除工作中的障礙,規劃職業發展。

我工作中最多樣化的部分是作為我們團隊的代表,並和Google其他團隊合作來創造美妙的東西。我的團隊是更大的Chrome專案中的一部分,但我們和很多遍及世界的負責Google各種技術平臺的其他團隊也都有聯絡。我也經常被叫到一些會議裡討論如何把我們團隊的工作和公司裡在進行的其他工作協調起來。所以我從來不會覺得無聊。幸運的是,我們的會議效率很高(半個小時幾乎足以搞定所有事情),就算有這麼多事,我的會議負擔也只有在做學者時的一半。(另外,這些會議基本都是有產出的,相比之下,學術會議只有10%能產生實際的成果)

儘管工作量很大而且有很多救火任務,但我在Google的工作時間主要還是9點到5點。我很少在晚上和週末工作,除非有什麼事情我真的急著想做。在非工作時間裡我收到的電子郵件數量幾乎為零。(儘管我正在負責我們團隊的值班任務,最近也曾經在半夜花了幾個小時修復一個產品Bug。)這是從教授們普遍承受的工作、工作、再工作的永恆壓力下的巨大的解脫。我也感覺我用更少的時間完成了更多的事情,這要歸功於更少的干擾以及保持了清晰的專注點。我現在是這樣看待工作的:如果有人要求我完成比我在思維清晰的狀態下所能做的還要多的工作,我們就需要招聘更多的人手。幸運的是,這基本都不是問題。

宣告:本文所有內容均為本人個人觀點,不代表本人所在公司看法。

打賞支援我翻譯更多好文章,謝謝!

打賞譯者

打賞支援我翻譯更多好文章,謝謝!

任選一種支付方式

在Google管理一個軟體團隊 在Google管理一個軟體團隊

相關文章