為什麼我辭去 Google 的工作，選擇為自己工作
在過去四年裡，我一直在 Google 擔任軟體工程師。2 月 1 日，我辭職了。那是因為他們拒絕送我一份耶誕禮物。
嗯，我想，事情其實比這稍微複雜一點。
前兩年
進入 Google 兩年時，我熱愛 Google。
當年度員工調查問我是否預期五年後仍會在 Google 時，答案根本不用想。
我當然五年後還會在 Google。我身邊圍繞著全世界最頂尖的工程師，使用著全世界最先進的開發工具，吃著全世界最免費的食物。
我最近一次的績效評等是 “Strongly Exceeds Expectations”。只要我繼續這樣做，很快就能晉升到下一個職級：Senior Software Engineer。多棒的頭銜啊！往後在職涯中，我就可以說：「是的，我曾是資深軟體工程師。在Google。」大家一定會印象深刻。
我的主管向我保證，升遷已經不遠了。他覺得我已經具備資深等級的工作能力。我只需要一個合適的專案來向升遷委員會證明。
你的主管不能幫你升遷？
不，在 Google，主管不能升遷自己的直屬部屬。他們甚至沒有投票權。
取而代之的是，升遷決定來自於由高階軟體工程師和主管組成的小型委員會，他們在決定你升遷的那一天之前，根本沒聽過你的名字。
你需要組裝一份 “promo packet”：裡面包含同事給你的書面推薦、你撰寫的設計文件，以及你為了說明自己的工作為何值得升遷而寫的小短文。
升遷委員會接著會將你的資料包與其他少數幾份一起審查，花上一整天來決定誰能升遷、誰不能。
在我前兩年的蜜月期裡，這套制度聽起來很棒。我的命運當然應該掌握在一個從未見過我的神秘委員會手中。他們不會受到任何偏袒或政治的污染。他們會看穿這一切，並因為我高品質的程式碼和精明的工程決策而肯定我。
但實際上不是這樣運作的
在整理第一份 promo packet 之前，我從未想過這整套流程在實務上是如何運作的。
在我腦中，升遷委員會是一個全知且公正的存在。如果我每天都選擇正確的問題來解決、讓程式碼基底變得更好，並幫助團隊更有效率地執行，升遷委員會就會神奇地知道這一切並給予我獎勵。
不意外地，事情並非如此運作。我花了兩年才想通這一點。
天真地工作
到那時為止，我的主要職責是一條老舊的 data pipeline(資料管線)。它已經處於維護模式多年，但負載不斷增加，管線在壓力下瀕臨崩潰。它經常無聲無息地掛掉或產生錯誤的輸出。它的故障往往要花上數天才能診斷出來，因為自最初的設計文件以來，就沒有人為它寫過任何文件。
我自豪又用心地將這條管線慢慢調養回健康狀態。我修復了數十個錯誤，並撰寫自動化測試以確保它們不會再次出現。我刪除了數千行已經無用或可被現代函式庫取代的程式碼。我一邊摸索一邊為管線撰寫文件，讓這些制度性知識能與團隊共享，而不是孤立地鎖在我的腦中。
問題在於，正如我在申請升遷時才發現的，這些成果全都無法量化。我無法證明自己做的任何事對 Google 產生了正面的影響。
沒有數據，就等於沒發生
這條管線並沒有記錄太多 metrics(指標)。僅有的幾個指標反而讓情況看起來變得更糟了。我發現的錯誤讓整體的錯誤數量增加。管線的失敗次數增加，是因為我讓它在遇到異常時快速失敗，而不是默默地繼續傳遞錯誤的資料。我大幅減少了開發人員修復這些故障所花的時間，但卻沒有任何指標在追蹤開發人員的時間。
我其他的工作在紙面上看起來也不怎麼樣。有好幾次，我把自己的專案擱置數週甚至數月，去幫助一位發布時程岌岌可危的同事。對團隊而言這是正確的決定，但在 promo packet 裡卻顯得毫無亮點。對升遷委員會來說，我同事的專案才是那個需要多位開發人員協調的重大、重要工作。如果他們把我誆去幫忙，那就是他們具備強大領導能力的證據。而我只是一個無足輕重的小卒，工作無關緊要到可以隨時被中斷。
我提交了第一份 promo packet，結果正如我所擔心的：升遷委員會表示我尚未證明自己能處理技術複雜度，而且他們看不出我對 Google 產生了什麼影響。
從被拒絕中學習
被拒絕是一個沉重的打擊，但我並沒有氣餒。我覺得自己的表現已經超出目前的職級，只是升遷委員會看不見。這是可以解決的。
我認定自己在頭幾年太過天真。我事前沒有做足夠的規劃，來確保自己所做的工作能留下書面紀錄。現在既然已經了解流程如何運作，我就可以繼續做同樣好的工作，只是要把紀錄做得更好。
舉例來說，我的團隊因為誤判而收到了大量令人分心的電子郵件警示。以前的我會直接把這些警示修好。但現在我知道，為了讓這份工作能在 promo packet 中呈現，我應該先建立 metrics，這樣我們才會有警示頻率的歷史紀錄。到了升遷審查時，我就能拿出一張警示數量呈下降趨勢、看起來很漂亮的圖表。
不久後，我被分派到一個看起來注定能幫助我升遷的專案。它高度依賴 machine learning(機器學習)，這在當時是、至今仍是 Google 最熱門的領域。它將自動化一項原本由數百名人工操作員手動執行的任務，因此對 Google 有著明確且客觀的影響。這個專案還需要我在整個過程中帶領一位資淺的開發人員，而這通常能在升遷委員會那裡加分。
耶誕禮物的當頭棒喝
幾個月後，Google 登上了新聞頭條，因為他們終止了長久以來向全體員工贈送奢華耶誕禮物的傳統。取而代之的是，他們將禮物預算拿去為弱勢學童購買偽裝成慈善的廣告 Chromebooks。
不久之後，我目睹了兩位員工之間的以下對話：
員工 A：你其實還是有拿到禮物。這類節省會推升 Google 的股價。你可以賣掉你的股票配股，想買什麼禮物就買什麼。
員工 B：如果我跟我太太說，我今年不買耶誕禮物給她，但她可以用我們銀行帳戶裡的錢自己去買任何她想要的禮物，會怎麼樣？
員工 A：你和 Google 之間是商業關係。如果你因為 Google 沒有像你對太太那樣用禮物來「討好」你而感到失望，那你對這段關係就有錯誤的認知。
等一下。我和 Google 之間也是商業關係。
這樣講或許很奇怪，我竟然花了兩年半才意識到這一點，但 Google 確實很擅長在組織內營造社群感。讓我們覺得自己不只是員工，而是就是 Google 本身。
那段對話讓我意識到，我不是 Google。我只是提供服務給 Google 以換取報酬。
所以，如果我和 Google 之間的商業關係是為了服務雙方的利益，那我為什麼要把時間花在那些只服務 Google 利益、而非我自身利益的任務上？如果升遷委員會不獎勵修復錯誤或支援團隊的工作，那我為什麼還要做那些事？
為升遷而優化
第一次升遷被拒讓我學到了錯誤的教訓。我以為我可以繼續做同樣的工作，只是把它包裝得讓升遷委員會看起來很漂亮。我其實應該反其道而行：先搞清楚升遷委員會想要什麼，然後只做那些工作。
我採取了新策略。在開始任何任務之前，我會先問自己這是否有助於我的升遷。如果答案是否定的，我就不做。
我對程式碼的品質標準從「我們未來五年還能維護它嗎？」降到了「它能撐到我升遷嗎？」除非錯誤會危及我專案的發布，否則我既不回報也不修復。我想方設法擺脫所有維護工作的責任。我不再主動參加校園徵才活動。我從每週進行一到兩場面試，變成一場都不做。
然後，我的專案被取消了
優先順序改變了。管理層把我的專案交易給了我們在印度的姊妹團隊。作為交換，那個團隊把他們的一個專案給了我們。那是一個沒有文件的系統，建立在已被棄用的基礎架構上，但它卻是線上環境中至關重要的元件。我的任務是在保持它在線上環境中持續運行並達成效能指標的同時，將它從姊妹團隊的程式碼中分離出來，並遷移到新的框架上。
我到底在做什麼？
這是六個月內第三次，我的主管在專案進行到一半時將我調離。每一次，他都向我保證這與我的工作品質無關，而是高層策略或團隊人力的變動所致。
在這個時間點，我退後一步，從更高的角度來審視發生了什麼。先不管我的主管，也不管他的主管，更不管升遷委員會。如果只剩下我和 Google 呢？在我們這段「商業關係」中，究竟發生了什麼？
嗯，Google 一直告訴我，在看到我完成一個專案之前，它無法評斷我的工作表現。同時，我卻無法完成任何專案，因為 Google 不斷在中途打斷它們，並指派給我新的專案。
這種互動關係讓人感到荒謬。
我的職涯正被一個不斷變動、匿名的委員會所主宰，而他們一生中只花一個小時來思考我的事。我完全無法置喙的管理決策，正在抹去我數個月來的職涯進展。
最糟的是，我對自己的工作不再感到自豪。我不再問自己「我該如何解決這個具有挑戰性的問題？」而是在問「我該如何讓這個問題看起來對升遷很有挑戰性？」我討厭這樣。
就算我升遷了，然後呢？普遍的說法是，每一次升遷都會比上一次困難數倍。為了讓職涯持續前進，我會需要規模更大、需要與更多合作團隊協作的專案。但那只意味著專案可能因為更多我無法控制的因素而失敗，浪費我數個月甚至數年的生命。
還有什麼替代方案？
大約在這個時候，我發現了 Indie Hackers。
這是一個為小型軟體企業創辦人打造的線上社群。重點在於「小型」。這些人不是想成為下一個 Zuckerberg（祖克柏）的人，而是想打造能支付帳單、規模不大但能獲利的事業的人。
我一直對創辦自己的軟體公司很感興趣，但我只知道矽谷新創那條路。我以為成為軟體創辦人，意味著大部分時間都在募資，剩下的時間則擔心如何吸引下一百萬名使用者。
Indie Hackers 提供了一個有吸引力的替代方案。大多數成員是用自己的積蓄，或是以正職工作之外的副業來打造事業。他們不需要向投資人負責，當然也不必向匿名委員會證明自己。
當然，也有缺點。他們的收入較不穩定，也面臨更多災難性的風險。如果我在 Google 犯了一個讓公司損失 1,000 萬美元的錯誤，我不會受到任何懲處。我只會被要求寫一份 post-mortem(事後檢討報告)，然後大家會一起慶祝這個學習機會。對大多數這類創辦人而言，一個 1,000 萬美元的錯誤就意味著事業的終結和好幾輩子都還不完的債務。
Indie Hackers 上的創辦人吸引我的地方在於，他們能掌控一切。無論事業是一飛衝天還是停滯數年，都是他們自己在做主。在 Google，我覺得自己連專案都無法掌控，更別說職涯成長或團隊方向了。
我思考了數個月，最終做了決定。我想成為一名 Indie Hacker。
離開前的最後一件事
我在 Google 還有未完成的事。在為升遷投入三年之後，我討厭就這樣一無所獲地離開。距離可以再次申請升遷只剩下幾個月，所以我決定再給自己最後一次機會。
在績效週期結束前六週，我的專案又被取消了。
其實，是我們整個團隊被取消了。這在 Google 是常見到有個委婉說法來形容它的事：defrag(重組)。管理層將我們團隊的專案轉移給我們在印度的姊妹團隊。我和同事們都必須在公司的不同領域重新開始。
我還是申請了升遷。幾週後，我的主管向我宣讀結果。我的績效評等是 “Superb”，是最高的分數，每個週期大約只有 5% 的員工能拿到。升遷委員會指出，在過去六個月裡，我明確展現了資深等級的工作表現。無巧不巧地，那正是我為升遷而優化的那幾個月。
但是他們覺得六個月的時間還不足以構成足夠長的紀錄，所以……下次再加油吧。
我的主管告訴我，如果我再以同樣的品質工作六個月，就很有機會升遷。我不能說我沒有心動，但在那個時間點，我已經在過去兩年裡不斷聽到「六個月後很有機會升遷」這句話了。
是時候離開了。
接下來呢？
當我告訴別人我離開了 Google，他們都以為我一定是有什麼絕妙的新創點子。只有傻瓜才會離開 Google 軟體工程師這種爽缺。
但我確實就是個毫無點子的傻瓜。
我的計畫是每個專案嘗試幾個月，看看有沒有哪個能做出成績，例如：
Google 是個很棒的工作場所，我在那段時間學到了寶貴的技能。離開是很困難的，因為我還有很多可以學習，但像 Google 這樣的雇主永遠都在。我不一定永遠都有創辦自己公司的自由，所以我很期待看看這條路會帶我走向何方。
更新紀錄
- 更新（2019 年 2 月 1 日）：身為獨立開發者的第一年
- 更新（2020 年 1 月 31 日）：身為獨立開發者的第二年
- 更新（2021 年 2 月 1 日）：身為獨立開發者的第三年
- 更新（2022 年 2 月 1 日）：身為自籌創辦人的第四年
- 更新（2023 年 2 月 10 日）：身為自籌創辦人的第五年
- 更新（2024 年 2 月 10 日）：身為自籌創辦人的第六年
插圖由 Loraine Yow（蘿倫·尤）繪製。