当你以 Tech Lead 身份加入一家新公司时，你前 90 天的路线图是什么样的？

Question

Accepted Answer

我的前 90 天按照**先倾听，再梳理，最后行动**的顺序展开：在改变任何东西之前，我先赢得信任和掌握背景，然后交付一个小而可见的成果，之后才提出结构性的改变。目标是建立可信度，而不是逞英雄。

## 第 0–30 天：倾听与学习

- **与每个人做 1:1** —— 每位工程师、我的经理、PM 以及关键 stakeholder。我会问什么是顺畅的、什么是出问题的，以及他们希望有人能修好什么。
- **理解系统，而不只是代码** —— 在本地跑起应用，追踪关键请求路径，阅读过去 3 个月的 incident 和 postmortem。
- **梳理交付流水线** —— 代码如何从笔记本走到生产环境、在哪里卡住、CI/CD 和 on-call 的现状如何。
- **暂不写任何结构性的东西。** 我会提交一些小 PR（文档、一个不稳定的测试、一个 README）来熟悉工作流并表明我亲力亲为。

## 第 30–60 天：诊断并交付一个成果

- 把发现综合成一份简短的**书面诊断**：按影响排序的前 3 项优势、前 3 项风险。
- 挑选**一个高信号、低风险的成果** —— 例如把 CI 时间砍掉一半、修掉最吵的告警、把部署流程写成文档。可见的价值能积累起推动更大改变所需的政治资本。
- 在确定方向之前，与团队和经理验证我的判断。

## 第 60–90 天：设定方向

- 提出一份与业务目标挂钩的**技术 roadmap**，包含先后次序和负责人。
- 建立或完善**团队仪式** —— code review 规范、on-call 轮值、规划节奏。
- 与我的经理就**如何在 6 个月时衡量我的成功**达成一致。

## 需要避免的陷阱

- **未理解就重写** —— 那些“显而易见”的烂摊子往往编码了来之不易的约束。
- **试图一次性修好所有东西** —— 挑少数几个，把它们做完。
- **忽视社交图谱** —— 谁真正做决策，和架构本身一样重要。

## 为什么这很重要

Tech Lead 的杠杆来自信任和背景，两者都会复利累积。第一个月花在倾听上感觉很慢，却能避免一个昂贵的错误——大张旗鼓地解决了错误的问题；而一个可信的早期成果会为你赢得日后处理棘手结构性工作的授权。