身兼RD與創辦人,如何平衡技術與管理?這家新創CTO詳細分享了公司壯大以來的心路歷程

評論
評論

本篇 原文 Edward Kim《How my role as CTO has changed as we've grown to 100 engineers》,經合作媒體 36 氪編譯,INSIDE 授權轉載。 編按: CTO 顧名思義就是技術的總管,聽起來似乎就是跟技術打交道為主的了。但是對於一家新創企業來說,公司的不同發展階段對 CTO 的角色要求是很不一樣的。如果到規模擴大後還想像當初那樣把大部分精力放在自己寫程式碼上的話,公司是沒辦法快速發展的。Gusto 共同創辦人兼 CTO Edward Kim 分享了自己在這方面的體悟,裡面有一些經驗值得借鑒,不妨參考一下。

在創業的各個階段, CTO 必須要扮演不同角色

我跟兩位共同創辦人一起創辦了 Gusto,這個公司的使命是讓中小企業的薪資、福利和 HR 工作變得容易一點。我和 Tommer、Josh 當初是在 Palo Alto 一間房子的主臥室那裡成立這家公司的,除了對未來的願景以及願意做任何將其變為現實的事情的承諾以外,我們一無所有。

6 年後,我們服務的小企業已經超過了 60000 家(超過美國雇主總量的 1%),聘僱了超過 600 人(包括約 100 名工程師),我們一起實現了超過 10 億美元的估值。

我會定期在 Gusto 安排接訪時間,任何工程師都可以過來問我任何問題。我有時候被問到的一個問題是:作為 CTO 和公司共同創辦人,你的角色是如何變化的?

一位工程師的時候:車庫,呃,衣櫃裡的技術宅

圖中為作者,左右為 Gusto 另兩位創辦人

我們開始起步的時候,我住在三藩市,我的兩位創辦人一起住在 Palo Alto 的一間房子裡。我認為在我們開發第一個原型的時候大家住在一起(當時我們都還是單身)非常重要。不幸的是,那裡已經沒有更多臥室可以租給我了,但是主臥那裡還有一個相當大的步入式衣帽間。在說服屋內所有房客讓我以 300 美元/月租用這個衣帽間之後,我借了朋友的空氣墊,打包好行李,然後就搬進來了。

我是 CTO ,但在公司的那個階段,這麼稱呼感覺會很傻,因為其實並沒有任何可以稱為「首席」的。軟體工程師用來描述我的角色更加合適。我盡可能地學習非常燒腦的薪資系統以及 ACH 系統的機制,同時每天用 12 到 14 個小時戴著耳機來程式設計——這種感覺很棒。我的日程上唯一的會議是午飯、晚飯以及去健身館鍛煉。這期間我們的目標?開發一套薪資後端系統從而讓我們能夠通過它來付費。

2 到 10 名工程師:一支團隊,一個夢想

在讓一個基本的薪資系統跑起來之後並且完成了種子輪融資之後,我們搬到了三藩市的一棟閣樓公寓裡面,這時候我的 Coding 時間占比從 90% 縮減到 60% 了。剩下的時間花在了尋找、面試以及聘用工程師上。我作為 CTO 的角色已經發生了很大的變化,但花在招聘上面的時間卻一直沒少(而且可能會一直如此)。從這時候開始,我總要花 30 -- 40% 的時間用於招聘。

成為球員兼教練

在我們招了一些工程師之後,我從成為唯一一名全職開發者變成了跟一小群開發者合作。我仍然要花很多時間在 Coding ,程式碼審查以及修補 bug 上,但我偶爾會摘掉耳機向團隊解釋 ACH 是如何工作的,或者跟大家商量是否應該開始進行程式碼審查了。只要我能為其他工程師保留製造者的時間,比如購買和配置電腦跑我們的 CI 管道,我就會去做。像 1 對 1 對話、衝刺計畫以及每日站立會議等開始爬滿我的日程。我要聽取工程師的彙報,但大部分都沒有層級之分,工作氣氛仍然感覺像是一群同行一起在一間房子裡 Coding 。

在此期間,關於 Gusto(當時叫做 ZenPayroll)發佈的消息被封鎖了,經過一晝夜通宵的忙碌之後,工程團隊緊張地監視這伺服器日誌,不斷刷新頁面以確保我們的 Linode 伺服器在被 TC 報導之後還能存活。

11 到 50 名工程師:堅持寫程式碼

Maker:0x4c,Date:2017-9-28,Ver:4,Lens:Kan03,Act:Lar01,E-Y

緊跟在公司迅速獲取客戶並且進行 A 輪融資之後,我的工程師團隊已經超過 10 人了。對這些工程師進行協調變得更加困難。除了規模以外,其中一些早期工程師的資歷也要求我必須讓我們的工程組織變得更加結構化。比方說,我們的一些工程師已經在 Gusto 工作了將近 2 年了,他們開始要求補償框架以及自己的職業發展路徑規劃。說實話,在這方面我沒有給予充分的考慮。

與此同時,儘管團隊規模變大了,但是要發佈的功能以及待修改的 bug 的清單仍然沒完沒了。最熟悉我們程式庫的人可能仍然是我,所以當出現問題或者需要交付一項功能時,我總是忍不住跳出來想自己寫和修補 bug。這經常是我幹的事情。

紐約之旅

2015 年,我知道我需要從 Coding 這件事情上退下來了專心成為一名好的管人的經理了。為了實現這一點,我決定飛赴紐約窩在一家酒店內用 3 天的時間讀一些推薦率很高的管理書籍。在飛行過程中,我認為編個薪資的新功能應該不會有任何傷害的——畢竟我有整整 3 天的時間去專心看書。但我錯了。當我下飛機後,我對不能徹底寫完那項功能感到耿耿於懷。到了 3 天結束之後,那些書我只看了一點點,我的騰出更多時間專心研究人事管理的目標非常糟糕地失敗了。

一天就只有那麼多時間,要同時兼顧人事管理(在 Gusto,我們稱之為「人員賦權」)以及個體貢獻者責任是極其困難的。作為 Coding 的愛好者,我自然是傾向於完成後一項任務而把管人方面的事情擱置到後面才做。對我來說,程式碼問題總是覺得要更緊迫一點。除此以外,我還要跟沒有做完自己那部分事情的內疚做鬥爭。

當我的確抽出時間去做人事管理方面的事情時,我並沒有花費同樣的時間去做到像寫程式碼一樣的品質。因此我的團隊也稍微出現了一些動搖,可以說我不放棄 Coding 所帶來的傷害要比做出的貢獻還要大。

你必須做出的二元對立選擇

到了這個時候,我相信技術共同創辦人要做出二元選擇:要麼繼續走技術路線,聘請一位專業經理人(通常給一個工程 VP 的頭銜);要麼放棄 Coding 自己專注於管理方面的事情。想兩全其美真的是不可能的。

我決定專注與壯大 Gusto 的工程團隊,而不是我們的程式碼。我案頭的技術書開始被《Mindset(終身成長:重新定義成功的思維模式)》、《格魯夫給經理人的第一課》、《The Score Takes Care of Itself(完美主義者的完美主義)》這類書所取代——直到今天這仍然是我最愛的三本書。《Mindset》對於幫助我在對待個人前途的心態上做好準備非常關鍵。《格魯夫給經理人的第一課》幫助我學到了管理團隊背後的許多流程。《The Score Takes Care of Itself》教會了我如何超越管理成為一名鼓舞人心的領袖。

對我來說,學習和應用這些經驗同時抵制 Coding 的誘惑是一段異常艱難的轉變,但對於以健康的方式擴大團隊規模來說卻是必要的。

51 到 100 名工程師:擁抱新角色

等到我們達到 50 名左右的工程師時,我開始把 60% 的時間放在盡量成為直接下屬最好的經理上,並且培訓團隊的其他工程師經理也做到這一點。剩下的 40% 時間則花在了招聘上。

我在人事管理方面的職責做得越好,我就開始約享受其中。我會花時間在改善工程入門培訓、績效管理、多元化和包容性、文化、變更管理等事情上,並且用流程去管理平衡技術債務之類的大專案。我唯一會去 Coding 的時間是在半年一度的黑客松期間。

熱愛我的新角色

並不是現在所做的任何事情我都享受其中。整天開會仍然給人的感覺非常糟糕,跟個別人展開艱難的對話從來都不是有趣的。不管如何,我已經真正向我在公司的新角色敞開了懷抱。比方說,我花了幾周的時間去協商一項計畫,將我們薪資領域更多的程式碼所有權移交給 Denver。其中一些會議相當的漫長和艱難,但作為那項工作的結果,我們現在已經有了一直迅速成長的 Denver 工程團隊,對此我感到極其自豪。

我的愉悅現在更少地來自於我自己所做的事情,而是更多地來自於我幫助他人產生的影響。有時候你只有在一段時間之後才能看到這個,所以你要通過學會從更寬廣的時間範圍內看待事物來獲得滿足。

100 到 250 名工程師

接下來會發生什麼?下一篇章要求將我們的團隊規模進一步擴充,同時還

要維持我們在過去的品質水準。這意味著招聘、發展以及挽留人才仍然是我的角色最重要的工作。對我來說,我致力於用一種我們感到自豪的方式去做,通過建立一個多樣化的、生機勃勃的、讓我們能夠做出最好工作的環境來做到這一點。如果說我從一家快速成長的新創企業裡學到了什麼的話,那就是唯有變化是唯一不變的東西——我也非常興奮地期待著未來將如何展現。

評論