本文為《星箭廣播》159 集——工程師，你的 1:1 會議都怎麼談？（ft. vgod & 🐶） 訪談逐字稿。本集節目介紹與相關連結請到此頁面閱讀。
本集使用說明＆來賓介紹
Titan：嗨！大家好，歡迎收聽星箭廣播第 159 集，我是主持人 Titan，今天很特別我們再度邀請到先前在 154 集有上過節目的特別來賓，在美國矽谷大型軟體公司工作的工程師 vgod，先請 vgod 跟聽眾打招呼。（星箭廣播 154 集——連載再開！從程式設計之道走向軟體工程師的修煉與成長（ft. vgod） | Star Rocket Blog）
vgod：大家好，我是 vgod，很高興又可以來星箭廣播，跟大家再次分享我的一些心得。
Titan：上一集算是這整個系列節目的第一集，那時候講的是從〈程式設計之道〉走向〈軟體工程師的修煉與成長〉，原因是年紀跟我差不多的聽眾可能都有讀過，以前 vgod 寫過的文章〈追求神乎其技的程式設計之道〉，在那系列文章跟我們第一集節目，他花了一些篇幅跟大家分享，以前小時候從國中開始自學寫程式，一路到 MIT 讀博士，進入軟體公司工作過了一段時間。
中間連載曾經停過一段時間，最近連載再開，開始寫〈軟體工程師的修煉與成長〉，他開始在現在服務的這家公司，待的年資比較久，開始有些新的體悟，跟他當年剛進公司的時候已經很不一樣，他想跟大家分享一下，他認為這個部分，比較像是在講軟體工程師在做什麼，跟以前講程式設計是有差別的。
在那集談到的話題除了回顧之外，vgod 進駐現在的軟體公司裡面，首先他先意識到程式設計跟軟體工程的差別，以及跟我們分享剛進這個軟體公司之後，會遇到比如身為一個 mentee，這種學徒制裡面的學徒，以及開始變成資深工程師之後，要怎麼帶領新人？
上次有跟大家預告節目會有第二集，很幸運的 vgod 在上次錄音後就直接跟我說沒關係，後面東西太多，我們就再拆成兩集，我們錄音至少會有三集，所以大家要記得再回來聽我們第三季。
今天節目可以分成三個部分，第一個就請 vgod 跟大家講剛進現在這家軟體公司的工作情形，以及他遇到的狀況，有些狀況是當時他沒有意識到，後來回過頭看，才發現他當時有這些問題，而且當時可能都沒有人跟他講，包括他當時的 manager 可能都沒有讓他發現這件事。
再來，第二部分會講到我們上次有跟大家預告，他寫的那篇文章一定是最紅的，題目〈1:1 該談什麼才能讓職涯起飛？〉，我想這應該是很多工程師或在工作的時候追求職涯發展的人會很在乎的事情，這是我們節目的第二部分。
第三部分，我們上次有稍微提到，上次講 vgod 在〈軟體工程師的修煉與成長〉系列文章第四篇 〈Product vs Infrastructure〉，這篇文章裡面有講到 Tech stack 跟 Technical leverage， 我們今天要用不同的角度，請他來談一下這件事情，會涉及到工程師怎麼樣在他做前端跟後端的時候，在組織、團隊裡面發揮他的影響力，這個部分今天會請他來談，作為我們第三集節目要談的主題，我們講 IC（Individual Contributor）這種職涯路徑的一個引子。
得到不符預期的「符合預期」評價
Titan：我們今天要講的第一部分，先請 vgod 跟大家談一下他剛進現在這家公司的時候，工作的狀況，他很認真的在做哪一些事情，但等到績效考核的時候，卻發現好像做錯工。
vgod：先從我剛進公司的時候在做什講起，我是從 2015 年的時候加入現在這家公司的，我加入的時候在做的一個產品，算是一個有點類似 Google Docs 的共筆軟體，我做的是產品方面的，開發新的功能，會給使用者直接使用的介面，或是後端的服務也有做，基本上前段後段我都有做，都是在 Web 的領域。
我剛加入公司的時候，算是中階的工程師，我們在矽谷說的 L4 的工程師，在矽谷一般的工程師等級是從 L3 開始，L3 是你大學剛畢業會有的等級，進去後大概過了一兩年，就會升到 L4 變成中階的工程師。
Titan：想請問一下，所以 L1 跟 L2 是留給實習生嗎？
vgod：對，我記得 L2 是實習生，可是我不知道 L1 是什麼？這件事情一直是個謎。
Titan：真的嗎？
vgod：對，這個等級制度是從 Google 開始，他們一開始的時候，是有留了兩個 L1 跟 L2下來，可是現在好像已經沒有在用，基本上所有的等級都是從 L3 開始。可是在每家公司其實都不太一樣，我們公司實際上是從 L1 開始，只是為了讓大家了解方便，我把它 unite 到跟其他公司都是一樣，從 L3 開始這樣子。
Titan：這樣有點像 C 槽的概念。
vgod：對，沒錯。C 槽以前都要從 A、B，但後來也沒有在用了，都從 C 開始。
剛加入公司的時候，我是從 L4 開始，稍微有一點經驗，可是也還不到資深工程師的等級，剛進公司的時候，我算是蠻有衝勁的吧，所以我覺得可以加入這個團隊開發一個新的產品，在公司也算是一個非常新的產品，覺得非常的興奮。
加入的時候我們團隊還很小，大概只有五六個人吧，那個時候大家可以自己決定你要做什麼事情，因為這個產品還很新，我們有很多功能需要做，像 backlog 一樣，從裡面就可以看到現在有什麼新的功能是需要被做的，基本上我們做這個是從裡面挑一個你喜歡的跟老闆討論一下，決定大概要花多久時間，這樣就可以開始做。
剛開始進去的時候，我先從裡面比較小的開始，從比較小的 bug 開始解起，開始做一些比較小的功能，我覺得可以獨立做完，可以自己研究一些現有的系統架構，我就知道說要從哪裡切入，就可以開始做。那時候我還花蠻多時間在做這個事情，覺得我好像只要花很多的時間，一直開發新的功能，做越多功能就越好，可以用越快的速度把這些功能開發出來就越好，基本上前一年，我大概都是這樣子拼命不斷的寫程式，也沒做什麼其他的事情。
每個人都在做一些不同的功能，有的可能是做給使用者的使用功能，有的是做比較後端方面，給大家共用的一些工具，甚至是做給我們團隊用的一些開發的工具，這些東西都有不同的人在做，可是那時候我沒有關心太多這方面的事情，想說我就做我有興趣的部分就好了。
一開始這樣其實也沒有什麼問題，大家也都是這樣子做的蠻開心，直到大概過了一年後，我們的 performance review 的時候，performance review 是一個年度的績效考核，每家公司都有，一般矽谷公司的考核方式是這樣，除了是老闆要給你一個 feedback 之外，自己要先寫自己的 feedback，也要跟你的同事要求他們給你 feedback，就是我們說的 360度的 feedback 的制度，好處是不會完全依照老闆跟你的印象來決定 performance 好不好，而是你的同事也會有參與的機會。
那時候覺得我好像做很多事情，ship 非常多的功能，寫了很多 code，而且好像也寫得蠻快的，所以就覺得這樣子我的 performance 應該不錯吧，結果在 performance review 出來以後，我就得到了普通的 rating，我們的 rating 有大概 1～5 這樣子，普通就是 3，大部分的人其實都是得到 3，那時候我自己給自己的評價是 4，我應該是有比一般 average 好一點吧，剛拿到這個 rating 的時候，我其實有點失望，因為覺得我好像做了很多事情，可是沒有得到認可，我其實也不知道為什麼？
在 performance review 的時候，老闆給我的 feedback 並沒有講為什麼我得到 3 而不是 4，他沒有講那麼清楚，他就說我已經做得很好了，因為大部分人都是得到 3，所以你得到 3 也是很正常的事情，4 真的要做的非常傑出，exceptional 的好，例如：幫這個產品做了什麼天翻地覆的事情，才有可能得到 4。
Titan：他當時給你的 feedback 只有大部分人都是 3，不要放在心上，4 要怎麼樣做，他是說要做到真的在產品上有很大的突破，或是重大的貢獻，他講的比較單純是從這方面的角度去理解表現的分數嗎？
vgod：對，他講的方式比較像 4 是一件非常難做到的事情，只有在真的做了很大的貢獻的時候才有可能，可是他也沒有講很大的貢獻是什麼意思，對於一個初階的工程師來說，這個概念對我來說非常的模糊，不知道要怎樣才能達到這種程度的 impact。
那時候我老闆，他其實也是新手老闆，他原本也是一個工程師，才剛轉成做 manager 不久，我覺得他其實也不知道要怎麼跟我講這件事情。那時得到 feedback 以後，我也沒有特別再深究，就覺得好吧，明年說不定就會好一點，反正我還喜歡現在做的事情，我可以繼續這樣子做下去，我就這樣又繼續做下去了。
Titan：我覺得這種感想經過第一次的 performance review，你得到 3 這個分數，普通的這個分數，符合預期表現的分數，然後有你剛剛的想法沒關係，可能就像老闆講的，我再努力也許明年狀況就會改善，我覺得這個好像的確是普遍大家會馬上有的想法，再加上如果老闆就是這麼講，好像更容易自然而然就接受這樣子的想法是不是？
vgod：對，沒錯。我覺得 manager 有一個很重要的工作是很清楚的跟他的 report 說他的 expectation 是什麼，這個 exception 應該需要對應到你的 performance review 的 rating，例如：你做了什麼樣的事情可以得到 3，做什麼樣的事情可以得到 4，這些必須要非常清楚的，我們說 action item，他必須要是可以 actionable，你要有一些明確的動作，讓 report 說你做這些事情的結果產出來也是好的，那你應該就可以得到這個 rating。
而不是比較模糊的，只是說你只要做一個對產品產生非常好的改變，例如：我們要可以增進多少的使用者，讓多少使用者的 retention 增加，或是可以帶來多少新的使用者，這個也是一種 metrics，可是這方面是工程師比較難去達到的 metrics，這方面的 product metrics 是工程師比較難施力的，因為一般工程師其實是沒有能力可以獨自決定這件事情，一個 product feature 是需要 PM、Designer 還有 Engineer 共同一起合作，一起決定，如果對工程師的評價是從這個 product 的真正 impact 來，對工程師來說是非常難施上力的。
令人緊張的「On Call」經驗與解法
Titan：第一部分我也想要請 vgod 跟大家分享系列文章第三篇 〈On Call 遇到的挑戰〉，延續剛剛跟大家談的剛進這家公司的時候，他就是專心做自己的事情，而且很快把自己負責的工作做完，大家知道軟體工程的團隊，通常以這種比較大規模的公司來說，可能每個團隊有自己固定要負責的算是守備範圍，可能公司的某個功能、某個產品，是這個團隊要負責維護的。
再往下分可能每個人分到的工作又不太一樣，你可能會不太熟悉團隊其他同事在做的事情是什麼，但 On Call 就是要一個人 cover 全部的事情、發生的意外狀況。vgod 在文章裡面有提到，其實還是有一個備援的工程師，等於是第二個 secondary 的這種方案，secondary On Call 的一個角色，這邊先請他跟大家分享剛開始，當時的團隊 On Call 的時候遇到的狀況是什麼樣。
vgod：那時候因為我們團隊在做一個新的產品，所以這個新的產品，我們也要自己負責監看產品是不是有在正常運作，我們設置了很多監看還有警報的系統，這些系統可以幫助我們在出事的時候，系統某方面出現異常狀況，例如：出現了很多的錯誤，這些很多的錯誤就會 trigger 這個警報系統，這個警報系統就會馬上 page 當時 On Call 的工程師，我們 team 上面每個時候都會有兩個 On Call，一個 primary On Call，一個 secondary On Call，primary 要負責在被 page 的三十分鐘以內一定要回應，你必須要上線，坐到電腦前面去，馬上進入 production 系統，去看到底出了什麼問題，想辦法把它解決掉。
這件事情對當初的我來說其實還蠻困難的，因為當初我就是很專心的做自己開發的 feature，對我自己開發的東西當然很熟悉，問題是整個系統非常的大，還有非常非常多部分是我完全不熟悉的，我也沒有看過那部分的 code，其實也不知道它們怎麼運作的，可能有一些模糊的概念，可是絕對沒有仔細到我有辦法去修那邊出的問題。
剛開始 On Call 的時候我就非常的剉，你只要一被 page，馬上就要進去系統看，然後你要先找出問題到底出在哪裡，因為出現的錯誤可能是千奇百怪的，有一些如果是你看過的那還好，可是很常會出現你完全不知道是為什麼發生的問題，這些問題都是來自於人家新寫的程式。
在開發這種 Web 的系統，這個程式都是不斷一直在更新的，大家每天都是有幾十個、幾百個新的 code 一直被不斷 push 進去，所以大部分的時候，你被 page 的時候，問題都是出在那些最近剛寫的 code，比較簡單的方式是如果發現新的 code 出現的問題，你就 rollback 到前一個版本就好了，前一個版本如果知道是沒問題的話，就可以解決了。
可是，有時候就會出現一些情況是那個問題可能藏得比較深，不是那麼容易會被 trigger 到，這個時候你就必須要去找問題在哪裡，你 rollback 可能也沒有用，因為可能在很久以前的版本就已經跑進去，只是我們那時候沒有發現而已。
On Call 必須要能夠在時間壓力下處理這種問題，這時間壓力蠻恐怖的，因為軟體公司都有一個很嚴格的 SLA，我們叫做 service-level agreement，這個 agreement 是我們的系統開發出來，因為要給其他商業公司使用，所以我們之間其實是有合約的，這個合約會寫得很清楚，我們的一個月只能 down 多少時間，例如：比較常見的是 99.9％ 的 SLA，這意思是我們在一個月內，每個月 99.9％ 的時間，我們系統都必須要是能夠正常運作的，都是要能夠上線，並且正常運作。
換算一下你就知道我們只有 0.1％ 的時間，也就是一個月大概只有 43 分鐘可以出事，這就算是我們故障時間的預算，如果故障了以後，每一次開始 page 的時候，其實事情都已經出現可能幾分鐘了，因為我們的警報系統都是錯誤累積到一個程度才會發出來，因為一開始如果設的太敏感，就會不斷的被 page，所以要累積到一段時間才會出來，那時候其實已經過了幾分鐘。
你接到 page 上線，真的開始處理可能又過了 10 分鐘，開始進去真的了解發生什麼問題的時候，可能又過了 10 分鐘、20 分鐘，一個月不要看 43 分鐘，很快就用掉了，43分鐘你只要被 page 兩次，你就用完了，這是非常可怕的時間壓力，對 On Call 工程師來講，就是必須要在這種壓力下處理這個問題。
那時候我非常菜，我也不知道其他人寫的 code 在幹嘛，一開始遇到問題的時候，有好幾次都是完全沒有頭緒，比較幸運的是大部分出問題的時候都是工作時間，還會有其他工程師還在公司，或是在線上，那時候我只要請他們來一起幫忙看是什麼問題，通常都可以被解決掉。
在晚上的時候就比較糟糕，我們是 24 小時 On Call，所以你有可能在半夜的時候也會被 page，就會半夜被叫醒，半夜被叫醒的時候，如果那時候你又不知道問題要怎麼解決，你就必須要再去 page 另外一個工程師，請他上線來處理，被 page 的那個人想當然就會非常的不開心，他明明不是 On Call，卻要半夜被叫起來。
Titan：所以你在文章裡面寫的是真的有發生過的事情？
vgod：對，真的有發生過。沒有發生過很多次啦，我有至少兩次是我在半夜被 page，然後我不知道要怎麼處理，只好 page 我們 team 的其他工程師來處理，有一次比較嚴重的是那個問題還不是在我們 team 的範圍內可以解決，是我們公司的其他系統壞掉了，我們就要連續的把其他 team On Call 的人叫起來。
Titan：像連鎖反應一樣。
vgod：對，是一個非常可怕的連鎖反應，那個時候只要這種比較大規模的故障發生，如果是系統，我們整個公司比較多團隊在共用的 infrastructure 壞掉，例如：我們公司整個中央資料庫壞掉好了，這個壞掉整個公司幾乎所有 team 的 On Call 都會被 page，然後幾十個人，甚至一百個人就會全部跑上線，一起到 slack room 裡面討論到底發生什麼事情，其實也是蠻壯觀的。
Titan：但是這樣子個人的緊張感應該會下降一些啦！
vgod：對，如果知道問題不在我們的話，其實就會比較好一點，可是我們還是必須要能夠提供意見，幫忙想到底哪裡出問題，甚至是討論一些解決方法，因為這種 online 系統出問題的時候，有時候你要修復的不是只要把它重開機就好了，像一般電腦你可以直接把它重開機。
這種 online 系統要修的時候，因為牽扯到線上已經有存的資料，如果直接重開機好了，你可能會丟失掉一些資料，所以必須要能夠保證在不丟失資料的情況下，把系統恢復到正常的狀態，這就需要工程師進去做一些手動的工作，這些就是真正難的地方，你必須要很明確知道你要做什麼，把這些步驟在短時間內寫出來跟大家討論清楚，確定沒問題後，再去執行。
Titan：而且你在進行這件事情的過程當中，SLA 的時間還是繼續再累積當中是嗎？
vgod：對，沒錯。這個時間是不會停的，所以如果是碰上大規模的故障，還有可能一次故障就會把你整個月的時間用掉，甚至會超過，這是非常有可能發生的。
Titan：這邊我想問兩個問題，第一個是我們上一集，第一集有講到 mentoring，一般來說，資深的工程師，大概會花六週去陪一個新進的工程師，協助他認識你們公司的系統，像你有提到 navigate，你們的 cobe base 這件事情，你剛有提到，當時剛開始 On Call 的時候，對於團隊其他人在做什麼，其實不是很了解，我好奇是不是這六週的時間是不夠去處理這個部分的問題？
vgod：對，基本上六週的時間，我們對於一個新人的期待是他可以把需要用的工具全部都練熟，知道要怎麼用例如：怎麼寫程式，怎麼用 Git 把程式 push 到我們的 Version control 系統裡面，怎麼樣 deport 你的程式，把寫好的程式 deport 到 production 上面，怎麼做測試，出了問題怎麼 rollback，還有一些我們說的 operation 事情，operation 是你必須要知道怎麼讓已經在線上的系統，讓它保持健康的狀態，中間是有一些日常需要做的工作的。
六週的時間，大概只能讓一個新手的工程師知道這些事情，並且幫他做新手的一個 project，這個 project 可能會設計好，讓它可以在六週時間內，學完這些基本工具，然後把一個很小的 feature 寫完，寫完以後他就可以把它 ship 出去，讓他覺得完成一件 mile strone。
可是六週大概也就這樣而已，你沒有辦法知道整個系統那麼大，是那時候我們五六個人做的系統，已經有幾十萬行的程式碼，在這麼大規模系統下，你是絕對不可能馬上了解其他人在做的部分在幹嘛，更別提這些程式碼每天都在變，每個人每天都在寫新的程式，它會改就會有人寫新的程式，所以這些東西很難一直按著發展步調學習。
Titan：我想要請問現在大家有發展出一套方法，能夠解決剛 On Call 的工程師比較不了解整個情況的一些方法嗎？
vgod：我們現在有一些比較好的方法，那時候我們 team 沒有做得很好，我們沒有所謂的 playbook，playbook 意思是當你遇到什麼問題的時候，有一個很明確的，就像 SOP 一樣，跟你說應該要從哪裡看，可能的問題點在哪裡，然後你可以做什麼步驟去嘗試修復這些問題。
這些 playbook 很重要，讓新手工程師可以知道出現問題 A 的時候，可以做什麼步驟，出現問題 B 的時候，可以做什麼步驟，即使是你完全不熟的系統，也應該要可以看 playbook 就知道要做什麼事情來排除這些因素。只有在最後，playbook 全部用完的時候，你已經試完所有東西，還是沒辦法解決的時候，才需要去 page 另外一個人。
假設某一個功能壞掉，去 page 當初做這個功能的人，讓他自己看到底發生什麼事情，這時候被 page 的那個人也會知道，被 page 並不是因為 On Call 做的不好，而是因為沒有把 playbook 寫好，他可能新寫一個功能，可是他沒有去 update playbook，沒有把對應這些排除故障的方法寫下來，造成的結果就是他可能會被 page，不是他 On Call 的時候被 page。這其實變成一個蠻好的正向循環，如果今天你沒有把 playbook 寫好的話，其實比較大的責任是在你身上，你只好被 page，沒有辦法怪別人，因為當初就是自己沒有把它寫好。
尋求協助的界線在哪裡？
Titan：第二個問題我想問之前的工程師在遇到狀況，比如剛剛講到 On Call 的狀況，在尋求協助的時候，一般來說這種工程師的團隊，或你的同事們，他們可以接受之前工程師在尋求協助，可以接受的範圍是什麼？有沒有一個界限？
我想大家還是知道在職場上，不是只有工程師而已，有些問題應該是你自己要解決的，有些東西當你去麻煩別人來幫你處理的時候，有可能會讓同事不太愉快，或他們會很明確知道你有點越界了，這個問題不應該是你來找我們，應該要自己解決。
就像剛剛 vgod 有跟大家講， playbook 就擺在那邊，你如果都沒有看，或你來問的問題被人家發現，就在 playbook 第二頁，你都沒有看，這樣子就會有問題，我想要請 vgod 來談一下，這種尋求協助的狀況，到底界限在哪邊？有辦法跟我們的聽眾講一下嗎？
vgod：這是一個蠻好的問題，這點跟公司的 culture 有很大的關係，不同公司在處理這件事情的方法會不一樣，以我們公司來說，我們公司的 culture 算是非常好的，意思是大家是很樂意互相幫忙的，在問問題的時候你也不需要擔心問了一個笨問題，或你請別人幫助的時候，是在麻煩別人，或在請別人做你的工作，我們公司的人其實完全不會有這樣子的想法。
這給新人提供了一個比較安全的環境，不用擔心你問錯問題，或是問了笨問題，即使你因為不懂這些系統其他部分怎麼運作的，也不用擔心到底該不該問這件事情，在我們公司這件事情是不會發生，所以那時候如果是我在 On Call 遇到問題，我很放心可以直接問別人，或請別人來幫忙，不用擔心他們會給我一個不好的印象，或不好的 feedback。
相對在有些公司，他們的 culture 不是這樣子的，有些公司他們是比較互相競爭的，大家可能知道比較傳統公司，他們是有一種排名機制的，他們每一次 performance review 都要固定淘汰掉整個公司的 8％、10％ 的人，所以你如果在同個團隊裡面，必須要能夠表現得比你的同事好才行，如果表現不好，如果到最後 10％ 可能就會被開除掉，某些公司的 culture 是這樣子，在團隊裡面，幫別人對你其實沒有好處，反而還有害處。
在這種 culture 底下，大家就會變得不想要去問一些笨問題，或隨便請別人幫忙，因為請別人幫忙，第一他沒有動機需要幫你，他不想幫你，第二如果請他幫忙，然後問了一個笨問題，他可能給你的 feedback 就會不好，你會必須要擔心很多這種事情，這種 culture 我覺得對公司來講並不是一件好事，長久下來會讓大家變得非常封閉，大家就在自己的 silo 裡面做自己的事情，都不跟別人交流，這種資訊的不流通，我覺得對公司長期來講是一個很大的傷害。
Titan：如果從比較資深工程師的角度，像你帶過的新進工程師，有沒有什麼狀況是你的確會直接跟他們講不應該這樣做，應該要換一個方式，你會怎麼引導他們？
vgod：現在回頭看我會覺得對於在帶新人，比較初階的工程師來說，他們比較常遇到的問題是埋頭苦幹，就像我當初剛加入的時候一樣，覺得我的工作就是要寫程式，我應該就是要把老闆交下來的任務，或是我被分配到的任務把它寫好，他們就不管其他事情，他們每天工作的任務就是把 code 寫出來，可以準時，甚至超前的速度把它寫出來，就是他們最大的目標。
所以對於資深工程師來講，我現在在 mentor 他們的時候，會很注意不要讓他們自己埋頭苦幹，完全不問是不是這樣子，這是很容易變成一個很糟的情況，他們有問題可能不會來問，他們也沒有辦法了解系統的其他部分，因為現在每個大型的軟體公司，每個系統都很大，一個人是只能了解其中很小的一部分，你要了解到整個 team 其他人在做什麼，公司其他 team 在做什麼，都是一件非常難的事情，這件事情是需要刻意去做的。
對於新手工程師來講，我會特別避免讓他們掉入自己的 silo 裡面，讓他們做這個東西都不管其他的事情，這樣長久下來，他們會陷入我以前碰到的不好循環裡面，會覺得好像做很多事情，可是為什麼這些事情沒有得到老闆的認可，好像沒有產生很大的 impact，很大一部分是來自他們太專注在自己的事情，沒有真的理解到有其他更重要的事情需要被做，這是他們不知道而已。
Titan：我補充一下，剛剛聽眾聽到背景有些聲音，那是因為 vgod 他們家的狗，我覺得有時候錄音保留背景聲音是蠻有趣的，我們以前錄音的時候，會錄到我家這邊垃圾車的聲音，大家知道垃圾車聲音出現之後接著會是什麼？資源回收車！所以都會有一些聲音，蠻有趣的，應該沒有影響到大家收聽的狀況啦。
想要走人了
Titan：順著剛剛 vgod 跟大家講，如果一個初階工程師進入一個團隊後，不小心掉進了 silo，他的主管或 mentor 沒有注意到的話，開始這種挫折感，可能在每年 performance review，或是每半年 performance review 的時候，就會開始累積，一開始會出現，接著就會開始累積，幾次之後就會開始發生 vgod 在他的文章裡面寫的這個狀況。
接著，我們要請他來談一下當時提到〈1:1該談什麼才能讓職涯起飛？〉，他當時在寫文章的時候，當然是可以說我現在跟大家分享一下，怎麼談才可以起飛，但是在之前，他可能自己也曾經遇到過一個狀況，他一直在累積這種挫折，也沒有人跟他講到底為什麼會這樣，所以我想請他來先分享當時的狀況。
vgod：之前我有提到，因為第一年的 performance review，拿到一個 3 分，很普通的成績，我們叫 meet expectation， 剛好可以達到老闆心中的期待，你沒有更差也沒有更好，這樣之後，我後來又繼續這樣子做了一年。第二年的時候，我並沒有做什麼不同的事情，這件事情本身就是一件不好的事情，如果你拿了一個 rating，你覺得不好，應該是要做一些不同的事情去改變，可是那時我也沒有想那麼多，我就照樣繼續做我的事情。
因為我並不知道我做的事情不對，我只是繼續享受寫程式這件事情，因為那時候就只是一個喜歡寫程式的人，可以說我是一個不錯的程式設計師，可是我並不懂真的軟體工程師是什麼樣子，一個軟體工程師是必需要可以跟其他人合作，要做很多程式設計以外的事情，可是那時候我完全不知道，所以我就是很專注在做寫程式這件事情。
那時候我就是這樣又過了一年，到第二年 performance review 的時候，我覺得今年又做更多事情了，我對於這個系統了解更多了，開始做一些其他的部分，不是只有我的一個小 feature，我也做很多其他的 feature，覺得這次應該可以做得比較好了吧，至少在 performance review rating 上應該可以比較好。
這樣又過了一次 performance review，我拿到的 rating 一樣又是 3 分，這時候我覺得非常困惑，因為我感覺自己做得很好，我程式寫得很好，我知道我很會寫程式這件事情，所以我知道我程式寫得很好，架構的很漂亮，可以很有彈性的讓其他人增加新的功能，或是要修改都很容易，也做了我該做的事情，例如：那時候 On Call 我也比較上手，我比較知道怎麼處理狀況，我也知道要開始寫 playbook 這件事情，對於一般工作情況，我覺得應該都是做得不錯，可是為什麼我還是只有拿到 3 分？
這次給我的感覺是很大的失望，因為那時候我覺得我好像完全沒有搞清楚，真正重要的事情是什麼？什麼樣的貢獻才算是有 impact，我們在 performance review 的時候，老闆都會跟你說，或是我們這個 performance review 系統，都非常強調要有 impact 這件事情，要有 impact 才能升職，或是拿到比較好的 rating。
可是從來沒有人解釋過這個 impact 到底是什麼事情，所以那時我非常的困惑，而且也非常失望，對於這件事情老闆也沒辦法給我一個好的交代，因為那時候我的老闆同樣是新手老闆。
Titan：等一下，他其實已經過了一年，還是新手？
vgod：對，過了一年了。那時候 performance review 完，其實我也沒有得到什麼比較好的結果，經歷過第二次的 performance review 以後，那時候我已經覺得蠻挫折的，那時候我甚至也想說如果這樣子沒有辦法在這家公司表現很好，是不是就應該差不多要離開了？還好是那時候剛好我的 manager 決定不要繼續做 manager，轉回做工程師，所以我就換了一個新的 manager 這樣子。
Titan：這樣講比較失禮，但是可能是不錯的決定。
vgod：的確是，沒錯。以 manager 的角度來說，他的確是比較不知道怎麼引導他的 report，或是幫助他們在 career 跟 growth 上面，有一些幫助這樣子，他的確是比較不熟這塊，他做工程師其實是蠻厲害的，可是做 manager 跟做工程師是完全不一樣的工作，他可能也有意識到不適合做 manager，就轉回做工程師了。
突破點
vgod：那時候就換了一個新的 manager，這個新的 manager 其實還蠻不錯的，manager 角度來說，他是第一個 manager 跟我可以很直接給明確的 feedback，跟我說應該要做什麼才是真的對的事情。
那時因為我已經幾乎是想要離開公司了，覺得對我的 performance 並不是很滿意，那時候就開始跟新的 manager 講這件事情，那時也覺得反正我已經沒什麼好失去，就很直接跟他談這件事情，沒有跟他說我要走，我就很明確的問他，我要怎麼樣才可以拿到 4 分？要怎樣才能升職？
他給我很明確的 feedback，跟我說做自己的事情其實做得很好，我可以一個人抵多人用，一個人可以自己做好幾個人做的事情，我自己感覺也是這樣，我就覺得很奇怪，為什麼這樣子不夠？為什麼這樣子沒有辦法得到超過 exception 的 rating？
他就跟我說要做到下一個 level 的事情，變成資深工程師，資深工程師和我在的 L4 的中階工程師，差別並不在於我們程式到底寫得多快或多好，技術能力是次要的，更重要的是我能不能展現出領導能力，能不能帶別人一起做好一個 project？能不能把一個 project 該做的事情，把它切割，切割成別人可以做的任務給別人做，而不是只有我自己可以做而已，我很擅長拿到我們要開發一個新的功能，我可以很快的拿到之後，就 figure out 到底要做些什麼事情，有什麼小任務需要做，然後很快就可以把它做完。
可是我完全沒有去想，我真的應該要做的事情是要把這件事情變成別人可以做的任務，而不是只有我自己可以做而已，我需要跟別人合作，帶領別人做這件事情，其實我不需要自己寫全部的程式，最好的情況應該是我完全不要寫程式，我把拿到的問題的解決方法提出來，寫成一個文件寫清楚，分割成別人可以完成的小任務，讓別人去做這樣就可以了。
他給我這個 feedback 以後，我就有一種如雷灌頂的感覺，他讓我理解到我完全做錯事情，我沒有拿到好的 rating，我沒辦法升職，其實跟我的程式寫得好不好完全沒關係，程式寫的好是基本的，你本來就應該要寫的好，你要升職也是應該要寫得好，可是只有那樣是完全不夠的，需要做一些完全不同的事情，例如：領導一個專案。
我還蠻感謝他這麼直接給我這個 feedback，這個 feedback 讓我了解到要更小心選擇我要做的事情，而且不是只有寫程式，我需要看寫程式以外的事情需要做什麼，我才有辦法真的做到對這個團隊，或是對公司有 impact 的事情。
為你的 1：1 會議設定議程
Titan：你在文章裡面有提到這一件事情讓你學到幾件事，第一個是可以讓你順利進階的關鍵點是什麼，再來是你發現在 1:1 的時候，這種直球的對決是有用的，他對你的幫助很大，你後來在文章有稍微歸納幾點，你覺得 1:1 應該要做的事情，我覺得可以請你跟聽眾朋友，尤其是我們的工程師聽眾分享一下，你覺得其中哪幾點是特別想在節目跟大家分享的，因為我們的聽眾點 Show Notes 連結就直接可以看到原文了。
vgod：那時候跟我這個新的老闆談完這件事情以後，我覺得在 1:1 中，談這件事情是非常有幫助的，我就開始檢討我在 1:1 中是不是也做錯事情，我原本在談的事情是 1:1 的時候跟我老闆報告一下我上禮拜做什麼事情、進度如何、有沒有遇到什麼困難，如果有些困難是他可以幫忙解決，就會特別跟他講一下，就是進度報告。
後來我開始理解到報告進度是蠻沒有用的，而且蠻浪費時間，最主要原因是因為我們團隊本來就已經一個禮拜有一個固定的時間，讓整個團隊報告他們進度，分享他們做什麼事情，讓團隊的所有人都知道，包含 manager，不是只有 manager 而已，你如果在 1:1 中談進度報告，基本上只是跟 manager 講，可是團隊其他人也應該要知道你在做什麼，已經有那個場合可以報告進度，在 1:1 中就完全沒有必要再重複一次。
那時就開始檢討在 1:1 中，應該要談什麼比較好，後來我歸納幾點，第一應該要主導 1:1 的話題，我不應該要進去 1:1 什麼都沒有準備，完全沒有想我應該要做什麼，我開始開了一個 doc，像 Google Docs 一樣 share 給我的 manager，然後裡面放了 agenda，紀錄每個禮拜 1:1 就放一個日期 ，下面就是一些 bullet point，我這禮拜想要討論什麼，我還有一個叫 topic，算是一個 backlog，我想討論的一些事情，不是那麼緊急可是我想討論的話，就放在那個 backlog 裡面。如果時間到了，時間對了，我就把它移到那禮拜想要談的地方。
Titan：聽起來是把它變的蠻正式，把它變得有組織，很有結構的一次談話的方式。
vgod：對，這個 document 還蠻有用的，因為他可以讓老闆知道你是很在意這件事情，而且你想要談的事情，平常就寫在上面，所以他也可以先準備，不是只有你自己準備好而已，他看到你加一個話題，他也可以準備，他如果有話題也可以加在裡面，這是對雙方都很好的事情。
有了這個 doc 以後，就可以開始談一些我覺得比較重要的事情，例如：職涯的發展，我在 career 上面，想要達成的 goal 是什麼？每個人可能有不同的 goal，最重要的是要先設定這個 goal 是什麼，有這個 goal 以後才能跟老闆討論你要怎麼達到這個 goal，中間有什麼 milestone 之類的，不管你是想要升職，或是你想要學什麼特殊的技能，或是你要轉職，轉成不同的，不是工程師以外的 role，像是 PM，或那邊的 manager，這些事情都是應該要跟老闆討論的，manager 最大的工作就是要幫助他的 report 去想他的 career 要往哪裡發展，要怎麼走到哪邊。
我開始做這件事情以後，對自己的幫助的確非常大，從此以後，老闆都會在 1:1 中跟我很明確的直接討論這些事情，給我直接 feedback 還要多做什麼才行，或是我現在做的事情其實並不重要，對於達成我的 career goal 沒有什麼幫助，我不應該要做這些事情，這是第一點，你必須要先有一個 agenda，而且你要主導話題。
再來，在 1:1 中，你必須要能夠跟老闆很透明 transparent 溝通，第一個必須要先建立一些彼此的信任，通常你要先花點時間跟老闆閒聊一下，聊自己的家庭，聊彼此的生活，讓彼此建立一些比較 personal 的 bounding，有這些信任感以後，彼此要互相幫助就會容易很多。
有了信任以後，就可以比較透明的講很多事情，你的 career goal，你想要升職，老闆應該要怎麼幫你，你要升職的時候，很多時候是需要老闆幫你找一些新的機會的，這些機會你如果沒有主動跟老闆講，他不會知道他要幫你找，或是即使有這種機會他也不會想到你，假設有別人表達他們想升職的意願的話，老闆就會先把這個機會給別人，所以讓老闆知道你想升職，或是你的 career goal 是什麼，是非常重要的事情，這樣老闆才能這種機會出現的時候幫你。
跟老闆還可以談的事情，像是不要只 focus 在自己，例如：只談自己的 career goal，從頭到尾只談這件事情也不好，因為老闆在意的事情還是整個團隊，他最重要的目的就是幫整個團隊成功，讓整個團隊可以持續的把這個產品真的開發出來，掌控好這個進度，所以很重要一點是你要讓老闆知道你可以幫他做這件事情，幫他分攤這部分的煩惱或是問題。
我後來花蠻多時間跟老闆談團隊的未來，團隊的瓶頸，團隊裡有哪些合作不順暢的地方，或是有什麼新的制度，我們可以開始嘗試看看，或是現在我會跟老闆說我覺得 meeting 太多了，花太多時間在 meeting，我們應該要減少 meeting 的時間，把一些例如：每週的這種進度 update，把它變成 asynchronous，我們可以在 slack 上面報告就好，不需要真的有一個 meeting 來講這些事情。
把這些事情攤開跟老闆講的話，可以讓老闆知道你其實是一個在意整個團隊的人，而不是只在意自己，你在意整個團隊的話，就可以幫忙 enable 周圍的人，enable 整個團隊，幫他們更容易做好他們的工作，幫他們做一些他們原來做不到的事情，或是可以幫助整個團隊的溝通合作變得更順暢，這件事情對增加自己的 impact 的 scope 有很大的幫助。
以前我在埋頭苦幹的時候，我就是只管自己而已，簡單說就是我完全沒有想到要怎麼幫整個團隊做得更好，或是幫其他人做得更好，只想到自己應該要把這個事情做好，也就真的只做這個事情，我後來理解到，我會沒有辦法得到一個好的 rating，或是沒有辦法升職，最大的主因其實就在這裡，我開始改變這個想法以後，後來 performance review 或升職，就順利非常多。
Titan：有點像是視野、視角打開了，本來比較聚焦在自己本身的狀況，因為跟這個 manager 談過之後，開始注意到應該有其他事情是你要在意的，這件事情跟你的升職，或是你在主管心中的表現是有很大的影響的。
vgod：對。
🚫不要在 1：1 會議談這些事
Titan：我這邊有一個小問題，有沒有什麼是你覺得 1:1 的時候，身為一個 report 你不要講什麼事情，或是不要把這個時間，你剛有提到不要拿來做進度報告，還有什麼事是你覺得可以跟大家講，大家可能在網路上看到很多各式各樣的建議，但是拜託不要真的拿來用。
vgod：我覺得最不要做的事情，第一個就是進度報告，第二個就是不要讓 manager 主導話題，如果你什麼都不準備，你都不想好 1:1 應該要講得話題，manager 其實也不會幫你想，比較好的 manager 他可能會主動的提對你職涯有幫助的事情，可是並不是每個 manager 都這麼好，像我一開始遇到的 manager，他完全沒有提過這些事情，他也沒有想要幫助我設定 career 的 goal，他完全沒有要提什麼事情，如果你讓 manager 主導話題就會變成你要碰運氣，看你的 manager 好不好，來決定你的職涯發展會有多順利。
另外一個我覺得不要做的事情是純抱怨，有些人會在 1:1 中跟老闆抱怨他遇到很多困難，遇到了有其他人不跟他合作，或是他東西做不出來，因為有很多 x、y、z 的各種理由，這種抱怨其實沒有什麼建設性，老闆沒有辦法直接幫你解決問題，老闆的角色比較像是 support 你，幫你排出困難，可是如果是自己在你的 project 遇到問題的話，是可以自己解決的，就應該要自己解決。
如果是在跟其他團隊合作上遇到問題，其他團隊不願意幫助你，這種跨團隊的合作，是老闆可以幫忙處理的，這種事情提出來是很 ok 的，如果只是自己的 project 遇到問題，例如：技術上的問題，你不懂某個東西怎麼運作的，這種東西老闆也沒辦法幫你，因為老闆技術能力不會比你好，甚至在比較大的公司，矽谷的公司，所有的 EM 他們做的事情真的就是 People manager，他們幾乎完全不會碰技術。
團隊通常會把 EM 跟 Technique 分開來，Technique 可能是稍微比較懂技術，你技術有遇到問題，你可以跟 Technique 討論，如果你拿去 1:1 跟 manager 討論，manager 通常也沒辦法幫你，他一定比你還不懂你在做的東西到底是什麼，這種東西跟 manager 討論是沒有什麼用處的，知道跟誰討論這些問題也是很重要的。
Titan：剛剛你有提到 manager 可以幫你處理這種跨團隊遇到的障礙，可能要找他們，因為是跨團隊，老闆可能比較容易接觸到跨團隊的實務，當你有跟他明確的表達職涯想做的事情，他才比較有機會幫你留意說有哪些機會，vgod 在文章裡面也有提到，我覺得大家也可以思考這件事情，我剛這樣聽下來，你做為一位工程師去參加 1:1 的時候，對於自己的職涯應該要有一個想法，才可以擬定這個策略去跟你的 manager 討論，不然他有點像是我想要幫你，可是也不知道要怎麼幫助你，或是甚至不知道你想要做什麼，那他當然沒辦法施力。
接下來，我想要反過來問，請 vgod 跟大家分享一下，一位工程師大概職涯發展方面，對 manager 提供協助的期待，這個我們剛剛其實已經都有提到了，比如組織內部的機會是什麼，要怎麼做才可以升級，進階或者是在團隊發揮影響力，不知道在這之外，還有什麼東西是你覺得一般的工程師會覺得他的 manager 應該要在這種 1:1 或是平常管理的時候要提供的協助。
vgod：manager 最重要的工作，我覺得有兩大塊，一塊就是幫助所有的 report，達到他們 career 的 goal，幫助他們的 career goal，簡單說就是讓他們可以在 career 上面有所成長，這個是可以避免讓他們覺得太無聊，然後就想要離開。
另外一個要想的是整個團隊要往哪裡前進，團隊的 vision 是什麼？團隊的目標是什麼？這件事情通常是 manager 跟 Technique 會一起決定，想這件事情，至於要怎麼分工就是看團隊而定，有的團隊是 EM 主導這件事情，EM 比較有想法，或比較有 vision 他就會花比較多心力在這裡，也有的 EM 是比較技術導向團隊，他可能就會交給 Technique 做這件事情，比較產品導向團隊。
甚至會交給 PM 來做這件事情，因為 PM 就是管產品的，所以 PM 在這種時候，反而會變成純粹的 People manager，把整個團隊的人顧好，確定團隊裡的每個人都很開心這樣就好了，這就是他們最大的工作。所以我覺得對於 manager 來講，可以讓團隊健康的運作，每個人都很開心，如果有人離開了，要補人，要 hire 人，基本上就是 manager 做的事情，把 People manager 這塊做好。
Titan：讓大家開心。
vgod：對，讓大家開心。當然細節說起來，讓大家開心是一件很難做到的事情，因為每個人想的事情不一樣，有的人想要的是更多的機會，可是團隊的機會就這麼多，你要增加機會，manager 就要想辦法讓團隊的 scope 增大，必須要從公司其他地方找更多機會，甚至要去跟其他團隊合作之類的，產生出新的機會，新的 project 可以做，這也是 manager 必須要主動去找才會有的，這些都是 manager 可以做的事情。
可是，基本上一個好的、壞的 manager 程度取決於他讓團隊多開心的運作，如果我們在給 performance review 的時候，我們也要給 manager 評分，manager 的表現完全是看他的團隊給他的 rating 有多好，如果 manager 得到的 rating 也不好的話，manager 也很難待得下去，發現大家都不開心的話，通常 manager 就會要離開了。
Titan：不過，可惜這個部分我就比較不清楚，台灣的軟體公司是不是都有這種雙向的 review 的系統，我比較有自信的是一般的上班族，他們待的公司是沒有這種系統。
vgod：對，這個系統其實我覺得是矽谷公司的一個好處，這個評分不是只有單向的，不是只有老闆對下面的 report 評分，而是你對你的老闆也可以有評分，這個評分是會直接到老闆的老闆，就是 skip level 那裡去的，所以你可以寫非常詳細的 feedback，如果你對老闆有不滿，或是覺得哪裡做得不好，你是可以把這個 feedback 寫出來的。
工程師的影響力：什麼是 Technical Leverage？
Titan：接著，我想要請 vgod 跟大家談談他在第四篇文章裡面講 〈Product vs Infrastructure〉這個部分的內容，我上次在第一集的時候有跟大家提到我對這件事情蠻有興趣的，因為當初在讀那篇文章的時候，發現 vgod 用工程師的技術和影響力，跟前端、後端搭配著講，我覺得蠻有意思的，所以想要請他特別談一下。
這個部分，剛剛有提到影響力，我們今天整集都在講你要發揮影響力才有辦法在 performance review 或在團隊上，讓大家真的看到你，這個部分我覺得可以請 vgod 跟大家分享，剛剛前面在講 On Call 有提到，萬一今天你做的東西是整個公司共用的東西，它在 On Call 的期間出問題，會有一些連鎖反應，這時候雖然是比較負面，但也可以看出這個東西影響力是比較大的。
vgod：我一開始加入公司做的是產品，就是產品工程師，工程師可以做得東西非常的廣，除了產品以外，產品算是最上層的東西，產品也可以再細分，例如：我是做 Web，Web 有前端網頁的介面，一般做瀏覽器看到的東西，HTML、CSS、JavaScript 這種東西，還有後端的，跑在每家公司自己的機房裡面，跑在 Cloud 上面的，這些後端的 server。
在這個之下，還有一層叫做 Infrastructure，Infrastructure 是比較籠統的稱呼，是說所有的基礎建設，可以被很多產品共用，或是沒有特定的目的，是比較一般化，比較 general-purpose 的系統，比較常見的例如：資料庫，或儲存資料的 warehouse 資料倉儲，或檔案系統，甚至是網路的 Load Balance、Proxy，這些在每一個公司都會看到的基礎建設系統，就是共用的系統，這些也是需要很多工程師去做的。
一開始我做的完全是在產品這一層，那時候做產品有一個好處，可以直接接觸到使用者會用的東西，所以做出來的東西很快，ship 出去使用者馬上就可以用了，會比較容易有成就感，可以知道今天做了一個新的功能，馬上就有幾百萬個使用者可以開始用到，這對於做產品的工程師來說，這種 feedback 是他們主要的成就感來源。
如果你是做比較下層的人，例如：做 Infra、資料庫、網路系統、資料的儲存系統，這些東西使用者是不會看到的，一般根本不知道下面有這些東西，做這些東西的時候，很大的缺點是沒有辦法跟外面的人說你在做什麼東西，外面的人很難理解。
用 Twitter 來舉例好了，Twitter 在表面上看起來就是一個網頁，可以打 140 個字，發一個 tweet，也有一個 timeline 可以看到其他人的 tweet，一般人知道就是這樣子-而已，不知道後面其實需要同時 run 幾千台伺服器，甚至是幾萬台的伺服器，去同時支撐這個系統，在這些伺服器下面還有很多的資料庫，資料庫可能也是要拆分成幾百台伺服器，還有很多檔案系統都藏在後面，這些後面的系統可以把它看成一個金字塔，user 看到的部分是金字塔頂端，是一個尖尖的小角，在下面還有非常大的基底，這叫基礎建設，這些基礎建設非常的龐大，也是需要幾百個、幾千個工程師去維護。
我在做產品的時候，只是覺得做產品可以馬上得到 user feedback，好像還蠻不錯的，所以我有新的 idea 可以很快的嘗試，很快知道它會不會 work，可是做了一陣子後，開始發現這個有一個相對的壞處，我做的產品功能如果不是在產品的核心部分，是一個比較少人用的功能，以 Twitter 來舉例，Twitter 裡面可能有一些使用者管理的功能，例如：改使用者名字，或是換你的頭像，不是最核心，大家比較不會去用到的功能，被使用到的機率會比較低，甚至是一些實驗性的功能，這些東西有點一翻兩瞪眼，如果很多人用的話，當然就會有很大的 impact，很少人用，impact 就少。
可是，這些東西多不多人用，跟 engineer 沒有很大的沒關係，因為產品的 feature 通常是 PM 還有 designer，PM 決定這個東西優先順序有多高，這個功能有多重要，決定要做了以後，designer 會去設計出應該要長什麼樣子，engineer 再把它做出來，有很大部分是 engineer 不能控制的，這個 feature 到底好不好用，或能不能吸引到很多人來用，對 engineer 來說就是施不上力，我們沒有這個 leverage。
另一方面，如果你的功能沒有很大的 impact 的話，你在這個團隊裡的 impact 就不大，因為很少 user 用，這個功能相對就比較不重要，甚至團隊最後決定要把它砍掉，你寫的這個 code，就等於會被砍掉，他就已經沒有用處了。
這個東西對於其他的 engineer 來說，他們就比較不需要依賴你，他們做他們的 feature 的時候，做他們的程式就好了，你寫的程式基本上只有你自己會看到，你自己會用，對其他人來說沒有什麼影響，中間是沒有相依性的。
可以牽扯到 Technical Leverage 的概念，Technical Leverage 是你可以多容易透過你的技術，或寫出來的程式產生影響力，如果是做最上層的 product 的話，很難有 Technical Leverage，因為你寫的程式不會被其他工程師重複使用，你寫的程式就是拿來服務使用者，如果使用者不用的話，你這個程式基本上就沒有用了。
如果想要增加 Technical Leverage，應該是要往下層移動，即使是在做產品，產品中有一些共用的部分，即使做前端，前端階有很多程式碼是可以共用，例如：你要 create button、create menu，這些東西都會有一些共同的 utility 函式可以使用，這些 utility 函式是需要工程師去寫的，如果你是寫這些東西，就比較會有 Technical Leverage，因為你寫的那些函式，別的工程師都要共用它，所以你寫的東西就比較容易在這個團隊裡產生 impact。
如果你再繼續往下走的話，是走到 Infrastructure 這層，你做的東西是整個公司共用的資料庫，這個東西的 Technical Leverage 就更大了，因為在這個資料庫裡面，只要稍稍改動一點，增進讀取效率好了，整個公司所有的產品，只要用到這個資料庫的，速度都會提升，你的 impact 就會馬上影響到上面所有用的產品，當然會間接影響到使用者。
在一般軟體公司裡面，如果是做越下層的系統，Technical Leverage 就會越大，就越容易透過程式碼、技術，產生影響力。相對的，如果是在上層的話，你做的東西就是非常 specific，我們說 Business logic，常常在產品裡面寫的，要針對產品功能寫特定的 logic 去滿足使用者需求，這些 logic 可能也不是自己決定的，是 PM 決定的，或是 designer 決定的，所以你的 Leverage 就相對比較少。
理解到這件事情以後，我就開始覺得如果想要真的發揮影響力，應該要往下層移動，應該要去改做比較底層的東西，做 Infrastructure 的東西，這個東西可以給我比較好的 Technical Leverage，我一樣可以專研技術，可是做出來的東西比較容易影響到公司其他人，至少同個團隊，甚至其他團隊的工程師。
Titan：我剛聽起來像是回扣到你以前講的東西，你那時候剛進這家公司是專心在做跟使用者比較靠近，你寫的東西是自己做，我記得你在文章裡面有提，你前後端都可以寫，所以你一個人就把這個東西做完了，但就像你在文章裡面提到的，跟商業邏輯有直接關係，或是直接面對使用者的東西，你很難把它轉移到別的地方去，可以這樣講嗎？
vgod：對。
Titan：像你講的，Technical Leverage 比較難發揮，你現在發現往下走。
Product Leverage
Titan：我看你在文章有提到另外一個是相對於 Technical Leverage，另外一個叫 Product Leverage，直翻叫槓桿，我想不出比較好的翻譯，我們就叫 Product Leverage 好了，這部分是專屬於產品經理或設計師的嗎？還是前端的工程師也可以往這方面發展？還是以工程師來說，就真的只能往下去發揮他的響力？
vgod：這有點看公司的 culture， 基本上在做比較產品方面，或是前端方面東西的話，前端工程師是可以有這個 Product Leverage，這個取決於你有對這個 product 有多強烈的 意見，我們叫 opinion，如果你對這個產品本身有很強烈的 vision，你覺得這產品應該要長什麼樣子，應該要達到什麼功能，這些功能的運作方式應該要是什麼樣的話，這個是可以在決定做這個 feature 的時候，跟 PM 還有 desinger 一起溝通的，有些人的確有這種 vision，對這個 product 有強烈的熱情，所以在這方面的話，他是可以發揮 Product Leverage，可以影響 product 走向的。
像我當時加入的時候，我對這個 product 並沒有那麼強烈的熱情，對於這 product 來講，我覺得是一個很苦的 product，我心中沒有一個 vision，這個 product 應該要長什麼樣子，一方面也是我對這 product 還不熟，另一方面是這 product 並不是我有熱情的地方，也間接造成我在做 product 的時候，我很難有 Leverage，很難提出我覺得應該怎樣做比較好，或是怎麼樣做比較對。
如果是有 product vision 的人，是可以在這方面發揮很大的 impact，否則我完全覺得是看人，有些人想轉職成 Product Manager 或是 Design Marketing，這種人就很適合直接做產品，因為他在做產品的時候，可以跟其他不同領域的人互相合作、溝通，可以學到其他領域在意的事情，甚至對他以後要轉職有所幫助，這個在做比較底層 Infra 是不會有機會的，Infra 的 team 甚至不會有 PM，不會有 desinger，全部都是 engineer。
知道公司的「生意」是什麼
Titan：我會問這一題，當然是希望如果有聽眾是做前端的工程師，也不要因為聽 vgod 這樣講，就想所以我的影響力很小嗎？影響都在 PM 跟設計師手上，不見得是這樣。
我覺得可以一起問的是之前 vgod 有談到，像在 1:1 的時候他有說也可以跟你的 manager 了解這家公司在做什麼事情，這個概念在蠻多網路的文章或書裡面都有提到，Netflix 希望整家公司所有人，從最直接面對客戶的，從客服到底層的工程師，最好都可以知道公司是靠什麼維生，才可以讓他們從根本了解自己的工作，對整家公司的貢獻具體是什麼，自己的工作做得好，對公司會有什麼影響，類似像這樣子。（《星箭廣播》43 集 —— 矽谷重要文件特輯：Netflix 超狂的「自由與責任文化」投影片 | Star Rocket Blog）
我也想請 vgod 跟大家談一下，對工程師來說，了解整家公司在做什麼，他的重要性，或對你的工作，對你在這家公司、這個團隊工作上會有什麼影響嗎？
vgod：簡單說，即使是工程師，也應該要了解公司的產品是什麼，第一個是公司 Business model 是什麼，公司的產品為什麼有這個存在的價值，為什麼在市場上會被使用者接受，可以有他的一席之地，這點很重要，如果你是做產品的人，才能根據這個去選擇你要做的事情。
一個產品工程師，某種程度來講，可以選擇你想要做的 product 的 feature 是什麼，這件事情很多人都覺得做產品或工程師，就是被動的接受上面指派的任務，可是這件事情在大部分公司，至少矽谷的公司是都可以談的，可以跟老闆討論，或跟 PM 討論什麼東西的 quality 應該要比較高，我們應該要做那個，不應該要做這個，只了解公司產品在做什麼，或公司的 business 怎麼賺錢的，你才能知道做什麼東西的 impact 比較大。
product 工程師最重要的是你選的事情要對，你做的 product feature 都不對，做到一個沒有人用的東西，做到一個 feature 最後被砍掉的話，這段時間就等於是白做工，很重要的一點是選擇你要做的 feature 是什麼，這點甚至可以往下推到做 infra 的工程師，做 infra 工程師也有需要了解 product 的點，最主要原因是現在的 product 非常的複雜，尤其在很大規模的公司裡，需要能夠支持非常大規模的使用者，這些大規模的使用者會產生非常大量的資料，非常大量的流量，做 infra 的要找方法去承擔，這些大規模的流量或資料。
在這點了解產品本身有很重要的功用，可以知道這些使用的 pattern 是什麼，可以針對不同使用的 pattern 做不同的最佳化，像 Twitter 是一個大部分使用者都在讀，非常少人在發 tweet 的平台，是一個讀取很多，寫入非常少的平台，如果你是做 infra 的人，要最佳化的點應該是讀取的流量，而不是寫入的流量，因為寫入發生的機會少很多。
不同的產品會有不同的特質，有的產品反而是寫入很多，可是讀取比較少，你必須要能夠根據產品的特性了解使用者是怎麼使用這個東西，這個東西的 pattern 是什麼，才能跟著這個去做最佳化，不管是做哪一層的工程師，了解產品本身都是很有價值的。
Titan：我之前在聽一個 podcast，有聽到前 Uber 的 data engineer，他提到當時他們在做這件事情，在處理 data 的時候，有注意到一個 pattern，大家可能會覺得底層，或這個系統效率要越高越好，越快越好，最好使用者想要叫車，叫一台 Uber 的時候，最好直接可以顯示一分鐘馬上就會到的，車輛也要顯示出來，最好優先派給這位使用者。
但其實不是，因為一分鐘太短了，很多時候會造成乘客根本就來不及到定點，司機到了也不等他，雙方互相給劣評，整個使用體驗是差的，所以幾乎不會去媒合最快速、最短時間的車輛跟乘客，我猜 PM 應該最清楚，但工程師如果知道這件事情，他在做這件事就不會一開始就來個效率最高的，直接把他寫到滿這樣子，這樣對產品的體驗是扣分的，我不知道這是不是可以做一個類似的舉例。
順著了解整家公司在做什麼，或產品，或某個功能的特性對前端、後端的影響之外，還有一件事情是大家很自然會問工程師需要會使用自己家的產品嗎？我覺得這個問題，沒辦法有很明確的答案，原因是有些產品並不是工程師想用就用，應該可以這樣想，這種規模很大的，或很特殊的產業，並不是工程師說今天想要試試看，他就可以用，很多時候是不行的，但我想請 vgod 從他自己的角度來談一下，工程師需要會使用自家的產品嗎？
vgod：我自己覺得如果你就是使用者，你可以是使用者就應該要用，有句話說你要 eat your own dog food，要吃自己的狗食，才會知道這個狗食好不好吃，用自己的產品才會知道你做的東西到底好不好用，這是跟使用者體驗有很直接關係的，如果你自己都不用的話，有很多使用者平常會經歷的一些 pinpoint 是不會知道的。
這些 pinpoint 需要越多人發掘越好，不能依賴只有 PM，或是只有使用者給你的 feedback 才去改這些東西，因為使用者給你 feedback 的時候都已經太晚了，可能有一百個人遇到這個問題，只有一個人會給你 feedback，他真的會有心花時間給你 feedback，大部分人會覺得這不好用就不要用了，就直接走了。
用自己做的產品可以幫助你很早發現這些事情，這是做產品的人一定要做的，當然這也取決你做的產品是什麼，因為你做的產品不是一般人會用的，不是 consumer 的 product，是給 business 用的，如果你又不是那個 business 的人，是沒有辦法用，像 Salesforce，做的東西是 CRM，customer relation 這個東西基本上是 sales 才會用，工程師完全不需要用這個東西，這樣就很難叫工程師去當第一線的使用者，或是白老鼠去測試，這就跟公司的產品有比較大的關係，如果你的產品是一般人可以用的話，我覺得工程師是應該要親自用看看。
Titan：像我們剛剛講的 Twitter，應該就是對不對？
vgod：沒錯。基本上 consumer-facing 的東西，工程師應該都可以直接用的，只有一些 business product 可能是工程師不會用的。
Titan：不知道現在有沒有很多工程師要去做編輯按鈕這個功能，擠進去這個團隊。
vgod：Twitter 現在做 Code Freeze，在他們收購完後，他們把整個 code 的 repository 關掉，大家都不能改一些 code 進去，要改的話需要一些 VP的同意才行。
Ending
Titan：原來是這樣，我們今天非常高興再度邀請到 vgod 還有他的狗，我們在這一集跟大家談一開始初階工程師比較容易遇到的狀況是什麼，具體一點來講是 vgod 有跟大家分享他 On Call 的經驗，還有他剛加入現在這家軟體公司的狀況。
以及第二部分，我相信應該蠻多聽眾很關心，還有 vgod 讀者也很關心的，〈1:1 該談什麼才能讓職涯起飛？〉在職涯發展遇到困難的時候，可以透過什麼樣的方式讓團隊的 manager、老闆協助你。
第三部分就是剛剛講的，工程師要怎麼透過技術去發揮他的影響力，往上走、往前端走、往後端走，我們都有談到，這個部分跟接下來第三集要跟大家談的 TechLead 還有IC （Individual Contributor），也就是 vgod 自己選的職涯發展的這個路徑，第三集會集中討論這幾個問題。
包含 TechLead，剛剛大家聽 vgod 在講，應該也有聽到在比較大的團隊，或比較大的軟體公司，所謂的 EM（Engineering Manager）跟 TL（TechLead）是分開的，也就是 TechLead 不會有這種管人的權力，如果沒有這種管人的權力，沒有這種 authority，他要怎麼發揮影響力，要怎麼用技術去推動，讓整個團隊去相信他，這就是我們下一集要請 vgod 跟大家聊的話題，再次謝謝 vgod 來上我們節目，我們下一集見，Byebye。
vgod：謝謝大家，Byebye。
（文章代表圖並非 🐶 本人，來源：Elisei Abiculesei on Unsplash）
本文為《星箭廣播》159 集——工程師，你的 1:1 會議都怎麼談？（ft. vgod & 🐶） 訪談逐字稿。本集節目介紹與相關連結請到此頁面閱讀。
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出