程式設計師神話：六年時間打造價值10億的帝國？
之前，我和兩位聯合創始人一起創立了 Gusto 公司，旨在為小型企業提供工資和福利結算，以及人力資源。 Tomer、Josh 和我在 Palo Alto 的一座房子的主臥室裡成立了這家公司，當時我們什麼都沒有，只有對未來的憧憬和盡一切努力將其變為現實的決心。
六年後，我們服務的客戶達到了 6 萬多家小型企業（超過了美國所有僱主的1%），員工超過了 600 名（包括約 100 名工程師），我們齊心協力達成了超過十億美元的估值。
辦公時間我一般都會在 Gusto，工程師可以隨時過來問我問題。有時他們會問我：作為這個公司的 CTO 和聯合創始人，你的職責都有哪些變化？
1名工程師：待在車庫或壁櫥裡的書呆子
公司剛剛成立的時候，我住在舊金山，而另外兩個聯合創始人住在 Palo Alto 的一所房子裡。我覺得在建立第一個原型期間我們住在一起很重要（當時我們都是單身）。不幸的是，沒有多餘的臥室供我居住，但是主臥裡有一個非常大的步入式衣櫃。我說服了房子裡所有的租戶，他們答應我每個月支付 300 美元租用那個衣櫃，我跟一個朋友借了充氣床墊，收拾好行李，搬進了衣櫃。
我是公司的 CTO，但是對於一個剛起步的公司來說，這麼說很傻，因為公司裡壓根沒人可以“領導”。軟體工程師更適合當時我的職責。我儘可能地學習複雜的工資管理系統和自動清算中心繫統，同時每天戴著耳機寫 12-14 個小時的程式碼——那種感覺非常好。我日曆上唯一的會議是午餐和晚餐休息，以及去健身房鍛鍊。這個期間我們的目標是：建立工資管理後臺系統，以供我們做自己的工資結算。
2-10 名工程師：一個團隊，一個夢想
在基本的工資管理（僅限加利福尼亞州）可以執行，並拿到種子資金後，我們搬到了舊金山的閣樓公寓，我 90% 的程式設計時間縮減到了 60%。其餘時間我需要尋找、面試並聘用工程師。作為一個 CTO，我的很多職責後來都發生了變化，但是隻有招聘花費的時間卻始終如一（可能要永遠如此了）。從那以後，我總是需要 30-40% 的時間來做招聘工作。
兼職程式設計和教練
在我們聘用了一些工程師後，我從全職開發人員變成了負責一個小型開發團隊。我仍然會花大量的時間程式設計、稽核程式碼和改 bug，但偶爾我會摘下耳機向團隊解釋自動清算中心的工作原理，或者決定我們是否應該開始稽核程式碼。如果有我力所能及且可以節約其他工程師時間的活兒（例如購買和配置計算機來執行我們的 CI 管線），我就會包攬下來。我的日曆上開始出現：一對一、 Sprint 計劃和每日例會。有些工程師需要向我彙報，但大多數情況下，由於公司沒有等級制度，所以感覺像一群同伴在一個房間裡一起程式設計。
在此期間，我們解除了媒體釋出有關 Gusto（之後的 ZenPayroll）訊息的禁令。在經歷了一個通宵之後，工程團隊緊張地監視著伺服器日誌，以確保我們的 Linode 伺服器能夠在“Techcrunch”的評論中活下來。
11-50 名工程師：緊緊圍繞程式設計
在公司快速獲得客戶並通過了 A 輪融資之後，我的工程師團隊已經壯大到 10 多人。協調所有這些工程師的工作變得更加困難。除了規模，一些早期的工程師的任期迫使我不得不將工程團隊組織得更有條理。例如，一些在 Gusto 工作了近兩年的工程師開始詢問福利制度，以及 Gusto 內部的職業發展情況。坦白來說，我還沒有認真考慮過這些問題。
與此同時，儘管團隊更大了，但是我們仍然有無休無止的功能列表需要實現，以及 bug 需要修改。我可能是對我們的程式碼庫瞭解最深的人，所以當出現問題或需要釋出一個功能時，我按耐不住想介入程式設計或改 bug。而且通常，我確實這麼幹了。
紐約之旅
2015 年，我知道自己需要遠離程式設計，並花更多時間成為一名優秀的人事經理。為了做到這一點，我決定飛往紐約，在酒店裡住三天，閱讀一些大家極力推薦的管理書籍。在飛機上，我覺得寫一段程式碼實現一個新的工資管理功能應該沒啥問題，畢竟飛機著陸後我有足足三天的時間可以專心讀書。天啊，我大錯特錯了。飛機降落以後，我無法抑制內心對做完整個功能的渴望。結果，三天結束以後，我只讀了一點點書，花時間學習人員管理的目標徹底失敗了。
每天只有那麼幾個小時，兼顧人事管理（在 Gusto，我們稱之為“人事助理”）和貢獻程式碼非常困難。作為一個程式設計愛好者，我自然傾向於先完成功能，晚一點再做人事管理的工作。對我而言，程式碼問題總是讓人感覺更加緊迫。最重要的是，我因為沒有盡到自己的責任而深感內疚。
當我做人事管理的時候，我並沒有花太多時間來完成與我的程式碼同等質量的工作。我的團隊因此而人心浮動，不放棄程式設計似乎對團隊的影響弊可能大於利。
你必須二選一
在這一點上，我認為技術聯合創始人必須二選一：繼續做技術並聘請一個專業的經理（通常以工程副總裁的頭銜繼續做技術），或者放棄程式設計，專心做管理。兼顧兩者基本不可能。
我決定專心抓好 Gusto 工程團隊，而不是程式碼。我桌子上的技術書籍換成了《思維模式》（Mindset）、《格魯夫給經理人的第一課》（High Output Management）和《The Score Takes Care of Itself 》，這三本書至今是我的最愛。《思維模式》對於幫助我為自己的發展做好心理準備至關重要。《格魯夫給經理人的第一課》幫助我學習了管理團隊的許多過程。《The Score Takes Care of Itself 》教會我如何超越管理，成為一個鼓舞人心的領導。
學習和應用這些知識，同時抵制程式碼的誘惑，對我來說是一個非常艱難的過渡，但這對於以健康的方式發展工程團隊是必要的。
51-100 名工程師：擁抱新的職責
當工程團隊發展至 50 人時，我花了 60% 的時間努力成為最好的經理（那些向我直接彙報的人的經理），還負責培訓團隊中的其他工程經理。剩下 40% 的時間我負責招聘。
隨著對人員管理職責的瞭解越來越多，我也越來越喜歡這個工作。我會把時間花在注入改善工程師入職、管理績效、多元化和包容性、文化、變革管理以及為大專案指定流程（平衡技術債務等）等。只有半年一次的程式設計馬拉松期間我才會寫程式碼。
愛我的新職責
我現在所做的一切也不全是非常愉悅。整天開會讓人很煩，與個人進行艱難的對話永遠也不會有趣。然而，我真的開始接受我在公司裡的新職責。例如，我花了數週的時間來協商計劃，以便將工資管理模組的程式碼所有權轉移到丹佛。其中一些會議漫長又艱難，但由於這些工作，現在我們擁有發展迅速的丹佛工程團隊，我為此感到非常自豪。
現在，對於自己做的事情，我能得到的享受很少，我更加享受幫助他人時產生的影響。有時只有經過一段時間才能看到這種成果，所以你可以在更廣闊的時間範圍內看待事物，從而可以獲得滿足感。
100-250 名工程師
接下來會發生什麼？下一步將要求我們的工程團隊進一步發展，同時保持與過去相同的質量水平。這意味著招聘、培養和留住人才仍將是我職責中最重要的部分。我正在致力於通過一個讓我們感到自豪的方式來做到這一點，那就是：建立一個多樣化和充滿活力的工作環境，我們可以在這個環境裡把工作做到最好。如果說我從迅速崛起的創業公司中學到了一件事情的話，那便是：變化是唯一的常態，我對未來充滿了期待。
原文： https://engineering.gusto.com/how-my-role-as-cto-has-changed-as-weve-grown-to-100-engineers/
作者：Edward Kim，Gusto Engineering的CTO。
程式設計師的工作或許會比較枯燥，但是，我們可以創造世界，改變世界，讓我們的世界變得更美好。
每當我完成一個專案的時候，沒敲一個程式碼的時候，都能有一種成就感。不知道你們有沒有？
小編從事前端開發的工作4年了，業餘的時候希望能在這裡發一些東西
這裡推薦一下我的前端學習交流群：784783012，裡面都是學習前端的，從最基礎的HTML+CSS+JS【炫酷特效，遊戲，外掛封裝，設計模式】到移動端HTML5的專案實戰的學習資料都有整理，送給每一位前端小夥伴，有想學習web前端的，或是轉行，或是大學生，還有工作中想提升自己能力的，正在學習的小夥伴歡迎加入。
點選： 加入