有个现象我一直觉得很有意思：很多技术Leader当了Leader之后，比当个体贡献者时更忙了。

这不正常。

如果你的管理是有效的，你应该比以前更闲才对——因为你把事情分出去了，别人在做。但现实是，大部分Leader的日常是这样的：早上站会听进度，上午review代码，下午排需求优先级，晚上还要处理线上问题。忙得脚不沾地，但回头一看，团队离了你好像啥也干不了。

你以为这是"能者多劳"，其实这是一个信号：你根本没在管人，你还在管事。

管事和管人，不是同一件事的两种叫法

我见过不少刚做管理的朋友，聊起来都说"我在带团队"。但你仔细看他们的工作内容：拆任务、派活、盯进度、review产出、解决技术卡点……这些是管事还是在管人？

都是管事。

区别很简单：管事关注的是"事情有没有做好"，管人关注的是"人有没有成长"。前者是项目管理的范畴，后者才是团队管理的核心。

这个区分听起来像废话，但大部分技术Leader从来没认真想过这个问题。因为在工程师的世界观里，把事情做好就是一切。升Leader之后，自然也觉得"把团队的事情管好"就是管理。

做了这么多年技术，我发现一个挺有意思的现象：几乎每次技术方案评审，都会有人提出一个"理论上最优"的方案，但最后落地的，往往是那个"看起来不够优雅"的方案。

这不是偶然。背后有一套残酷的逻辑。

那个"完美方案"为什么总是死在会议室里

上周技术评审会，前端团队提出要引入微前端架构，理由很充分：模块解耦、独立部署、技术栈自由、团队自治。PPT做得精美，架构图画得漂亮，甚至连落地路线图都准备好了。

然后架构师问了一句："谁来维护基座？iframe降级方案谁负责？跨应用通信出问题谁排查？"

会议室安静了30秒。

最后的决定是：继续用现有的Monorepo + 模块化方案，虽然不够"先进"，但团队都熟悉，出问题知道怎么修。

这不是个例。我见过太多"技术上正确"的方案，死在各种现实问题上：

- 服务化改造，拆到一半发现团队根本撑不起这么多服务
- TypeScript全面迁移，三个月后发现一半团队还在用any
- GraphQL替代REST，半年后发现后端团队都不会写resolver
- Kubernetes上云，结果运维团队连基本的Pod调试都不会

Monorepo 最近几年成了前端工程化的显学。Google、Meta、微软都在用，Turborepo、Nx 这些工具层出不穷，到处都在讲 Monorepo 的好处。但我观察下来，大部分团队引入 Monorepo 之后，要么是用成了"巨型仓库"，要么是过度拆分变成了"伪 Monorepo"。

真正的问题不是 Monorepo 本身，而是大家搞错了它的适用场景。

先说结论：Monorepo 不是银弹

很多团队看到 Google 用 Monorepo 管理几十亿行代码，就觉得自己也该用。但这里有个认知偏差：Google 的 Monorepo 是为了解决他们特有的问题——跨团队代码共享和依赖管理。

你的团队有这个问题吗？

大部分团队的实际情况是：
- 前端就 3-5 个人，管理的项目不超过 10 个
- 业务相对独立，跨项目共享的代码不多
- 没有复杂的内部依赖关系
- 团队协作流程还没稳定下来

这种情况下，Monorepo 带来的复杂度远大于收益。

每次看到 Dependabot 或 Renovate 提的 PR，我的第一反应不是"好，及时更新"，而是"又来了，这次会炸在哪"。

这不是危言耸听。见过太多次：一个看似无害的小版本更新，导致生产环境莫名其妙地挂掉；一个"修复安全漏洞"的补丁，带来了更严重的 breaking change；一个"只是升级 devDependencies"的操作，让 CI 流水线跑不起来。

行业里有个有意思的现象：所有人都在说"依赖要及时更新"，但实际操作中，大家都在拖延。不是因为懒，是因为怕。

这种恐惧是有道理的。

语义化版本的美丽谎言

Semantic Versioning（语义化版本）告诉我们：`major.minor.patch`三段式版本号清晰明了，patch 是 bug 修复，minor 是功能新增，major 才是破坏性变更。所以升级 patch 和 minor 是安全的，对吧？

对个屁。

去年金融业务的一次故障，就是因为某个依赖的 minor 版本更新。库的作者认为他只是"优化了内部实现"，所以只升了 minor。但这个优化改变了某些边界情况下的行为，恰好触发了我们业务代码里一个隐式依赖的逻辑。