科技公司正让不懂技术的工程经理悄然退场

技术面试 软件工程 产品 决策 非技术背景工程经理的悄然消失。

Emily 4分钟阅读· 2026年5月11日

为什么公司终于意识到：如果你无法评估架构，就管不好一个软件团队。

大约十年来，科技行业说服自己相信：管人和管系统是完全独立的两种技能。这催生了一代从未真正上线过生产代码的工程经理。他们靠电子表格、速度指标和 Jira 燃尽图来管理团队。我认为那个时代正在终结——随着工程团队规模缩小、AI 工具提升个人产出，让一个需要别人用类比来解释技术权衡的经理继续存在的管理成本，已经变得太高了。行业正在回归到这样的经理：他们能读 pull request、能排查线上故障、能直接告诉产品经理某个功能为什么会把数据库搞垮。

如果你曾经向一位非技术背景的工程经理汇报过，你完全清楚那种“翻译税”是什么滋味。

那就是你每周花一个小时，试图解释团队为什么需要暂停功能开发去重构支付网关。因为经理不懂代码库，你没法直接告诉他们当前的耦合正在制造循环依赖。你必须编一个类比，告诉他们这房子地基不行，我们得先浇新混凝土，才能盖二楼。

他们点头、记下来，然后去产品团队那边，却没能守住技术债冲刺——因为他们并不真正理解那个“混凝土”，他们只知道那个类比。

这种税消耗的是团队的动能。工程师最终开始在暗中做架构决策，把重构工作藏进功能工单里，因为偷偷把活干过去，比向经理解释清楚要容易。当经理无法参与团队的技术现实时，他们就变成了一个薪水更高的项目经理。

当你无法评估工作质量时，你就会去评估工作的指标。

非技术背景的经理高度依赖仪表盘。他们看完成的 story point、合并的 pull request、关闭的工单。他们把软件工程当成制造业流水线。

我曾经有一位经理，在团队会议上表扬一位工程师一周关闭了十二个工单。我看过那些工单。全是些 CSS 微调和文案修改，每个五分钟就能搞定。与此同时，另一位工程师花了一整周理清我们后台 worker 里一个竞态条件——这个 bug 一个月来一直在丢用户数据。那位工程师只关了一个工单。在经理的仪表盘上，第一位工程师是高绩效者，第二位是瓶颈。

如果你分不清忙碌的杂活和真正的工程影响，你就带不了一支技术团队。当领导层为仪表盘上的指标做优化时，团队就会为仪表盘上的指标做优化。代码在腐烂，而速度图表看起来棒极了。

工程经理最重要的工作，是保护团队免受糟糕产品决策的伤害。

产品经理的职责就是快速要东西。他们会问某个新功能能不能周五上线。懂技术的工程经理了解系统。他们知道加那个功能需要在一张五千万行的表上加新索引，这会锁表，白天部署就会导致线上故障。他们会立刻用技术现实顶回去。

非技术背景的经理则必须把需求带回团队，让工程师估时，再把估算带回产品那边，充当传话筒。如果产品经理推得够狠，非技术经理往往会妥协，因为他们缺乏技术底气来守住底线。他们答应下截止日期，把团队逼进一场死亡行军。

公司正在注意到这一点。这种转变在纽约和湾区已经发生。纯粹的人员管理岗位正在被逐步淘汰，或转回项目管理。

取代它们的是技术主管型经理（Technical Lead Manager）。这些人是资深工程师，百分之五十的时间写代码、设计架构，另外百分之五十的时间管理写其余代码的人。

他们不需要类比。他们审 pull request。他们凌晨两点在事故应急电话里。当他们告诉产品某个功能要一个月时，他们清楚知道需要改哪些文件才能实现。

管人是一项独立的技能，同理心不可妥协。但在软件工程里，技术能力是同理心的前提。如果你不理解一个脆弱的遗留系统为什么脆弱，你就无法有效地支持一位被它折磨到精疲力竭的工程师。

最后的思考

如果你现在正是一位向非技术经理汇报的工程师，你的职业成长在一定程度上被封顶了。他们无法评估你的技术进步，这意味着他们无法基于你工作的复杂度为你争取晋升。他们只能基于你的曝光度和指标来为你说话。

如果你正在面试新职位，你能问的最重要的问题，是关于你未来经理的技术背景。问问他们上一次必须在架构决策上打破僵局是什么时候。如果他们的回答是“让团队自己决定”，那他们是在告诉你：他们没有领导团队的技术权威。

如果你正在准备这类面试，想知道如何区分高绩效工程文化和功能工厂，PracHub 在其公司专属指南中列出了文化与管理的危险信号。因为通过技术面试，只有在你加入的团队由一个真正懂行的人带领时，才有意义。