「恭喜你成為我們團隊的一員，期待你能帶來新的想法和衝擊。」
這是我的新主管在我第一天報到時對我所說的話。然而，身為新來的資深工程師（Senior Engineer），我深知自己並不是單單只要接下原本的工作，而是要以自己的經驗與能力，在不干擾團隊原有運作的前提下，協助他們更好地達成目標。
在過去的幾份工作中，我還真看過新進同仁帶著想法衝得太快、嘗試改善流程或重構系統，但因為沒有充分理解團隊的現況及人際關係，最後反而造成反效果。這一次，我成為了別人眼中的新進同仁，希望能憑藉過往的經驗，更有計畫、更有意識地踏出每一步。第一階段：傾聽與觀察
「有資深工程師來了，就能馬上把老舊系統推翻重來嗎？」
這是大多數人對「新人帶來新思維」的想像，但現實往往沒這麼美好。尤其在商業專案中，「歷史包袱」——不管是舊程式碼、既定流程，或是既有團隊文化——都可能是公司維持收益運轉的重要基石。某位前輩曾提醒我：「不要不尊重現有流程，你認為的『legacy code』，也許是養活了這間公司多年的關鍵。」
因此，剛進入一個新環境時，我更傾向先觀察、傾聽，而不是急著推翻或評論。
- 了解產品或專案的價值：我會跟銷售或產品經理聊聊，請他們像對客戶推銷時一樣告訴我「為什麼這產品重要？哪裡能解決用戶痛點？」，以建立最核心的產品脈絡。
- 找到組織中的意見領袖：正式的組織結構並不一定代表真正的「影響力」分布。某位工程師或許沒有管理職稱，但他卻是團隊最關鍵的知識庫。花時間和每個同事一對一聊聊，問問他們在做什麼、痛點在哪裡、希望改善什麼，也能幫助我掌握團隊文化、政治角力和隱形規則。
- 多嘗試小任務：若時間允許，我會先從小的功能修復或 Bug 修正入手，一方面熟悉開發流程與代碼架構，一方面透過解小問題搭起信任，讓團隊知道我不是只會「空談」。
Tips： 有人建議觀察的黃金時間至少 90 天。雖然並非絕對，但在此期間，盡可能避免提出大刀闊斧的改革，先把現行做法理解透徹，再考慮改進策略。
第二階段：筆記與知識管理
不少工程師（包含我以前）都有個習慣：覺得自己記性不錯，很多事就沒做特別紀錄。但當整個系統知識和人脈資訊堆積越來越多，必然有遺漏。當我開始嘗試每日做筆記時，才發現它不僅能記錄我的學習軌跡，更能成為日後溝通或自評的佐證。
- Lab Notes / Daily Notes：為自己準備一個 Markdown 或筆記系統，每天把學到的、看到的問題，以及解決過程寫下來。不僅能在季度考核時回顧表現，也能幫助新人或同事更快上手。
- 公開分享：當我採訪完不同部門或資深同事之後，如果能整理出一份「新人工具＆流程指南」、或是一篇內部 Blog 文章，發表在公司 Wiki 或知識庫，往往能展現出「幫助團隊」的意圖。這樣的主動行為也能為自己建立口碑，讓團隊知道我不是只懂技術，而是樂於分享。
第三階段：穩紮穩打，建立信任
在新的組織裡，儘管我擁有「Senior」的頭銜，也不會馬上得到信任。有同事曾經分享：「大家不會馬上把你當資深，尤其如果你冒冒失失地批判現有做法。」對於長期以來的專案，若我不先理解前因後果，就拿現有程式碼大肆開刀，很可能破壞信任，甚至讓老團隊產生排斥。
- 觀察人事動態：透過接觸部門同事、跨部門協作，我會留意哪些關鍵人員影響決策、誰擁有歷史上下文、誰對流程特別熟悉。並注意哪些同事對技術改革較開放，哪些同事偏保守。
- 謙虛求教：很多時候，我是「新來」的，至少在組織文化與商業脈絡方面可能相對陌生。所以，我會保持尊重與提問：「為什麼之前會這樣設計？是基於哪些商業考量嗎？」這麼一問，常能得到更多資訊，也能讓團隊覺得我在意他們的想法，而不是一上來就頒布新規。
第四階段：提出建議前的準備工作
當我逐漸熟悉公司產品、技術堆疊和人際環境後，就會進入所謂「提出建議或改革」的階段。但在正式開啟某個大型改善計畫之前，我會先做POC（Proof of Concept）或小範圍試驗，並且先與主要利害關係人「預溝通」。有人稱之為Pre-wiring：也就是先和那些可能持反對意見或最需要被說服的人聊天，收集他們的疑慮並調整方案。當正式會議開始，支持者就不只我一人，而是有多人背書。
- 先從小處著手：先解決一兩個大家都覺得痛的點，或者能立刻帶來好處的功能改進，讓團隊看到成效，提升改革意願。
- 預先對焦：一旦我掌握了團隊常見反彈點，比如「過去開發過程、測試流程、系統相容性顧慮」等，就會在提案前做足準備，避免把會議變成辯論大會。
- 與主管對齊：事先問清楚主管或老闆對我在未來一季、半年或一年的期待目標，確認「我對團隊帶來何種影響」才是他們想要的。這樣才能保持工作方向與公司策略一致，也避免好不容易做完一個專案，卻發現這不是老闆在乎的事情。
第五階段：維持協作與長期影響力
除了技術專業以外，溝通協作與帶領能力也是資深工程師必須具備的。在初期建立起的信任基礎上，接下來就能逐步擴大自己在團隊的影響力，幫助同事解決難題，或帶領更複雜的專案。但切記，維持合作關係需要持續努力，一時的成功不代表永遠的順利。
- 願意做「基礎工作」：有些雜事或細瑣的工程維運，仍可能是團隊缺少人力的痛處。適時承擔這些工作，不但能更快熟悉系統，也能展現「就算是資深，也能放下身段做基礎」。
- 持續回饋與調整：如同在技術上做迭代一樣，與同事的相處也需要不斷調整。若在某件事情上出現爭議或失敗，不要逃避，應該持續檢討與溝通，展現解決問題的能力，而不是一味推責。
讓「新」真的帶來「新」
對我而言，跳槽到新公司或新專案，挑戰絕對不只有技術層面，而是更全面的「人」和「流程」。和我一樣的新進資深工程師，不妨把前 90 天當作對環境的探索期，多觀察、多提問、多累積信任。在大家開始認可你之後，再適度推動更大的技術改革或流程改善。
有時候，慢就是快。先穩住基礎，才能讓資深工程師的優勢在未來幾個月、甚至幾年裡真正發揮出來。帶著耐心、謙虛與主動，我們才能在新環境裡既做出好成績，也為整個團隊帶來正面的改變。讓我們一起成為在新組織中，真正能影響並提升全局的推動者。
（本文結合了多位資深工程師的親身經驗與建議，並參考了個人過往對於技術導入與人際互動的思考。若你正在新工作的適應期，希望以上內容能給你一些啟發，協助你在團隊裡穩健前行！）
參考資料：
原Hacker News 討論串 How to approach first days on a new job as a senior engineer?
過往經驗 從技術選擇到技術債：選擇框架的隱藏成本
