本訪談錄製於 2020 年 3 月。Keavy McMinn 是 Fastly 的資深首席工程師（Senior Principal Engineer）。

目前的角色#

我是 Fastly 的資深首席工程師。Fastly 是提供 CDN 等服務的邊緣雲端平台。我在 OCTO（Office of the CTO，技術長辦公室）工作，這裡約有十位首席或傑出工程師（distinguished engineers），直接向 CTO 匯報。OCTO 的每位成員通常各有焦點，我的焦點是擔任 API Lead。

在公司裡怎麼運作、怎麼花時間#

OCTO 裡有好幾種很不同的首席／傑出工程師：有人做網際網路標準或學術研究，有人做深度技術研究與原型，有人幫忙孵化一個從零打造新東西的團隊。也有首席工程師是直接在工程團隊內、而非 OCTO 裡。我在 API Lead 角色上與更廣的工程組織密切互動。

我們做的事各不相同，但有個共同目標：對事情採取整體、長期、系統層級的視角，並找出並協助那些跨工程、容易被忽略或掉進縫隙的事。CTO 支持我們的工作，但不指定我們該做什麼專案，那由我們自己決定。

我從沒用百分比想過我的時間。有些工作是分階段的，這週多做這個、下週多做那個。我大量的時間花在書面工作、研究和與人交談上——定期和建 API 的團隊與經理開會、把長期策略拆成小塊、做研究、寫提案，然後在公司裡「推銷」這個提案。最近較少寫程式，但在其他階段我會建 demo 或工具來支援更大的工作，那種寫程式仍然很享受。

有了頭銜之後#

• 一般工程師很難挪出時間，你得更在既定專案的約束與節奏內工作。作為首席，你有信任、時間與空間去嘗試新東西。
• 有了頭銜，你不用花那麼多力氣把資歷擺上檯面，它幫你替別人設定好脈絡。你從一開始就更被尊重，這點很明顯。你也能接觸到高階主管，於是更早拿到資訊，並可能有一席之地去影響事情。

倡議與推動改變#

我被聘來就是要為 API 設定策略方向，一部分是掌舵技術方向與選擇。我把它當成協作練習：我會做研究的苦工、分析所有資訊、呈現取捨、給出建議，並吸納所有組織與工程脈絡。我呈現我認為對我們最好的方案，人們可以不同意——而他們常常不同意。

我是在掌舵與影響，而不是說「我有權直接叫你怎麼做」。我從沒見過那種風格運作得好。

對有爭議的決定，我會和不同相關群體的代表碰面：先和一群工程師說我要建議什麼、問「你們覺得如何？我漏了什麼？」也和管理與產品端、也許法務、文件、安全等碰面。我也試過相反方向：先把東西呈現出來，再開會收集回饋，而不是被動等人在文件裡留言。

我倡議過的一件事：在現在的工作，我大力倡議為 API 變更寫設計文件。在任何人寫程式之前——當變更成本還低時——先寫下使用者工作流程，以及什麼樣的介面能支援這些流程。有時會發現看似簡單的東西其實很難，尤其當團隊不習慣用這些肌肉時。

我的倡議方法是提醒大家：當初讓我們想做改變的痛點是什麼。我們不是為了理論、程式碼之美或某種崇高的顧慮而追求完美，而是把它拉回「這些是大家都說感受到的痛點，而這是最終能幫上忙的做法」。我也讓別人一起在乎同樣的事，例如更多地和工程師配對做 API review，一邊審一邊教他們我在看什麼。

贊助其他工程師#

這在我現在的角色裡不是那麼大的重心。在 GitHub 時我意識到自己因資歷與年資而有特權，於是贊助了一位工程師：給他越來越有挑戰性的工作、鼓勵他對我的工作中任何不清楚或好奇的地方提問，並為他爭取更多責任與肯定。

如何建立組織信任#

在 Fastly，我從一開始就被給予信任。我被聘來處理特定的事，我記得問「這有時間表嗎？」以及他們對策略的想法，得到的明確答覆是他們要我自己搞清楚、再告訴他們。所以確實有很多信任與責任。

「一開始就被賦予信任」與「慢慢建立信任」各有利弊。建立信任時，你同時也建立了大量脈絡（我在 GitHub 就是如此）。但我發現在現在的工作，不帶脈絡進來、當一雙新鮮的眼睛其實很有用——當大家覺得「喔，我們一直都這樣做」時，你更容易提出質疑。不被過去綁住可以很解放。

Staff 專案#

我沒聽過有人給它取名，但我懂這個概念。我確實幾次領導並架構過那類專案——解決棘手的工程問題、對公司有大影響——只是很遺憾它們沒讓我升遷。不過它們確實推動了我的職涯發展：那些專案給了我經驗、知識與信心，讓我能以不同方式定位自己，甚至去做公開的研討會演講，或知道「我做過 X，而且能再做一次」。

公開演講與能見度#

我認為這對我整體職涯發展是巨大因素。我不覺得它是必要的，但它絕對有幫助。

如何第一次拿到 Staff / Principal 頭銜#

我是被 Fastly 以首席工程師身分聘進來的。所以老實說，對我而言最大的因素是換公司。我做的工作類型沒有戲劇性改變，但換公司才是最終讓我拿到頭銜的關鍵。當時有人特別強力倡議聘用我，我相信這有幫助——他不是我直接共事過的人，但熟悉我的工作。

遠距工作有影響職涯軌跡嗎？ 就我所知沒有。我一直是遠距員工，也一直這樣做很久了。你會刻意花力氣去進行對話、建立關係。我待的公司也大多是分散式的。我能想像，如果遠距是少數、或公司沒有完全擁抱分散式，它可能更會是個潛在問題。

關於建議#

我沒得到什麼特別有幫助的建議，反而得到一些爛建議。有個很老套的說法：「這很棒，現在你得再證明一次。」有些建議把人推向英雄式的方向，像是說你得發明某種不尋常或神奇的東西才夠格。到達 Staff 有非常多不同的方向，工程階梯常助長這些迷思。

給剛上任 Staff 的建議：找到你的同儕或支持網絡。就像管理職一樣，爬得越高越孤單，重要的是找到仍會挑戰你、能與你腦力激盪的同儕。他們是否在你相似的領域、甚至是否在同一家公司，都不重要。

關於工程管理#

我試過一次，經驗不好，然後我意識到那不是我熱情所在。我對工程管理太尊重了，不能為了「正確理由」以外的原因去做它。而正確的理由，是為了支持其他人。

學習資源#

研討會一直是我的資源，還有能和成熟、低自我（low-ego）、很棒的工程領導者與工程師共事的機會。名單頂端是 Chad Fowler 和他的書《The Passionate Programmer》。Dave Thomas 是另一位——我剛學 Ruby 時常去他的工作坊，他的書《The Pragmatic Programmer》也是很棒的一本。