本篇訪談錄於 2020 年 8 月。達米安·申克曼（Damian Schenkelman）是 Auth0 的 Principal Engineer。

我的角色與團隊#

我是 Auth0（一個 Identity as a Service 平台）的 Principal Engineer，隸屬系統架構（Systems Architecture）組，目前有三位 Principal Engineer。我們和不同團隊一起推策略性行動，也形塑 Auth0 的技術策略、架構決策與準則。撰文當下，我以技術主管身分和一群 IAM（Identity and Access Management）團隊合作一項大型新產品功能，同時和其他團隊推動可靠性與擴展相關的行動。

Staff-plus 工程師在做什麼#

工程按領域（domain）組織：目前有 IAM、開發者體驗、服務管理、平台。

• Staff Engineer：能在一個領域內技術性地帶領團隊，通常屬於領域裡的單一團隊，同時能積極貢獻於跨領域範圍的行動。
• Principal Engineer（我們階梯的下一級）：可以在特定團隊（深度），也可以和多個團隊合作、範圍橫跨整個組織（廣度）。我目前在「廣度模式」：既做具體行動，也定義技術策略、平台的技術選型，並帶領設計與架構工作組（DNA）。

DNA 有 6 名成員（3 位常任 Principal，3 位每 6 個月輪替的 Staff／Senior II）。這個工作組制定決策與準則，把 Auth0 技術推往特定方向（例如避免語言氾濫，讓函式庫只造一次、大家也能輕鬆換團隊），並在大型行動的技術審查上與團隊協作。

我的角色最不同之處，在於我有「最廣的範圍」——我在公司待了六年多，其中三年多是工程總監。我和產品與平台團隊一起做行動，也常和公司其他部門合作：加入與重要潛在客戶的對話、和法務團隊研究合約用語、與行銷協作。

日常怎麼分配時間#

變化很大。典型一週有很多會，所以我在試新做法：把會集中在週一、週三、週五；週四完全封鎖；週二只處理緊急事務。因為我們遠端，所有會議都在 Zoom。

• 會議日：定期的有 1:1（與我的經理，即工程 VP，或某位團隊經理／技術主管），以及團隊會議（工程領導層、DNA 工作組）。不定期的有：我技術主導的特定行動、幫一群團隊釐清怎麼起步、做同步設計審查。
• 週四（以及盡量在週二）：花時間思考現有行動的進展、未來（下一季、明年）我們能／該做什麼、寫文件與準則與部落格文章，偶爾做 POC 或寫小工具。

最有影響力的地方#

最大的影響來自能幫忙達成「人的規模化」（people scale）——盡可能正面影響內部更多人的工作。《Scaling Up Excellence》有個好懂的比喻：規模化是地面戰，不是一次性空襲。它需要大量時間與耐心，但要達成目標，你得讓整個公司在目標與達成方式上對齊。

身為 Principal Engineer，我試著找出我相信能長期為盡量多的人設定方向的機會／缺口。讓我們產品交付組織約 200 人在某個主題上對齊，比我自己寫程式解決一個問題有價值得多——前者影響更大、擴展性更好。

拿到頭銜後才做得到的事#

成為 Principal 前我是 Auth0 的工程總監。最有趣的是，當我以 Principal Engineer 給回饋時，人們防衛心少很多，在 1:1 中似乎也開放很多。我想這可能和「身為 Principal Engineer，你不是在代表組織的某一塊」有關。在這方面，當個人貢獻者感覺好多了。

倡議變革：一個影響組織的故事#

快速成長公司常見的問題是「缺乏清晰度」。我們當時對未來會發生什麼有很多困惑，這讓我們在技術決策上又慢又沒效率：團隊不確定該不該用某項技術（因為不知道未來會不會支援）、不確定該不該用某種方式做某產品（因為不知道那做法是否符合長期技術策略）。

我們相信需要一個長期方向，說明今天該如何處理問題的技術實作、以及如何銜接現況與未來願景——更精確地說，需要一份文件化的技術策略，詳述為了長遠成功，我們該做與不該做什麼。

和大量的人談過後，我發現他們都接觸到不一致的資訊與謠言，讓他們害怕做決定，例如「我聽說公司未來要做 X」或「我聽說平台團隊未來不會支援技術 Y」。很多混亂來自一個謠言：我們會支援某個客戶需求及其技術意涵——大家一直聽到，但具體計畫從未宣布。我把這些問題寫下來、串起所有線索，試著把資訊轉成知識，並意識到需要短期與長期兩種解法。

少寫程式後如何掌握真實狀況#

這有兩個面向：跟上整體技術，以及跟上 Auth0 內部與工程團隊當前的「現況」。

• 內部：透過 Slack 保持耳貼地面，並和一些技術主管與工程經理做 1:1。這幫我第一手理解他們的挑戰，也找出模式、得出全域而非局部的解法。
• 外部：和客戶／潛在客戶談他們怎麼用產品、讀提到 Auth0 與身分領域的推文與新聞。

技術方面，我覺得自己「跟上」的程度不如我想要的，但我仍努力。產業每個月都有太多重要新事物，很難跟上。接受「開會與不再親手做，意味著我很可能不如我想要地跟得那麼緊」很重要——一旦接受這點，我才能開始優先處理真正有價值的事。

我讀書、挪時間做 POC 或讀特定主題的部落格／論文，並主動要求領導特定行動，即使不常寫程式，也能跟上我們的開發方式。

贊助其他工程師#

是的，很多！我是工程領導團隊的成員，我們每週開兩次會討論組織議題。這加上耳貼地面、參與中期計畫的會議，幫我知道（有時提出）未來可能出現的機會。每當有這種機會，我通常會提出我認為能從中受益的人名、解釋為何我認為他們會勝任，若有幫助，還會在他們有能力缺口時提議指導他們。

我到 Principal 的路#

我的故事有點特別。我 2014 年 5 月加入 Auth0，是第五位工程師、約第十位員工，當時沒有頭銜、沒有階梯，什麼都沒有。2015 年左右我開始指導幾位新人、做 1:1；到 2015 年底，我做自己的行動、也帶領別人、幫忙招募等。2015 年底，Auth0 的 CTO 兼共同創辦人 Matias Woloski 在找人帶領工程團隊，問我要不要當工程總監。

我很幸運能以「最大化學習與解決難題機會」的方式看待職涯——這是幫我做決策的主要原則。當他給一個住在阿根廷、25 歲的我，機會去領導一家指數成長、遠端優先的「矽谷」公司的工程組織時，我自然說「好」。我從沒想過「我要當管理者」，它就這麼發生了，因為我想學習、想解決難題。

事情發展得很好。我學到很多關於建團隊、建組織、帶人的事。因為我是最早的工程師之一、建過很多系統、也享受技術對話，我在那個角色也做了大量技術領導。到 2019 年初，身為平台總監，我開始覺得學習速度不如以往，也想要比「只做平台」更廣的範圍。和當時 Auth0 的工程 VP Christian McCarrick 多次談話後，我意識到下一個想接的挑戰是成為 Auth0 的技術領導者之一。我在 2019 年 8 月轉為 Principal Engineer。

走到 Principal 的關鍵因素#

我很愛塞內卡（Seneca）的一句話：「運氣是準備遇上機會時發生的事。」到 Principal 需要做對一些事，但也需要很多運氣。

• 第一份工作：在阿根廷念大學時工作很常見。高中畢業後我在一家很棒的公司 Southworks 找到工作，兩個關鍵是：公司用尖端技術做專案，給我很多磨練學習能力的機會；公司主要作為 Microsoft 美國的遠端供應商，意味著不只技術受重視，我們也常練習溝通、期望管理與其他人際技能。（我能高中畢業就做軟體，是因為 11 歲時我一直跟媽媽說想「做電玩」，父母找到並支付了一所教程式的高中。）
• Auth0：我是最早的工程師之一，多年來做過產品與基礎設施的許多部分，讓我很容易幫人、也能在各主題提供有價值的意見。當過工程總監也幫我理解許多關於業務的事，讓我成為更有效的貢獻者。
• 團隊運動：我小時候與青少年時打籃球，很早就體會到「拿任何分數但贏」感覺遠比「拿很多分卻輸」好。這以兩種方式形塑我的工作：讓我常幫隊友、思考如何以團隊姿態成功；讓我學會並去做「補位」所需的事，這培養了我在職涯成長中很有用的領導與人際技能。

運氣的角色：任何新創的成功都需要許多不同時點的大量運氣。若 Auth0 沒有這樣成長，我不會有機會學到我所學、走到今天。這點特別重要，因為我住在阿根廷，那裡軟體業比美國小得多，多數公司也沒有雙軌制。

關於「Staff 專案」#

我沒有。因為我在 Auth0 成長的方式，我算是「跳過了那部分」。身為新創的總監，我有機會技術性地領導很多大型關鍵行動，但沒有特定／明確的「staff／principal 專案」。隱約最接近的，大概是我 2017 與 2018 年領導的提升 Auth0 可靠性與擴展性的工作，包括為部分關鍵客戶提供更高 SLA 的專案。

給剛上任者的建議#

• 先對齊期望：Staff 在不同地方意義不同，第一個建議是和盡量多的人談，去定義你所在之處的期望。
• 要有耐心：你之所以到這裡，多半因為你相當技術、能拿出成果；但沿階梯往上，你工作的成果需要時間發酵。你可能同時做更多事，而它們的影響有更長的時間跨度；你現在也在影響更多不同角色的人，有時他們需要更久才能「看見」你清楚看到的東西。有耐心、漸進地影響人、教導他人，長期會有回報。

習慣把東西寫下來、並反覆對別人講。把想法、計畫、推理與標準寫下來，是你規模化自己的方式。文件化讓任何人未來都容易取用、閱讀、引用，比「只是口頭談」好得多：擴展性更好，也降低被誤解的機會。但光發布文件沒用，反覆也必要——你得把想法分享給人。辦 AMA、brown bag 與其他解說你想法的場次，非常有價值。

為何走這條路#

我沒有規劃過，但當總監的機會來時我接了。不過我的想法是：兩條路之間存在一個鐘擺，你可以來回擺動。難易取決於公司、以及 Staff／Principal 技能有多專精，但我認為可行。如今我很有興趣繼續發展我的技術與領導技能，因為我認為那會帶來最有價值的學習與挑戰。

學習來源#

我在 Twitter 上追蹤我認為在做有趣事、能讓我學習的人。有太多人在做有趣的事、太多可學！想到的一些名字：

• Aphyr：用 Jepsen 做的工作，以及關於分散式系統的一般內容都很棒。
• Tanya Reilly：有些很好的內容，如 RFC process @ Squarespace 與 Being Glue。
• David Fowler：分享很多關於 .NET Framework 與 ASP.NET 內部的內容，我覺得很有意思，還有他分享如何成為 ASP.NET 架構師的影片。
• Jon Allie（Auth0 同事）：一位很棒的工程師與人，追求簡單、能把事情解釋得很清楚，且以他懂得之多而言極為謙遜。

我沒找到很多針對資深「個人貢獻者」的書或類似內容（也許值得寫一本）。我最近讀了《Fundamentals of Software Architecture》，在描述這個角色、同時理解其中細微與灰色地帶方面做得相當好。

一些管理書對取得組織意識、以及協助指導／1:1／招募（Staff-plus 工程師通常會幫忙的事）很有用。《High Output Management》中 Andrew Grove 把「know-how manager」定義為「可能不直接管理任何人，但即使沒有嚴格的組織權威，仍影響他人工作的人」——這聽起來非常像 Staff-plus 工程師。我強烈推薦《Managing Humans》，它分享的故事好讀又有趣，也幫你對管理者產生同理，這對 Staff-plus 工程師很重要。《與成功有約》（The 7 Habits of Highly Effective People）也有很多對 Staff-plus 工程師的好教訓。《Accelerate》則是另一本好書，能把公司成功與工程實務及成果連起來，對影響利害關係人（尤其在高管層級）很有用。