「恭喜你成为我们团队的一员，期待你能带来新的想法和冲击。」

这是我的新主管在我第一天报到时对我所说的话。然而，身为新来的资深工程师（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?

原文发布于：詹姆士的软件易开罐 ...