说个真实的场景。
上周帮一个团队做技术复盘。他们的产品上线半年，迭代速度从最初的两周一版，变成了现在的一个月一版。
CTO以为是代码质量的问题，花了三周搞重构。
重构完，还是慢。
后来我花了一天时间跟他们核心成员聊了聊，发现问题根本不在代码层。是三个决策没做对——技术栈选型、招人的评估标准、技术债的处理节奏。
这三个决策，每一个都不紧急，但每一个都在持续产生负面影响。
我管这类决策叫"复利型决策"。做对了，收益会随时间放大。做错了，成本也会。
第一个：技术栈选型的"从众效应"
技术人选技术栈，最常见的逻辑是：大厂用什么我就用什么，社区热门我就跟。
这个逻辑有个致命漏洞——你看到的"最优解"，是别人基于自己的规模、阶段和约束条件得出的。直接搬过来，很可能变成你的最劣解。
上面那个团队就是典型案例。他们在B轮阶段，12人技术团队，产品还在PMF验证期。CTO参考了某大厂的架构方案，直接上了微服务。
结果呢？光维护微服务的基础设施就占了两个全职开发的工作量。业务迭代速度反而降了40%。
不是说微服务不好。而是在12个人的团队、需求每周都在变的阶段，单体架构+好的代码组织就够了。等用户量到了需要拆的规模再拆，迁移成本远低于提前过度设计的维护成本。
技术栈选型没有"正确答案"，只有"适配答案"。
关键问题永远只有一个：这个选择，适配我当前的团队规模、业务阶段和技术积累吗？
第二个：招人只看技术能力
我帮不止一个团队复盘过招人失误。
最常见的模式：面试全考算法题，代码能力过关就发offer。入职后才发现——这个人不跟产品沟通、需求理解有偏差也不问、写完代码不写文档、出了问题先甩锅。
代码能力是门槛，不是决定因素。
真正决定一个人长期价值的，是三个"软维度"：能不能理解业务需求、能不能跟团队高效协作、能不能在模糊场景下自己做判断。
但这三样东西，面试的时候很难量化评估。所以很多团队干脆就不评估了——只看代码能力，至少"公平"。
公平是公平了，但招来的人能不能用，全靠运气。
后来我建议那个团队调整了面试流程。增加了一个30分钟的"业务场景讨论"环节：给一个真实的产品需求，让候选人当场拆解——他会问什么问题？怎么定义边界？怎么排优先级？
这一轮下来，代码能力差不多的人，差距就拉开了。
第三个：技术债"要么全还，要么不还"
大部分团队处理技术债的方式，是在两个极端之间反复横跳。
阶段一：赶产品上线，怎么写快怎么写。代码里全是临时方案，注释写着"TODO: 后续优化"。
阶段二：系统终于扛不住了，花三个月搞大重构。重构到一半，业务需求又变了，代码又得改。
来回折腾几次，团队对"重构"两个字都产生了心理阴影。
其实技术债的处理不是"还"或"不还"的选择题，是"怎么还"的节奏题。
比较务实的做法是：每次迭代固定留出20%的工程时间，专门处理"当前最危险的技术债"。不用停下来搞大重构，每次清理一点，持续释放压力。
这不是技术问题，是资源配置的决策问题。
很多团队不是不知道技术债要还，是没人帮他们算清楚：不还的隐性成本是多少？还的投入产出比怎么算？
这三个决策的共同点
你会发现，这三个决策有一个共性：都不紧急，但都影响长期。
技术栈选型，影响的是未来一两年的架构演进空间。招错一个人，影响的不只是他的产出，还有团队的协作效率和文化。技术债的处理节奏，决定的是团队的长期迭代速度。
技术人最擅长处理的是"紧急且明确"的问题——bug要修、服务要恢复、接口要对齐。
但这些"不紧急但重要"的决策，才是真正拉开团队差距的地方。
不是说要花大量时间去做完美的决策。而是至少在动手之前，花点时间想清楚三个问题：
- 我当前最该关注的是什么？
- 这个选择的长期影响是什么？
- 如果选错了，退出成本有多高？
想清楚这三个问题，大部分决策的质量都会上一个台阶。
省下来的不是时间，是方向错了之后的半年。
