career

為什麼優秀的工程師很少被卡住

你應該優先處理風險最高的工作

職涯早期我經常被卡住¹ ，但現在很少發生。什麼改變了？被卡住看似無法控制，因為你在等待其他人或事件。但工程師其實對被卡住的時間有很大控制權。有些工程師擅長「解除阻礙」就證明了這點。他們有什麼特殊技能？

先說顯而易見的：許多工程師被卡住是因為不知道怎麼做。他們需要資深工程師解釋正確方法。在那之前（如快速會議或 Slack 訊息），他們無法繼續。這可能是一般程式問題，像實作 rate limiter。或是公司特定知識，像複雜的開發環境設定。

工程師獲得更多知識並學得更快後，被卡住的頻率會降低。但仍會被卡住。如果你需要資料庫表格，但資料庫團隊下週才會執行 migration。無論多聰明都得等。所有工程技能都無法消除外部阻礙。

等待 migration 時，沒理由不做其他工作。工程師常犯的錯誤是被卡住時什麼都不做。或只做微不足道的小事（等於沒做）。這源於避免過度承諾的合理想法。但根據經驗，可以取得平衡。

我個人隨時保持兩項任務進行。實際上是一到五項，視工作忙碌程度而定。有時會突然被分配任務，或已關閉的問題重新開啟。或認為快完成的任務需要更多時間。五項太多，一項太少。如果唯一任務被阻擋，你會陷入無事可做的窘境。

關鍵是一次只承擔一項高優先任務。這樣不會因處理其他任務而延誤高優先任務。如果被分配兩項高優先任務，應該和主管討論移交其中一項。主管通常很樂意幫忙（也鬆了口氣你有在思考這件事）。

主要技巧是維護任務相對優先順序清單。不確定就直接問主管。這是一對一會議的好話題。

可能的話，我會讓其中一項是副業投資。這是我認為有價值但團隊不太感興趣的高報酬任務。副業投資是好的填充物，值得做但優先級低。最高優先任務解除阻礙時可立即放下。

工程師被卡住有時是因為嘗試不可能的事。假設他們想為新功能使用 Memcached。但公司用 Redis。他們可能長時間「卡在設定 Memcached」。與不合作的基礎架構團隊和架構師交涉。撰寫內部 ADR 和文件說服大家使用 Memcached。更有效的工程師會選 Redis，午餐前完成任務。

說服組織使用新技術的工作並非總是無用。如果技術解鎖新能力或在重要面向明顯更好，可能很有價值。但可能不比團隊實際任務重要（如果是，該換團隊了）。

有效的工程師知道哪些任務可能被阻擋並避開它們。如果公司創建新服務需要六個月。最好架構新功能由現有服務支援。如果邊緣網路團隊是不友善的守門人，會挑剔任何變更數週。最好設計專案不需要變更邊緣網路設定。預測這些問題決定專案是一年還是一個月完成。

所有優秀工程師都繞過組織功能障礙對公司不一定是好事。但不管好壞，事實就是如此。多數優秀工程師想交付成果，不想把時間花在政治鬥爭。即使長期來看政治鬥爭能讓公司更有效率。

如果你在處理重要專案，繞過功能障礙可能是對的，不要試圖解決它。專案延遲導致公司財務受損。這造成的功能障礙絕對比你修復某個不當團隊更多。

無法避免高機率被阻擋的任務就擁抱它們。先處理它們，被阻擋時可繼續做其他事。簡單例子是寫後端程式前先提交資料庫 migration。資料庫團隊審查執行 migration 時，你可以寫後端程式。你從未真正被阻擋。

這有時是技能問題。如果沒信心在寫完程式前正確完成 migration，最好等待。避免提交其他「修復」migration 混淆整件事。但根據經驗，仔細規劃通常能做對。

我可以寫更多關於專案任務正確排序的內容。先做可能被阻擋的任務是通則的例子：優先處理風險最大的工作²

我花了一段時間才學到被阻擋時可以求助。特別是處理高優先事項時。你會有許多強大盟友個人投入幫你解除阻礙。他們沒有你的技術背景，但有你缺乏的正式組織權力。如果你在專案前線，主管和上級主管就像三個山谷外的砲兵。你不說話，他們按兵不動讓你嘗試解決。召喚他們，他們會帶著壓倒性力量到來。

實際上是你組織的 VP 與阻擋你的團隊 VP 私下談話。突然他們竭盡全力幫你發布功能。從訊息和會議請求被忽略，變成該團隊資深工程師被指派確保你得到所需。沒經歷過很難知道可以這樣要求。但確實可以！

謹慎使用這策略。經常向主管求助，他們會認為你無法獨立作戰。這對未來晉升或信任關係都不好。同樣地，在技術問題上尋求政治幫助（如無意中要求不可能的事）。你可能讓上級或 VP 看起來像白痴，對你有嚴重後果。但有時這樣做是對的。記住這是危險的建議。

我說被卡住，指所有可能讓你標記工作票為「被阻擋」的情況。或在站立會議說「我被卡住了」：程式碼審查、資料庫 migration、等待關鍵答案。需要其他團隊批准，或不知道如何繼續。
如果你想讓我多寫這方面的內容，請告訴我！

Read more