本訪談錄製於 2020 年 8 月。Katie Sylor-Miller 是 Etsy 的前端架構師（Frontend Architect）。

目前的角色#

我在 Etsy 工作，這是全球最大的手工商品線上市集。我目前在前端系統（Frontend Systems）團隊——一個負責前端架構（含我們的 PHP 視圖渲染框架）的產品基礎架構團隊。不過近幾個月我專注在 Web 效能上，扮演顧問角色：改善監控與報告系統、辨識可改進之處，並隨時協助產品團隊處理效能相關問題。

Web 效能是許多公司忽略或不重視的領域。Etsy 曾有很好的效能文化（多虧了拉臘·霍根 Lara Hogan 這些人），但幾年前的組織變動後我們不再有 Web 效能團隊，整個組織有點吃老本、降低了它的優先級。現在我們把它重新拉回前線，因為業界對「好效能」如何定義與衡量有很多變化，尤其在 SEO 上——Google 正大力推動把 Web 效能納入搜尋排名的標準。

「正常」的 Staff-plus 工程師：技術主管 vs. 架構師#

我覺得有趣的是，我們把兩種「變資深」的方式都塞進「staff engineer」這一個桶子，但其實是兩個不同的桶子：

• 技術主管（tech lead）：透過成為某個主題領域的專家而變資深，驅動所屬團隊或組織的技術方向與路線圖。
• 架構師（architect）：擴大工作範圍與焦點，思考跨領域、跨團隊的問題，驅動跨多個團隊運作的系統與實務的建立。不是說你不是主題專家，而是你的影響範圍比為單一團隊當技術主管更大。

Etsy 有幾個資深層級：Senior Engineer I 與 II，接著 Staff I 與 II，再來是等同總監（Director）的 Senior Staff。我技術上是 Staff Engineer II，也這樣看自己，但我的具體角色是前端架構師——這意味著我不只負責自己團隊在做什麼，而是負責看整個 Etsy 在前端領域在做什麼：未來長什麼樣？我們需要解決哪些問題？如何抵達那裡？並在公司層級倡議能帶我們抵達的技術方案。

架構師還寫程式嗎？#

有趣的是，我是前端架構師，但近來寫最多的其實是 SQL，因為我在做大量資料分析——看效能指標、找出最值得修、最能改善效能與業務指標的問題。我這裡那裡寫一點 JS 或 PHP，但多半是為了幫團隊解阻塞、跑小型效能實驗，或有重要但別人沒空做的事。

隨著行事曆被會議填滿，我明顯變慢了，也更難找到專注時間寫程式。所以你大概不會想要我再寫太多程式了！我更聚焦於辨識機會，然後把它「賣」成我團隊或其他團隊該做的工作。

如何衡量影響力#

坦白說這是我非常掙扎的事。我隨時有一堆不同的專案與討論在進行，又有容易被最新鮮的事吸引、注意力游移的壞習慣，所以我必須非常刻意地組織我的工作與筆記，總在思考我可能做的所有事裡，哪件是當天最有影響力或最重要的。

直到轉為架構師，我才意識到我以前多依賴 sprint、JIRA 看板，以及「完成一張票、把它移到 done 欄」的儀式來自我確認有在完成該做的事。現在沒了那種團隊脈絡，我得更依賴自己的待辦清單。

一件確實有幫助的事，是追蹤我每天完成的所有任務——記錄會議、email、Slack 討論等。等到和主管做季度目標檢視時，回顧筆記才發現：哇，我幫工程師修了六個不同實驗的效能問題、影響某團隊採取更好方向、給了某工程師有幫助的回饋。這些當下感覺不多的小事，加總起來顯示出真實的影響。

在哪裡最有影響力#

我最愛做的，是辨識一個前所未有、獨特的問題，想出一個瘋狂的點子去解它，然後我才華洋溢的同事接下這點子、真正把它跑起來，做出很棒的東西。它始於吸收大量的輸入——看到這團隊做 x 有問題、那團隊做 y 有問題，把這些輸入混上你的經驗與整個產業的動態，讓它在腦中沉澱一陣，直到某刻全部咔嗒對上，你意識到兩個問題底層更深的共因是 z，於是想出一個計畫去修那個很難修的問題。

前端也能為公司創造槓桿嗎？#

當然可以。我個人只認識少數幾位前端專門的 staff 工程師，我認為前端這項技能在業界沒有得到它應得的重視。但成為 staff 工程師，好的 staff 工程師的特質是超越你在哪一層 stack 工作的——staff 工程師需要能把工程決策想成一系列取捨，而清楚闡述這些取捨的能力，從 stack 的任何視角都能擁有。

Staff 工程師應對自己專長的所有相鄰領域有廣泛理解。以我做前端為例，我投入大量心力理解行銷、業務目標、使用者體驗、視覺設計、伺服器端的視圖與業務邏輯層、如何把程式碼送到瀏覽器、瀏覽器如何把程式碼變成網站、以及使用者如何與之互動。擁有這些領域的專長，讓我更容易看見技術決策的更廣影響、更好地理解取捨。

對使用者有同理心尤其是所有工程師都該培養的重要技能，而它在許多不理解「他們其實也有使用者！」的基礎架構或開發者支援組織裡常被低估。我在前端基礎架構工作，我們真的把自己看成產品工程師——只是我們建的產品是給其他工程師用的系統。我們有客戶、有使用者，設計系統的 API 時，我們是在為使用者（也就是產品工程師）設計，必須理解他們才能做好。所以我認為偏前端的人能成為很棒的 staff 工程師，因為他們太習慣不斷思考使用者了。使用者同理心是前端人帶到檯面上的超能力。

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

Networking、networking、networking、networking。一對一特別重要，因為我是全職遠距。作為一個「不完全分散式團隊」裡的遠距者，你必須非常留意你在和誰交談，確保你在多個團隊與群體間都有連結，好善用這些網絡。

• Etsy 有幾個員工資源小組（ERG）。我在科技領域邊緣性別身分社群（MAGIC）相當活躍，很棒的是這社群裡有人在工程的每一個部門工作。遠距員工社群也是。
• 我抽時間指導較資淺的人、做定期一對一、參與 Slack 討論來培養這些連結，因為對組織正在發生什麼「把手指按在脈搏上」幫助極大。我也特別努力和產品工程的工程師交談，因為他們是我們的客戶群。
• 我正努力改進的一件事，是更多地與經理們建立連結。長期以來我在 IC 軌內有很好的網絡，近幾個月則努力擴展到更多工程經理——因為我的工作常需要「無權威的影響力（influence without authority）」，我不自己做決定，而是試圖影響別人做的決定，而很多時候，經理才是最終拍板的人。

贊助其他工程師#

我很幸運在 Etsy 和拉臘·霍根共事幾年，她談了很多關於贊助（sponsorship），而作為科技業女性，我親身受惠並看見它的價值，所以我投入很多時間精力在這上面。

升上 Staff 的過程#

我以資深工程師身分被聘（當時我們不從 Staff 頭銜招人，後來政策改了）。來 Etsy 前我已在業界工作近十年，但多在較小、較不知名的公司，並已當前端技術主管五年多，所以我對技術主管這角色已駕輕就熟。

但來到 Etsy，範圍比我以前見過的大得多，工程部門比我待過的任何一個都大上好幾個數量級。我有很多要學，關於在真正大的規模下運作、以及它和小公司有多不同——我學會更留意看資料，甚至自學基本統計來理解實驗框架。

從一開始，我就總在四處尋找可以改進的地方，主動說「嘿，我們沒在做這件事，我們應該要做」。

我認為讓人到達 Staff 的，很大一部分是注意到問題並主動採取行動去解決，而不是放著不管。

我在 Etsy 待了不到兩年就升上 Staff。當時我的主管是全新的、不了解我的過往，所以我們非常緊密協作地一起準備我的升遷包。我聽過「主管主導」與「IC 主導」兩端的經驗，很慶幸我自己是升遷流程的一大部分。

尤其身為遠距者，除非你主動，很多工作可能無人注意——因為它發生在 Slack、PR 或文件裡，不在經理習慣觀察的公開場合。你永遠是自己最好的倡議者，而這對遠距者更是如此。你必須付出很多努力，確保你的成就被看見、被知道。

到達 Staff 最重要的因素#

創意、主動、同理心我已談過一些。我談得不夠的是溝通與透明。升上 Staff 很大一部分是確保你的工作可見、人們知道你的名字、你有好名聲。

我很幸運在建前端基礎架構的團隊，我們自然會寫很多 email 給全工程部門，所以能見度高。但基礎架構更大一部分是客戶服務——幫助進到你 Slack 頻道問問題的人。我回學校念完資工前，在服務業做了好幾年，我總試著把當時學到的客服心法帶進每次互動：讓自己可及、保持謙遜、專注於真正聆聽與理解別人的需求。當你真心在乎幫助同事時，是看得出來的。

Etsy 特別擅長培養 Staff 工程師嗎？#

老實說我不太清楚別家公司的 Staff 工程怎麼運作，所以完全有偏見！我認為 Etsy 擅長培養 Staff 工程師，是因為我們有強調技術卓越、結合無咎責（blameless）文化、以及想對更大世界行善的強大內部文化——這帶來既聰明又善良的人，而聰明加謙遜的組合造就了很棒的 staff 工程師。這種環境會自我餵養，創造好榜樣與想效仿他們的人。

但要記得，有很多較小、較不知名的公司裡，有很棒的人在做 Staff 工程類型的工作，只是不叫 staff 工程師，而是以其他方式被認可為技術軌領導者。在許多公司，強的技術主管會變成經理，甚至可能沒有 staff 工程師這種角色的概念。在大公司裡很容易卡在「Staff 頭銜是終極目標」的執念上，但要記得，成長職涯的方式有很多種。

給追求 Staff 的人的建議#

我被提名 Staff 升遷兩次都沒過，第三次才成。最終推動它的，是我在總監那裡有個好贊助者。

我的建議是：務必發展你的網絡，開始和你的總監或 VP 見面，因為做「你是否升遷」這個決定的正是這些人——不是你的同儕，也不真的是你的經理，而是這另一群人。你要讓他們知道你的名字與工作。在升遷討論時，你希望他們想到：「喔，是她發了那封關於這專案的全工程 email。」或「我常看到他在 Slack 回答大家的問題。」

當人們（尤其女性與非二元者）來找我建議時，他們常以為我會談如何成長為技術領導者，卻很驚訝我說：「你的技術本領大概已經有了，你需要做的是經營你在公司裡的名聲。」不論好壞，沒有好名聲你到不了 Staff。人們想要或期待它是任人唯才制，但它真的不是——有太多因素影響拿到 Staff 級角色。

駕馭資深角色的不確定與模糊#

有個誤解：你以為成為 Staff 工程師後就能掌控自己做的工作、大家會聽你的、照你要的做。那絕對是相反！你長期以來有「升遷」這個非常具體的目標，然後成了 Staff 工程師，突然間一切變得模糊曖昧。你從解決相對明確的問題，轉為負責「找出對的問題」，再想辦法說服別人這值得解決。你會以完全不同於過往職涯的方式被挑戰。

• 要發展很多自我認識，以看清你追求某事是因為你想要，還是因為它對組織有益——這可能很難做到。你要準備好「殺掉你的寶貝（kill your darlings）」、轉向、嘗試新東西。如果一個做法行不通，別硬逼它。
• 我很喜歡 Dan Na 關於「推過摩擦（pushing through friction）」的演講，因為那是你成長為技術領導者時不斷經歷的事。我常想「無權威的影響力」這個概念：你的工作是搞清楚團隊或組織需要做什麼、讓組織對齊那目標，並在你對人力配置或最終決策沒有權威時，想辦法讓人們去做。這需要很多韌性，並施展一堆所謂「非技術」的技能。

學習資源#

很多我已提過的名字，尤其拉臘·霍根、Dan Na。我超愛 Julia Evans 做的一切，很幸運曾與她合作一個專案。前 Etsy 員工 Ryn Daniels 常寫職涯進展的部落格。Tanya Reilly 是我的一大啟發——另一位厲害的職場媽媽，也是受尊敬的技術領導者。前端領域的 Nicole Sullivan、Jen Simmons、Ethan Marcotte 都是巨大啟發。我也很享受讀 Camille Fournier 的《The Manager’s Path》——我從沒走過管理軌，任何能讓你一窺管理世界的東西都有幫助，因為身為 Staff 工程師，你幾乎像是個沒有帶人部分的經理。