我所经历过的美国科技公司中几种不同项目推进形式和企业文化

June 12, 2026

摄于 2026-6 西雅图

本文总计 5.35k 字, 阅读约需要 13 分钟

近期我组存在感不是很强的 TPM 被开了，发表感叹时跟象友们讨论起了科技公司中的各工种职责，随之扩展到了几种不同的项目推进形式。我经历了 10 多年的科技公司牛马生涯，大至 big tech 小至百来号人的工作也干过 5 份了，确实也体会到一些组织形式和公司文化带来的对个体码农工作体验的影响，遂有此文。

Glossary #

1. 严丝合缝井井有条型 #

我毕业后所在的第一份工作（big tech）是这种类型，上述的所有工种都有，不过我刚入职还没有大项目的时候尚未出现，直到碰上了一整个 org 总共百来人一起推进的大项目大家才井井有条各司其职地出现了。这里就有了日常小项目和大项目两种工作模式：

小项目 #

作为一个幼小的 SDE I，我接到什么活儿干什么就行，完全不需要思考活儿是怎么来的。日常的工作流程：

1. 组里的 SDE II 和 SDE III 和 EM 把要干的活儿写好 ticket 做好 的sign 放到项目管理工具里。
2. Spring Planing：全组 SWE 和 EM 凑在一起，评估 backlog 里有什么 task 最重要，要花多少时间。
3. 按个人手头项目和空闲时间把这些 task 分给个人。
4. 埋头写码。
5. Spring 结束评估完成状况，没完的 rollover 到下一个 sprint，完了的 close。

大项目 #

随着升职和大项目的到来，工作流程在上述基础上拉高一个抽象度的话，变成了：

1. PM 照领导的意思写产品文档：有什么功能，具体用户体验是怎样的。当时我 level 低也不用管这个文档。
2. UXD 设计产品界面。当时我在纯后端组，没有跟 UXD 接触。（因为公司太大我负责的领域也不涉及 data 所以也没跟 DS/DE 接触）
3. EM 和 SDE III 跟其它组的 EM 和 SDE III 分工协调各组 service 职责。上面应该还有 level 更高的码农负责整体架构。
4. 组里 SDE III 和 SDE II 们各自协调负责的领域，产出 technical/system design，项目如果能分工协作的话再把工作内容分开，方便给其它 SDE I 分配。我应该是赶上升职档口，此处也领到了一个 service，第一次自己负责 design。不过作为一个 SDE I，这个项目用的技术栈大体方向是 EM/SDE III 给我的，我仔细研究好之后设计具体怎么做，提供什么 API 和执行就行了。
5. 我生成我 service 的 design，提心吊胆找全组 review。大方向 review 完之后我分配具体任务和估算时间。
6. 我评估完我的项目之后发现 scope 比预期大，还多要了另外一个 SDE I 帮我写一部分。
7. 每周大组项目进度开会，由 TPM 主持，检查各 work stream 完成度，确保各组 API 交付时间能跟其它组对上，有没有 blocker 和需要催进度的地方等等。PM 偶尔会来跟大家讨论一下产品问题。

当时那个 TPM 应该是我职业生涯中见的最强 TPM 之一，基本就是兵来将挡水来土掩的效果，在我眼里有什么 blocker 他说要去解决之后下一次回来开会准会已经解决了，我们这边工作交接丝般顺滑毫无阻碍。（当然也有可能是当时 level 太低有人替我负重前行了）

这个公司的模式下，我心目中的项目负责人是 TPM。

2. 产品/数据驱动，随性写码型 #

第二份工依然是 big tech，但变成了一个 fullstack 组 (Application layer backend (no dedicated infra, mono repo) + web frontend + mobile react native + Android + iOS) hate objective C），且全公司没有什么 design review culture，基本上具体咋 implement 的 nobody care，我想咋写咋写，绝大多数时间都是一个人从头写到尾，然后去问我们的 Data Analyst（我们这个 work stream 没有 DS，所以 DA 基本承担了所有我心目中 DS 的活儿）能不能行。工作流程如下：

1. PM 告诉我们要做啥东西，UX 给我们 design。
2. EM 把活儿分给不同 SWE
3. DA 告诉我们要 measure 啥数据
4. 写码。偶尔跟 UX 讨论一下 design.
5. 跑实验，DA 看结果，告诉我们成功没成功，哪里要改

这个模式下，我心目中的项目负责人是 PM/DA。

3. TL 驱动 #

第三份工作已经顶上了 senior title，但在小公司 scope 小一些只有一个 backend team + mono repo，且实际上只干了一年 ramp up 要一定时间，外加组里有一位年长很多的 staff eng 作为 TL 负责掌管大局，加上公司根本没有 SDE II title，所以干的活儿实际上我觉得接近 SDE II。

1. TL 告诉我们要做啥。
2. 写码

这个模式下我心目中的项目负责人是 TL。

4. Bottom up, 产品 + TL 驱动 #

第四份工作去了稍大一些的公司（1000 人左右），我在一个产品 fullstack 组(Application layer backend (no dedicated infra, mono repo) + web + real time service)。工作流程如下：

1. PM + UXD + 全组 SWE 一起讨论产品
2. TL 分工
3. Lightweight design review
4. 写码
5. 和 PM, DS, UXD 一起实时讨论实验结果和改进产品
6. DS 看实验结果，有问题 PM 想方案再拿给我们改

大概是这个队的 PM 比较强势，外加 TL 后来转了 EM 的缘故，在我心目中项目负责人是 PM，technical 和项目管理负责人是 TL，但 SWE 们对产品影响也挺大，应该是我所有工作里参与感最高的一期。

5. 选项目 top down，执行 Eng 驱动 #

第五份工也是 big tech，但管理 surprisingly 松弛，从 EM 到所有 XFN 都不怎么参与项目的具体实施。他们决定好做什么什么之后就没影子了（我已经一两个月没见到我 PM 了……），能不能完成全靠项目 lead（一位 SWE，一般一个项目一个 backend + 看项目在哪有对应平台的 client，比如 web + TV，或者 iOS + Android，或者都有）督工。就这样最近上线了一个也是百来人一起协调且有公司外部 dependency 的大项目，竟然能跑起来我也是挺惊讶的……

1. PM + EM 搞出来要做什么的大方向
2. EM 写 high level memo，指定好 eng lead
3. Eng lead 去调查可行性，反馈给 PM 然后 finalize product doc
4. Eng lead 写 design, optionally 给全 org review，不 review 也没人管你
5. EM 找来这个项目具体谁做（比如 client 组谁来做等等）
6. Eng lead 跟其它做这个项目的成员讨论 API 和 call pattern，跟 UXD 和 PM 讨论因为 technical 因素而要改掉的 design/product decision 等等
7. Eng lead 确保各人负责的部分进度顺利
8. TPM 统计收集项目整体健康状况给领导报告，但汇报什么全靠 eng lead，要 unblock 也是 eng lead 推进。

此处为什么说项目 lead 是 eng lead 而没有用 tech lead 呢，因为通常意义上 tech lead 是一个组里最懂 technical 大局的人。但现在这个公司/组的模式下，项目通常是 multi platform 的，一个 service area 就一个人，没人比别人更懂对方领域的 technical detail。比如我现在是我这个项目的 eng lead，但作为 backend 对我这个项目前端在写什么完全搞不懂，前端相关的 decision 纯粹 trust 我的 client partner 的决定。不同的 partner 在同一个问题上也完全有可能有完全不同的偏好和结论。比如我这个项目开始的时候是 mobile first 于是很多 design decision 是迁就着当时有空的 native mobile engineer 的偏好考虑，结果还没开始写就来了个外部大项目 hijack 了整个 org 的 priority，我的项目也变成 web + TV first 了，前面很多 decision 完全不 make sense 了。

具体实施上 eng 有绝对自主权，哪怕别人 design review 给我的 comment 其实也可以完全忽略，最终怎么写全由我自己拍板。甚至今年 claude code 品质大幅提升之后我们整个 backend 组也是各干各的，4 个人在 lead 4 个完全不同的项目对其他人的项目完全不了解。一开始大家还把 PR 发到组里让大家 review，后来发现也没啥用反正别人也没 context 不会比 AI review 的好，到现在大家都是 AI 写 AI review 发 PR 跑个 CI 就自动 merge 了。也就已经 live 的组里 service change 会让别人/那个 area 的 owner review 一下。

扩展到 backend 之外，整个 work stream 的 implementation 也是。一开始好些地方我们还问问 PM，后来发现 nobody car，大方向跟外部客户/领导锁定之后，具体细节 eng 们说咋来就咋来。

至于为什么还是 top down 呢，要做什么 SWE 基本上是完全没有发言权的。以前几份工尤其上一份，大家还会凑一起 brainstorm 一下有啥可做的，再给 PM/EM 挑。这份工我来了也一年半了 planing cycle 也过去 4 个了，完全不知道做啥东西到底是咋决定的，EM 给啥就是啥。上一个 EM 还因为跟领导和领导的 XFN align 得不顺被开掉了🤷

一开始有大概六个月都在反复扯皮方向，又因为作为 eng lead 被 involve 得很早，来回扯皮而不是实际开始做东西就搞得我超级厌班。但近几个月接受了这个设定实际开始 implementation 之后我突然 enjoy 了起来这个工作模式。这不就是我之前梦寐以求的“反正都是厌班，给我钱干啥不行，拿钱办事完事了”。而且具体怎么 implement 我还有绝对自主权没人来烦我，很顺畅。

回到总结，在我心目中这份工的项目负责人是 Eng。但具体做什么完全是 top down decision. 整体而言是一个 high trust don’t car detail 的模式——我们 trust 老板给的是正确的项目，老板们 trust 给我们的项目我们能负责完成。

一些关于现在这份工的碎碎念 #

引发这整篇文章的引子是我们 TPM 被开了。因为开的时间点比较尴尬（TPM 说自己马上要病假了然后病假前被开了）所以她老板还开了个说明会，也让我多了解了一些 TPM 的职责。TPM 老板说这位 TPM 花时间最多的就是管理 Jira，which 增加了很多 overhead，value 有限，而且跟我司的 vibe 管理似乎格格不入。作为一个 L6 TPM expectation 是能 getting alignment, mitigate risk, make execution more efficient 等等，只管 Jira 就不行了。

这位 TPM 的存在感确实不强。这个全 org 外部大项目一开始本来是她负责，也早早被换掉了，换掉之后隔壁大项目被借调过来的雷厉风行的 TPM 一比也确实有点高下立判，确实有耳目一新 everything is getting clarity and unblocked 的感觉。这么想来一个多月前找我（和大家）1:1 讨论对她的 feedback （当时的借口是到了 review cycle）大概也是进了 PIP 之后真的想要改进。one thing to note that 这个 TPM 之前一任我组的 TPM 也是（我刚入职就）被开掉的。这个职责粘合剂/润滑油作用的平庸和优秀的区别在我司这种 eng lead 管掉很多局部项目管理的情况下确实会被放大。

我入职一年半了，我叫得上名字被开掉的人有：

• TPM 1（我一入职就被开掉了没什么交集，但跟组员聊发现大家都不意外）
• EM 1（招我进来的老板，确实全程摸不着头脑也没啥存在感）
• PM（组员好像都表示此 PM 比较一般）
• PM Director（开掉 PM 之后自己顶了半年，然后也被开了……于是至今我组一开始说很重要要招更高 level 的 PM，结果过了一年了不但没招到还走了两个，现在暂时有一个跟之前 PM 同 level 但看起来更雷厉风行一点的姐来顶替）
• EM 2（EM 1 被开掉之后我组一部分分给了隔壁 client 组刚升的 senior EM 这位，挺了不到一年大项目来了之后不顺利地锁定了 goal 就被卸磨杀驴了，跟 PM Director 相差一周被开的）
• TPM 2（前面提到这个 TPM 1 的 refill，没啥存在感，坚持了一年）
• 隔壁组的 3 个 eng，都不熟，在公司干了 1 - 8 年不等。

总结起来开人有三个模式：

• 入职 1 年多（加上 PIP 就 1 年 2 个月吧）是危险期，如果能力不行的话一般会这个时期被开掉。我前前 manager 和 TPM 属于这个范畴。有些不太行但也没有更好的选择的，随着项目 scope grow 越来越不行的可能能撑 2 年，前 TPM 和前 PM 是这样。
• 在公司有一段时间了，但是因为升职/reorg 之类的拿到更大/challenging 的 scope，然后一年之内被开掉的，跟第一种情况类似。前 manager 和前 PM director 是这种情况。
• 时间长了厌班/丧失工作欲望划的。隔壁组几个 eng （除了一年的 new grad？）应该是这个情况。

这么看来我司真是能养闲人，但绝对不养庸人。Eng 这种有活儿干活儿没那么模糊的职能还是好混太多了，有工的欲望 + 能力正常基本问题都不大，软技能要求比较多的工种则差异就被放大很多了。Let’s see 我还能苟多久……

企业文化对实际工作的影响 #

以前觉得企业文化这种东西虚头巴脑纸上谈兵都是空话，这么总结下来其实还是对实际工作有些影响的。比如：

• 1: 严丝合缝，流程 rigorous，井井有条，但 overhead 巨多。符合我刻板印象中的传统大企业，AKA 加双引号的“corporate“。也就因为在 tech 所以差个 dress code 了。对 entry level SWE 来说还挺省心也能 learn best practice 的，稍微成长一些就嫌烦了。
• 2: 虽然和 1 一样都规模很大，但草台班子，说风就是雨。一个全公司级的大项目连个产品内 promotion 都是最后一个月才想起来临时抱佛脚找我一个人 implement，实际执行也没啥流程，literally move fast and break things。早年应该是比较接近 4 的，但林子大了培养出来一堆功利性太强的鸟，不 fit in 的话就很难受了。
• 3: 公司太小还谈不上啥文化，看公司里老人说啥就是啥吧。
• 4: Playful, chaotic Good，随性，passionate, fun and quirky. 当然随着公司成长和 stakeholder 变现压力，也逐渐能感受到这种 playfulness 向现实低头，少年逐渐成长为打着领带进出办公楼有房贷要还的成年人的感觉。
• 5: 一边有很多 corporate BS，但因为钱多事少 remote 所以大家都养成了 don’t car 拿钱办事的习惯；一边又非常不 micromanage, surprisingly light process, a lot of trust on 各类负责人，各司其职也能转起来。

一开始写的时候没这个意图，但写完发现换了 5 份工作体验都挺不一样的，那来升华一下给读者朋友们：一份工干得太痛苦的话也不要绝望觉得天下乌鸦一般黑没有更好出路了，树挪死人挪活说不定碰一碰就撞上对路/能忍/更划算的了呢 乁། ˵ ◕ – ◕ ˵ །ㄏ

类似文章

• 工作的由俭入奢

  career

  software engineer

  patreon

• 也记录一下古早程序员的一周

  career

  software engineer

  code

• Human powered enshitification long predates AI powered slop

  English

  rant

  tech

• 10 年 5 份工作 4 次 gap

  career

  software engineer

  patreon

• Job hunting tracking template

  career

  productivity

  software engineer

如果您觉得本文对您有帮助，想支持我的博客创作，或者有特定的内容想要看到，或者想约 coffee chat 等，欢迎: 订阅 Patreon 参与博客选题和定制服务 在 Kofi 上给我买杯奶茶

❤️ 🤣 🤔 🤯