本訪談錄製於 2020 年 4 月。Michelle 是 Stripe 的支付產品技術主管（Payments Products Tech Lead）。

目前的角色#

我是 Stripe 的支付產品技術主管，直接與我們的產品長（Chief Product Officer, CPO）共事。我支援關鍵計畫、協助處理跨組織的緊急問題。通常我把 80% 的時間投入在一到兩個大型跨組織的設計專案上，剩下 20% 用來審查與支援全組織的技術與產品設計，特別是 API 設計。

我還帶兩位工程師，讓他們嵌入高優先領域。這既幫助我放大影響力，也讓他們有機會接觸 Stripe 的許多面向。我仍然是用 IC（個人貢獻者）階梯來評估的——計畫是永遠不要同時帶超過幾位下屬。

Stripe 有兩種 Staff-plus 工程師：

• 深度型（deep-scoped）：某個特定領域的主題專家，主導雄心勃勃的多年期專案，多半出現在產品基礎架構與系統團隊。
• 廣度型（broad-scoped）：透過處理模糊、跨組織的專案來創造影響力，累積跨領域的大量脈絡，在許多專案裡扮演支援角色，最常見於產品工程團隊。

在哪裡最有影響力#

隨著我進入現在的角色，這個答案一直在變。（背景補充：支付產品由 20 多個團隊組成，負責我們大部分面向使用者的 API 與 UI 函式庫。）

我漸漸改用「有能量（energized）」取代「有影響力（impactful）」。「有影響力」偏向以公司為中心，而「有能量」更向內看。找到讓我有能量的工作，正是我在 Stripe 待這麼久、持續追求有影響力工作的原因。

以前直接在團隊裡時，能直接和使用者互動最讓我有能量——無論是在 #stripe IRC 頻道上幫助使用者，或設計並交付一個能無縫整合的 API。現在，當我贊助（sponsor）的人宣布交付了成果，或當我幫忙形塑、扭轉了一個工程團隊對某個重要主題的理解模型時，我最有能量。真正每天做建置與支援苦工的是這些團隊，不是我。我用他們的進展來衡量自己的影響力，更重要的是那進展的方向性，以及他們的工作與公司目標的一致性。

我花時間參與 API Review 等審查論壇，但這些論壇往往更像 code review：發生在設計流程太後期，比較能防止壞結果，卻不太能與團隊協作、導向好結果。當我能給產品團隊的工程師工具去設計出好的 API 時，我覺得更有影響力。

有了頭銜之後的改變#

我在 Stripe 很久了（2013 年就加入！）。雖然年資一直給我一些份量，但支付產品技術主管這個角色（加上我直接向 CPO 匯報）確實改變了人們與我互動的方式。我現在在工作上明顯更孤單了（也正在努力適應這個新常態）。

有件事要花點時間習慣：現在無論討論什麼，大家都預期我要有意見！

有點令人迷失的是，比起我不在這種顯眼角色時，現在有些人更認真看待我的意見、對我更客氣。以前有些人不願協作、或會忽視我的意見，我覺得經歷過那些是好事——當時我夠自信（也夠受組織信任），能對他們的協作方式給出強烈回饋，確保這種事不會發生在像我這樣的其他人身上。我現在反而擔心，自己正失去對這些互動發生在哪裡的能見度。

少寫程式後，如何維持同理心#

進入新角色才一年，我還不覺得太脫節。為了維持脈絡，我花不少時間和第一線執行的工程師與 PM 做一對一——光這週我就有 12 場 30 分鐘的一對一。我也追蹤 Stripe 每一起事故（incident）。

事故的「嗡嗡聲」特別值得傾聽。細讀每起事故的細節，我能估算出系統的現實，和我整天在思考的理想化架構／產品之間的距離。我把自己看成工程師在領導層面前的倡議者，所以深入理解當下的現實對我很重要。

倡議與推動改變#

現在我花較少時間去倡議特定技術或方案，更多時間是賦能他人去倡議他們認為重要的東西。理想的結果是我們在方向上取得一致，然後他們能在自己團隊裡倡議我們的北極星、做出好的在地決策。

我手上的專案很難這樣做，因為它牽涉為非常多團隊定義理想化的架構與介面——基本上是每個做支付的團隊！連寫文件（散播資訊最可擴展的方式）都很難，因為不同團隊本來就從不同角度切入這個介面。

我們現在把文件審查當成使用者測試：觀察團隊成員讀文件時游標移到哪、對什麼有反應。目前效果不錯！

對有企圖心的設計專案，我發現極度透明、同時明確標示你是否已準備好接受回饋，很能打動在意這個主題的人。

贊助其他工程師#

是的，這是我最喜歡的部分之一！我很在乎共事的人——他們是我有能量去上班的主要原因。

對我來說，贊助的一大部分是為 IC 創造空間，讓他們去做自己在乎、有影響力的工作。現在的角色讓我不必花時間證明自己稱職，所以我能花很多時間扮演支援角色、抬升他人。我很少覺得必須「爭功」或在署名上被提及（雖然發生時感覺總是不錯）。

日常中，我發現自己能當個「小黃鴨」，幫想在複雜專案中導航、或化解技術分歧的人。這種在不直接介入的情況下幫別人取得進展的工作，特別有成就感。

我也總在心裡記著一份名單——那些在自己領域超級厲害的人，當符合他們興趣的顯眼機會出現時，我會為他們倡議。不過這裡有個平衡。

我學到，有時人們很難對我說「不」。最近我請一位工程師寄封信介紹她做的好工作，她寄出後告訴我，其實她本來不想做，但也不想拒絕我——還給我看了她「拒絕日誌（no log）」裡的相關條目。位高權重時，你的請求會被當成不容拒絕，要小心。

到達 Staff 的路徑#

我大學一畢業就加入 Stripe。剛進來時，我的成長曲線其實比同梯工程師慢——頭四年相對緩慢。部分是因為我寫程式的時間還不長（2011 年才上第一堂程式課，2013 年就加入 Stripe），部分是因為我在 Stripe 的第一個大專案是個 1.5 年、最終被取消的重寫專案。

Stripe 剛導入職級時，我已經進公司兩年半，被評為 L2——一個我們預期應屆畢業生 6 到 18 個月就達到的等級。老實說我相當失望，因為同儕已經到「資深工程師」了。

回頭看，以階梯來說 L2 百分之百公平。我努力又常加班，是因為經驗不足、寫好程式天生比別人慢。我當時穩穩是個高績效的 L2。

較軟的技能、跨公司的連結、對使用者的關注、對產品的深入理解——這些花了更久才學會，卻在我打好技術基礎後，最終加速了我通往 Staff 的路。技術能力可以在有意識填補缺口、挑戰舒適圈的專案中有機地累積。

Staff 專案#

我在 Stripe 幾乎每個產品元件上都廣泛工作過。有兩個我在資深工程師時做的專案或許夠格稱為 Staff 專案：Stripe Radar 與 Stripe Elements。

• Radar：從零打造全新產品，審慎取捨該建什麼、能安全砍掉什麼，好盡快交付。2016 年 10 月上線，是我們最順利的產品發表之一，此後成為非常成功的產品。
• Elements：我建了基礎設施、從零設計最初的 Card Elements API，三個月內上線。這只有靠大量 dogfooding 才可能——我用不同設計框架做了三家小電商店，測試客製化 API 的極限。

回頭看，兩個專案的產品架構自上線以來大致都撐住了。

我認為這是產品領域 Staff-plus 工程師的重要標準：不只是建出能上線的東西，而是讓它順利推出、隨時間持續成功成長，且盡量少有令人後悔的選擇。Staff 產品工程師會刻意地做出產品與技術選擇，代入各種使用者人物誌，並為未來的工程師徹底記錄粗糙之處。

升遷包（promotion packet）#

升 Staff 時，我很幸運有位極力支援我升遷的主管。老實說，當時我不太懂怎麼正確寫自我評估——我寫的是未來一年想學什麼的自省式發展計畫，而不是記錄我的工作影響力與範圍。實際上是我主管在他的評估裡把我的影響力寫了出來。

有幾件事幫上忙：第一，我大部分時間都跟同一位主管，換主管會讓對方失去脈絡、把建立連續性的工作推給你。第二，我主管帶的團隊相對小，能花很多時間掌握我在做什麼的細節。若我是向一位帶 10 多人的主管匯報，大概就得在自己的升遷包上付出更多。

到達 Staff 最重要的因素#

一個可能出人意料的重要因素是（也一直是）我的冒牌者症候群（imposter syndrome）。它讓我格外樂於接受回饋、學習成長，並為任何和我工作沾上邊的事負責。如果有什麼壞掉了（無論技術或組織上），我會不安，並有深層的內在動機去了解、修好它。Stripe 產品的任何一部分都不是「不干我的事」。這發展出兩種或許比技術超能力更重要的超能力：

1. 真正傾聽並同理他人。
2. 對解決各類問題有深切的在乎。

冒牌者症候群是雙面刃。它常讓我害怕、自我意識過剩——早期我不斷覺得自己會因為不夠快、不夠有效而被開除。我隨時間變得更篤定，但坦白說，這花了很多時間，以及來自主管與公司領導者的正向回饋。

產品工程比基礎架構更難到 Staff 嗎？#

我認為確實如此。不過在 Stripe 稍微容易些，因為核心產品本身就是基礎架構，產品工程裡有很多需要考量規模、韌性、遷移路徑、良好介面設計的專案。

若你在主要做 UI 的團隊，要到 Staff 確實棘手，因為 UI 產品本質上較短暫、允許更多迭代與實驗。要在 UI 團隊達到 Staff 等級的影響力，你需要能創造槓桿——例如打造設計良好的元件庫、實驗框架等。

產品工程師建立槓桿的另一面，是建立管理「產品債（product debt）」的流程與系統。大家常談「技術債」，但支援舊版產品所造成的產品債同樣重要。我相信一家公司累積的產品債，會在一定規模後創造出產品工程內的 Staff 級複雜度角色。

幾則建議#

關於一般性建議：我沒得到太多通用的好建議，得到的多是綁定當下情境的具體建議。對我最有用的通用領悟，是「與不確定性共處」變得自在。在資深角色的持續成功，取決於你能否隨組織需求改變而調適、成長。

給想成為 Staff-plus 工程師的人：別以會把你導向你不喜歡之工作的方式去做模式匹配（pattern matching）。去追求讓你有能量的工作，即使紙面上看起來不像能帶你到 Staff。作為 Staff-plus 工程師，很大一部分的成功是能辨識並界定全新的、有影響力的工作，並說服他人相信其價值——如果工作讓你有能量，這反而容易得多。

給剛上任的 Staff-plus 工程師：你的工作是特定於你的團隊與組織的，要避免採納不適用你情境的建議。例如我剛上任時，許多深度型工程師專注於寫描述未來 1 ～ 2 年目標的個人章程（personal charter），但這對需要快速回應組織變化的廣度型工程師（如我）沒那麼有幫助。

關於工程管理#

我現在確實帶兩位工程師，但不做很多傳統管理者會做的事——不像招募主管那樣參與招募，也不太經歷同樣的績效管理情境，因為進我團隊的工程師已經是高績效者。

我非常在乎 Stripe：看到不對勁的地方我會坐立難安、想修好它。在某些組織裡，這或許會把我推向工程管理，而我很感激管理不是唯一的路。我的強項與興趣在產品工程與 API 設計及執行，而我每天都能用上這些強項。

學習資源#

• 我愛讀小說，從偉大的文學裡學到很多關於世界的事，不太喜歡讀非虛構的商業或技術書。
• 對更直接相關的主題，我珍視同儕關係——他們給我即時回饋，幫我把腦中一直有的答案挖出來。
• Stripe 有個「Leadership In Practice」課程，其中一堂關於調適型領導（adaptive leadership）特別有幫助。
• 我從不是那種只找單一導師的人，而是採「科學怪人（Frankenstein）」式、自組導師的方式，類似拉臘·霍根（Lara Hogan）寫的「打造你的管理者 Voltron」。