很多人以为在大厂工作，就是不停地写代码、解决技术难题。

但事实是：真正成功的工程师并不是那些代码写得最好的人，而是那些解决了代码以外事情的人。

本篇和你分享 21 条职场教训。

这些教训，有的能让你少走几个月的弯路，有的则需要数年才能完全领悟。

它们都与具体的技术无关，因为技术变化太快，根本无关紧要。

但这些教训，项目换了一个又一个，团队换了一批又一批，始终在重复上演。

希望能帮助到你：

1. 最优秀的工程师都痴迷于解决用户问题

很多人容易爱上一项新技术，然后到处找地方用它。

我干过，你肯定也干过。

但真正创造最大价值的工程师是反过来的：

他们专注于深入理解用户问题，并让解决方案从这种理解中自然而然地涌现。

以用户为中心意味着花时间处理支持工单，与用户沟通，观察用户遇到的困难，不断追问“为什么”，直到找到问题的症结所在。

真正理解问题的工程师往往会发现，优雅的解决方案比任何人预想的都要简单。

工程师如果一开始就想着如何解决问题，往往会为了寻找理由而人为地增加复杂性。

2. 正确很容易，共同达成正确才是真正的挑战

即使你在技术上胜券在握，最终也可能输掉项目。

我曾亲眼目睹一些才华横溢的工程师，自诩为房间里最聪明的人，但总是默默地积攒怨气。最终表现为“莫名其妙的执行问题”和“莫名其妙的阻力”。

关键不在于证明自己正确，而在于参与讨论以达成对问题的共识。

为他人创造发言空间，并对自己确信的观点保持怀疑。

3. 行动优先，先做，再做对，再做好

追求完美会让人停滞不前。

我曾经见过工程师花几周讨论一个从没建过的东西的理想架构。

但完美的方案很少从思考中产生，它都是从与现实的碰撞中产生。

先做出来，再做对，再做得更好。

把丑陋的原型放到用户面前，写出乱糟糟的技术文档初稿，发布那个让你有点尴尬的 MVP。

从真实反馈中学到的内容，哪怕只有一周，也远比一个月的理论辩论多得多。

4. 代码清晰远比炫技重要

我知道你想要写出酷炫的代码，那可以证明自己很牛逼。

但项目往往不止你一个人，以后还有其他同事要维护。

优化时要考虑他们的理解能力，而不是你的代码是否优美。

5. 谨慎选择新技术

新技术就像贷款，你要用 bug、招聘困难和认知负担来还。

关键不在于“永远不要创新”，而在于“只在因创新可以带来独特报酬的领域进行创新”。其他的一切还是应该回归平庸。

6. 你的代码不会替你说话，但人会

刚开始工作时，我相信是金子总会发光。

但我错了。

代码静静地躺在仓库里。你的领导在会议上提到你，或者没提。同事推荐你参与项目，或者推荐了别人。

在大公司，决策是在你没被邀请的会议上做出的，用的是你没写的总结，由只有五分钟时间和十二件事要处理的人做出的。

如果你不在场时没人能清楚说出你的价值，那你的价值就等于可有可无。

这不是让你鼓吹自己，而是告诉你：你需要让你的价值被所有人看到。

7. 最好的代码是你根本不用写的代码

工程师文化崇拜创造。

没有人会因为删除代码而获得晋升，即使删除代码往往比添加代码更能改进系统。

因为你不写的每一行代码，都意味着你永远不必调试、维护或解释。

在动工之前，先仔细思考一下：“如果我们不做这件事会发生什么？” 有时答案是“没什么坏处”，那就是你的解决方案。

问题不是工程师不会写代码，而是我们太会写了，以至于忘了问：该不该写？

8. 大规模时，连你的 bug 都有用户

用户多的时候，连你的 bug 都会有用户，这产生了一个职业级洞察：

你不能把兼容性工作当“维护”，把新功能当“真正的工作”。兼容性就是产品。

所以把你的“废弃”做成“迁移”，带上时间、工具和同理心。

9. 慢实际上是因为不协调

项目进展缓慢时，人们的第一反应往往是责怪执行：员工不够努力、技术不成熟、工程师人手不足。

但通常来说，这些都不是真正的问题所在。

在大公司，团队是并发执行的基本单位，但随着团队数量的增加，协调成本呈几何级增长。

大多数效率低下实际上源于目标不一致——人们在做错误的事情，或者以不兼容的方式做正确的事情。

所以高级工程师花更多时间澄清方向、接口和优先级，而不是“写代码更快”，那些才是真正的瓶颈所在。

10. 专注你能控制的，忽略你无法控制的

在大公司，无数的变数都超出你的掌控——组织架构调整、管理决策、市场变化、产品转型等等。

过度关注这些因素只会让你焦虑不安，却又无能为力。

所以高效的工程师，会锁定自己的影响圈。你控制不了是否会重组，但你能控制工作质量、如何应对、学到什么。

这并非被动接受，而是策略性关注。

把精力浪费在无法改变的事情上，就等于浪费了原本花在可以改变的事情上的精力。

11. 抽象并不能消除复杂性

每一次抽象都是一种赌博，赌你不需要理解下面是什么。

有时候你会赢，但总会有漏洞，一旦出现漏洞，你就需要清晰地知道你站在什么上面。

所以高级工程师即使技术栈越来越高，也要持续学习“更底层”的东西。

12. 写作让表达更清晰，以教带学是最快的学习方式

写作能带来更清晰的表达。

当我向别人解释一个概念——在文档里、演讲中、代码评审评论里、甚至和 AI 聊天，我都会发现自己理解上的不足。

所以如果你觉得自己懂了什么，试着简单地解释它。卡住的地方，就是你理解肤浅的地方。

13. 注重粘合性工作

粘合性工作——例如写文档、帮新人上手、跨团队协调、流程优化——至关重要。

但如果你总是无意识地做这些，反而可能会拖慢技术成长，把自己累垮。

陷阱在于把它当“乐于助人”的活动，而不是当作有边界的、刻意的、可见的影响力。

尝试给它设时限，轮换做，把它变成产出物：文档、模板、自动化。

让它作为“影响力”被看见，而不是作为“性格特点”。

14. 如果你赢得每一场辩论，你很可能是在积累无声的阻力

当人们不再和你争，不是因为你说服了他们，而是因为他们放弃了。

但他们会在执行中表达分歧，而不是在会议上。

所以真正的共识需要更长时间。你得真正理解别人的观点，吸收反馈，有时候需要你当众改变主意。

短期“我是对的”的快感，远不如长期和心甘情愿的合作者一起建设的现实来得珍贵。

15. 当衡量标准变成目标时，它就停止了衡量

你暴露给管理层的每个指标，最终都会被博弈。

不是因为恶意，而是因为人会优化被度量的东西。

追如果你追踪代码行数，你会得到更多的代码行数。如果你追踪开发速度，你会得到过高的估算值。

高手的做法是：对每个指标请求都提供一对指标。一个用于衡量速度，一个用于衡量质量或风险。然后，坚持解读趋势，而不是盲目追求阈值。

目标是洞察，而非监控。

16. 承认自己不知道的事情比假装自己知道更能带来安全感

资深工程师说“我不知道”并不是示弱——他们是在鼓励大家坦诚面对。

当领导者承认自己的不确定性时，就等于在暗示其他人也可以这样做。如果不这样的话，就会形成一种人人假装理解、问题被掩盖直到爆发的文化。

我见过团队里最资深的人从不承认自己不明白，我也见过由此造成的后果。问题不被问出来，假设不被挑战，初级工程师保持沉默因为他们以为别人都懂。

17. 你的人脉关系比你拥有的任何一份工作都更长久

职业生涯早期，我专注于工作本身，忽视了人脉经营。回头看，这是个错误。

那些注重人脉关系的同事，在接下来的几十年里都受益匪浅。他们最先了解机会，更快地建立人脉，获得职位推荐，和多年来建立信任的人一起创业。

你的工作不会永远持续下去，但你的人脉网络却会一直存在。

以好奇心和慷慨的态度去拓展人脉，而不是抱着功利主义的心态。

当需要向前迈进的时候，往往是人际关系打开了这扇门。

18. 大多数绩效的提升来自于减少工作量

当系统变慢时，人们的第一反应往往是加东西：加缓存、并行处理、使用更智能的算法。

有时候这样做是对的。

但我发现，通过询问“我们计算了哪些不必要的东西？”往往能带来更多性能提升。

删除不必要的工作几乎总是比更快地完成必要的工作更有成效。最快的代码是永远不会运行的代码。

所以在进行优化之前，先问问自己这项工作是否真的应该存在。

19. 流程存在的目的是为了减少不确定性，而不是为了留下书面记录

最好的流程是让协调更容易、让失败成本更低。

最差的流程是官僚主义——它的存在不是为了帮忙，而是为了出事时推卸责任。

如果你无法解释一个个流程如何降低风险或提高清晰度，那么它很可能只是增加了额外开销。

如果人们花在记录工作上的时间比做工作的时间还多，那就说明出了大问题。

20. 最终，时间会比金钱更有价值

刚开始工作的时候，你用时间换钱——这没问题。

但到了某个阶段，情况就完全不同了。你会开始意识到，时间才是不可再生资源。

我见过一些高级工程师为了晋升而累垮自己，只为了多拿几个百分点的薪酬。有些人确实升职了，但事后大多数人都在反思，自己放弃的一切是否值得。

答案不是“别努力工作”，而是“知道你在交易什么，并深思熟虑地进行交易”。

21. 没有捷径，但有复利

专业技能源于刻意练习——略微超越现有水平，然后不断反思，不断重复。年复一年，没有捷径可走。

但令人欣慰的是：学习的进步在于创造新的选择，而不仅仅是积累新的知识。

写作——不是为了吸引眼球，而是为了清晰表达。构建可复用的基础模型。将过往的经验总结成行动指南。

所以如果工程师把职业生涯看作是复利投资，而不是彩票，那么他最终往往会取得更大的成就。

22. 最后

21 条听起来很多，但它们可以归结为几个核心点：保持好奇，保持谦逊，记住工作始终是关于人的——你的用户、你的队友。

工程师的职业生涯足够长，可以犯很多错误。我最钦佩的工程师，不是那些什么都做对的人——而是那些从错误中学习、分享发现、并坚持不懈的人。

本篇整理自《21 Lessons From 14 Years at Google》，希望能帮助到你。

我是冴羽，10 年笔耕不辍，专注前端领域，更新了 10+ 系列、300+ 篇原创技术文章，翻译过 Svelte、Solid.js、TypeScript 文档，著有小册《Next.js 开发指南》、《Svelte 开发指南》、《Astro 实战指南》。

欢迎围观我的“网页版朋友圈”，关注我的公众号：冴羽（或搜索 yayujs），每天分享前端知识、AI 干货。

本文面向种子轮、A 轮的产品/技术管理者，拆解早期工程团队最常见的管理反模式，重点是少花力气「管人」，把精力用在产品、用户和招聘上。

很多创始人都会经历类似的一天：

产品刚有一点起色，团队有 6、7 个工程师，大家各自忙着写代码。你刷了一圈飞书、钉钉、Jira，看到没人「熬夜上线」、「周末加班」，心里开始打鼓：

我是不是该「管一管」了？

要不要设周末站会？

要不要赶紧招个工程经理？

在早期，绝大多数你以为的「管理问题」，本质上都不是管理问题，而是产品和招聘问题。

对种子轮、A 轮阶段的产品/技术管理者来说，最值得警惕的，是那些听上去很「负责」、实际上却严重分散注意力的管理动作。

下面，我们把这些反模式拆开讲清楚。

一、问题：为什么你总觉得「需要管理」？

在早期工程团队里，创始人最常见的一种焦虑是：

• 工程师好像没那么「拼」，没人自发熬夜
• 项目进展不够「可见」，看不到随时可展示的进度条
• 组织结构还很扁平，感觉「不像一家真正的公司」

这时，很容易滑向一个直觉：

我需要更多的管理：更多会议、更多流程、更多角色。

但如果你还在找产品/市场匹配点（PMF），事情恰好相反：

• 你最需要的是把所有可用的精力，放到产品和用户身上
• 任何与此无关、但会占用创始人和工程师时间的管理创新，都是巨大的机会成本

所以，真正的问题不是「缺不缺管理」，而是：

在这个阶段，哪些「看上去像管理」、但其实只会拖慢团队的动作，应该被坚决避免？

二、误区：三种常见的管理反模式

误区一：试图靠「打鸡血」激励工程师

很多创始人一看到团队不够「燃」，就开始想办法「激励」工程师：

• 鼓励甚至默认 996 式的长时间工作文化
• 把原本可以异步的事情，塞进周末或晚上的会议
• 各种形式的微观管理：频繁要进度、要截图、要「证明你很努力」

问题在于，优秀的工程师，要么一开始就自带动力，要么很快会被这种文化劝退。

记住这个重要结论：

动力是招聘进来的，不是管理出来的。

当你花大量心思去「点燃」团队时，往往说明有两个地方出了问题：

1. 招聘时，没有足够重视候选人的内在驱动力、韧性和好奇心
2. 环境没有给这些本来就很自驱的人，足够的空间和意义感

可执行建议： 把「是否自驱」当作硬标准写进招聘评分表，而不是事后靠文化口号来补课。

误区二：过早引入管理者和头衔

另一个常见做法是：一到十几个人，就开始「像大公司一样」搭管理架构：

• 给团队划小组、设组长、甚至招全职工程经理
• 安排定期的一对一、绩效评估、晋升路径设计
• 为了「有条不紊」，大规模引入流程、里程碑、报表

听上去都很负责任，但在早期，这往往意味着：

• 你还在搞清楚到底该做什么产品，却已经请来一个「负责把事做对」的人
• 管理者不得不创造各种「管理工作」 —— 安排会议、管理 Jira、评估绩效，以证明自己有价值
• 很难判断问题出在产品、在工程师，还是在管理者身上

下面给出一个简单的分阶段视角：

• 5–6 人（含技术创始人）：阶段太早，不需要管理者。创始人主要做两件事：招人和（在极端情况下）开人，其余让团队自组织。
• 10–15 人、2–3 个子团队：所有工程师依然可以向一个人汇报（通常是 CTO），这是打磨工程文化的关键窗口期。
• 20–50 人：这时才是引入更多组织架构和管理层的阶段，此时团队规模扩大带来了混乱，开始真实限制产出。

可执行建议： 在 20 人之前，慎重对待任何「全职只做管理、不写代码」的角色设计。

误区三：照抄大厂的「先进管理实践」

还有一种更隐蔽的反模式，是把大厂的管理实践，当成早期团队的模板：

• 全套 Scrum 仪式：每日站会、迭代回顾、燃尽图
• 复杂的绩效体系、胜任力模型、晋升委员会
• 花哨的反馈机制、同行评审流程

问题不在于这些方法本身，而在于阶段错配：

大厂管理的是一台已经运转起来的机器；

你在早期时，还在造发动机。

早期团队的管理栈，应该像「Node + Postgres」—— 普通、稳妥、被无数人试过，不会成为公司失败的原因。

换句话说，在管理这件事上，越无聊越好。

可执行建议： 每当你想引入一个「很新」「很酷」的管理做法时，先问一句：如果不用，我们真的做不出产品吗？

三、方法：少做管理，多做这几件事

如果说上面三种是「别做」，那早期工程团队到底该「做什么」？有一个很实用的思路：

用「不情愿的管理者」心态，去做那一小撮真正必要的事。

1. 把精力放在「招对人」上

• 招聘时，刻意寻找那些有真正动力的人：主动加班、愿意为难题投入超预期精力，但不是被逼出来的
• 关注候选人经历里的「挫折时刻」 —— 遇到过什么困难？怎么扛过来的？
• 是否有持续的好奇心：愿意聊某个技术、某个兴趣时会「眼睛发光」

一旦招到这样的人，不需要做什么管理，更多的是别把他们的热情消耗在无意义的流程上。

2. 用最轻量的方式对齐方向

• 状态更新尽量异步完成：文字周报、短更新，而不是天天站会
• 对需求和优先级，用几篇共享文档就够了，没必要一上来就搭一整套系统
• 把「为什么做这件事」讲得非常清楚，比「怎么做、按什么节奏做」重要得多

当方向清晰、上下文透明时，优秀工程师自然会自己填补细节。

3. 保护工程师的注意力，而不是占用

• 钉钉、飞书是刚需，但要警惕演变成「注意力黑洞」
• 少 @ 全员、少搞临时化同步会议，多用异步文档和评论
• 鼓励大块、不被打断的深度工作时间，而不是随时在线的「响应速度」

真正的「高效」，往往体现在有多少时间被保护下来，而不是被填满。

4. 让一对一和反馈「有事可谈」

• 不做为了「保持关系」而开、却没有明确议题的例行 1:1
• 更鼓励基于具体问题、具体项目的临时对话
• 当有人真的有卡点、困惑或情绪时，再打开深入的沟通空间

这类关系，是在一起解决问题的过程中自然生长出来的，而不是靠日历上固定的时间段培养出来的。

可执行建议： 让「时间块」成为支撑深度工作的精简模块，而不是塞满整周日历的主角。

四、清单：给早期产品/技术管理者的对照表

如果你正在带一个 5–20 人的工程团队，可以用这份清单自查：

[ ] 最近一个月花在招人和面试上的时间，是否明显多于花在设计新管理流程上的时间？  
[ ] 是否在试图用流程和制度，去「拯救」一个本就不合适的招聘决策？  
[ ] 团队大部分状态更新，是否可以通过异步文档就能完成？  
[ ] 团队会议是否都有清晰议程和产出，而不是为了「看起来在管理」？  
[ ] 工程师是否能直接接触完整的业务上下文（用户反馈、营收数据、产品决策），而不是只拿到被筛选过的片段信息？  
[ ] 你是否依然亲自参与关键的产品和技术决策，而不是过早把这些权力和判断交给「管理层」？  
[ ] 当你觉得「需要更多管理」时，是否先问过自己：是不是该先多去几次用户访谈？

可执行建议： 每季度用这份清单做一次复盘，把那些「想不到不做也没关系」的管理动作，都列入精简候选。

五、总结：当你觉得需要「管理」，往往应该回到产品

在种子轮、A 轮阶段，如果你觉得自己有很严重的「工程管理问题」，九成的正确解法是暂时什么都不做，先去找用户、做产品、招对人。

早期工程团队最重要的管理决策，往往只有三件：

1. 招谁进来 —— 是否真的自驱、好奇、愿意为问题多走一步
2. 给他们怎样的环境 —— 信息是否透明、目标是否清晰、是否能安心做事
3. 在什么时刻引入管理 —— 坚持「能用 Node + Postgres，就别造新数据库」式的朴素标准

如果说传统管理在乎的是「把机器调得更顺」，

那早期管理更像是：守住几条简单的边界，让真正重要的工作自己长出来。

当你下次忍不住想「多管一点」时，不妨先问自己：

我现在做的这件事，真的会让我们更快找到产品/市场匹配吗？

如果答案是否定的，那也许最好的管理动作，就是先按下暂停键。

Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com，一起交流成长。

本文由mdnice多平台发布