「恭喜你成為我們團隊的一員,期待你能帶來新的想法和衝擊。」
這是我的新主管在我第一天報到時對我所說的話。然而,身為新來的資深工程師(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?
過往經驗 從技術選擇到技術債:選擇框架的隱藏成本