程序员转型 HR：我发现的意外优势

本文的作者本硕 7 年的专业是软件工程，从事 8 年编程及技术管理工作，于 2025 年中旬转型为一家创业公司的 HR 一号位。

最近我在为我们 HR 团队招募新伙伴。期间不少候选人看了公司官网上我的介绍信息以后，会冒出这样一个疑问：“你们公司的 HR 老大为什么会是个技术背景的人？” 背后包含一个非常直白的质疑：你来管 HR 团队，到底靠不靠谱？

我叫邹润阳，算是科班出身的程序员。大学时有一次课程作业，我需要在二维棋盘中模拟蚁群的生存：食物生成速度、能量消耗、繁殖速度……所有决定这个世界走向的数值，都由我掌控。那一刻我意识到：程序员就是某个微缩世界的规则制定者。

而作为 HR，尤其是作为一个大事业部的 HRBP 或者作为公司 HR 一号位，他往往就是和 CEO 合作完成规则制定的重要一员，甚至在很多场景下，是新规则的直接起草者。

于是一个观点悄悄浮出水面：也许程序员转型 HR 有其独特的优势

以下的讲述将分为 5 个小节：

1. 管中窥豹，可见一斑
2. Develop a company as a product
3. 大胆假设，快速求证
4. Let it crash，是成长第一法门
5. 人不是程序：把人当人

管中窥豹，可见一斑

受西方管理学影响，传统的 HR 领域常有三大支柱、六大模块（包括人力资源规划、招聘、培养、绩效、薪酬福利、劳动关系）等说法。自从人社部将六大模块标准化为考试体系以来，有一种 HR 职业发展的思路认为，“我从某个模块入手，未来会逐渐成为一个精通全模块的 HR 高手。” 这是典型的将学生时代打怪升级的思路带入了职场。

然而现实中，人与组织的问题要复杂得多。如果纯粹以模块拆分后的视角来看待这些问题，有两句常用的谚语可以对此做出总结。

管中窥豹，可见一斑。 只见树木，不见森林。

而程序员所从事的工作，天然需要他们掌握一种系统化思考的能力。年久失修的程序会腐化崩坏，因此优秀的程序员无时无刻都在斟酌着如何重构程序、如何优化程序架构、如何处理累积下来的技术债。为了延续自己程序的生命力，程序员们需要绞尽脑汁地考虑如何突破系统当前的最大瓶颈。

而一家公司、一个组织，同样会随着时间的流逝而日渐腐朽、消亡。据经济日报的记者统计，中国企业的平均寿命只有 3-4 年，比人的一生短得多。看起来，如何呵护企业的生命力，亦是当代管理者与 HR 们面临的系统性难题。面对此类问题，程序员们可谓身经百战。

但要记住，人不是代码，组织不是程序——这是我们后面会反复提到的。

Develop a company as a product

在早期的硅谷并不存在专职的产品经理，而是由工程师直接负责产品的设计、开发和迭代。1991年，Linus Torvalds 在宿舍里写了 Linux 内核，决定开源——这事实上是产品战略，而不仅仅是技术决策。1998年，Larry Page 和 Sergey Brin 坚持 Google 首页只放一个搜索框，拒绝加新闻和天气。

这些工程师做产品有个共同特点：他们首先是自己产品的用户。他们的产品直觉来自真实的痛点，而不是市场报告。

小标题中的这句话来自于张一鸣在字节跳动的一次内部分享。当时正处于字节跳动高速扩张的阶段，他需要思考如何构建可持续发展的组织能力。

如果真的把一家公司看作一款产品，这家公司的员工就是这款产品的用户。对于传统的 HR 来说，开发产品是一件非常有距离感的事情。我们有时会看到一些 HR 和员工站在对立面上的案例。他们缺乏尊重与人文关怀，把人当成流水线上的零件。——这种产品经理和用户对着干的诡异现象，居然层出不穷。如果一个产品经理从来不努力了解用户，而只是盯着数据报表看。这样的产品注定失败。

但对程序员来说，开发产品就是自己的日常，甚至不少程序员都习惯于在自己的闲暇时间创作一些独立软件。（更不用说在 Claude Code、OpenClaw 加持下的以曾经十倍、百倍的速度推进产品迭代的程序员了）不过，产品可以快速迭代，人的改变却慢得多——这是技术思维迁移到 HR 领域时，最容易踩的坑。

大胆假设，快速求证

开发一款软件最核心的思想就是 MVP（Minimum Viable Product，即最小可用产品），说的是用最小的成本和时间，做出一个刚好能验证核心假设的产品版本，然后快速投放市场获取真实反馈。这种数据驱动，实证为先的产品开发思路，放在迭代一家公司上尤为重要。这恰恰是几乎每一个具有产品思维的程序员的必备技能。

我见过不少 HR 工作时比较讲究直觉。他们凭经验判断“这个人不行”，凭感觉设计制度，不加选择地挪用外部实践，凭印象做决策。这种工作方式最大的问题是：没有假设，没有验证，没有迭代。

比如在招聘时，他们会因为不是985/211就觉得能力不够，因为大厂出来的就认为一定好用，因为简历有空窗期就怀疑有问题。这些刻板印象看似是“经验”，实则是用简单的标签代替了深入的判断。从来没有人追踪过：频繁跳槽的人，三年后的留存率和绩效表现如何？名校和非名校的员工，长期来看谁的 ROI 更高？大厂出来的人，在创业环境下的适应率是多少？如果把招聘当作产品来开发，这些都是可以被验证和优化的假设。

我并不是说直觉不重要。恰恰相反，我认为直觉和逻辑实证是处于同等重要地位的。在《程序员修炼之道：通向务实的最高境界》一书中，两位作者给出了一个建议“提示 61 倾听你内心的蜥蜴”：

你的蜥蜴脑试图告诉你一些事情，就像是在感知面下潜藏着某种形式的疑虑。这是很重要的。

作为一名开发人员，你已经尝试过很多东西，并已了解哪些是有效的，哪些是无效的。你一直在积累经验和智慧。如果能感到一种挥之不去的疑虑，或在面对一项任务时感觉有些不情愿，那可能是那些经验试图和你说些什么——要注意听。你可能无法确切地指出哪里出了问题，但经过一段时间后，疑虑可能会变得实在，变成可以确定的东西。让直觉来提高你的绩效。

蜥蜴脑是人类大脑中最原始的部分，负责本能反应和生存机制，遇到威胁时会自动触发“战或逃”的应激反应，优先保命而非理性思考。大量糟糕的事情在真正发生前，你的蜥蜴脑早已警铃大作。

Let it crash，是成长第一法门

“Let it crash”（让它崩溃）是 Erlang 系统设计的核心哲学。并不是所有程序员都熟悉 Erlang，乍看之下这句话非常反直觉——就让程序自己崩溃？这不是完犊子了嘛。事实上这一种相当超前的程序设计理念，并且这种思路横向迁移到人才发展领域同样适用。

想象一下你正在教孩子骑自行车。如果一直扶着车座，在地上铺满海绵垫，规定只能在平地骑行，孩子永远学不会真正的骑车技能。这种过度保护看似安全，实际上让系统更加脆弱。

这正是防御式思维的困境。程序员写代码时，如果用层层嵌套的 if-else 捕获每一种异常，这会导致业务逻辑被淹没在错误处理的海洋里。类似的，管理者对下属的决策层层把关，要求“零失败”，结果下属畏首畏尾，成为了一个实实在在的提线木偶。下属因此成长缓慢，管理者反过来还要嫌弃下属能力不行。

Erlang 的“Let it crash”哲学提供了另一种智慧：承认我们无法预测所有情况，与其防御未知风险，不如设计一个让失败变得安全、可发挥价值、可恢复的机制。

三个核心机制：

进程隔离 —— 每个进程独立运行，一个崩溃不影响全局。就像给孩子戴上头盔，这是基础保护。在组织中，对应小团队独立试错，设定明确的预算和时间盒，失败不会拖累主业务。

监督重启 —— 专门的监督进程负责监控，发现崩溃就自动重启到干净状态。就像孩子摔倒后把他扶起来，鼓励再试。在组织中，对应导师支持系统，不干预决策，但在失败时提供指导，帮助团队复盘、清空心理包袱、重新开始。

关注点分离 —— 工作进程专注业务逻辑，容错由监督者处理。就像孩子只需专注学习平衡，不用担心摔倒后果。在组织中，员工专注解决问题，不被“不能出错”的包袱束缚。

这样的设计会带来什么呢？代码变简洁，系统变可靠，能够持续进化。每次崩溃都被记录分析，成为改进的依据。就像教孩子骑车，最好的方式不是永远扶着，而是戴好头盔，选好场地，然后放手让他去摔，去学，去成长。这就是“Let it crash”，它让我们建立起一种鼓励试错的文化。

但要注意，程序崩溃可以重启，人的信任一旦破裂很难修复——所以别忘了 Let it crash 的前提是，你要确保失败是可恢复的。

人不是程序：把人当人

从前面种种描述中，似乎大量软件工程的哲学思想都可以横向迁移到组织领域。然而纯粹的工程师思维放在人身上，仍有不少的坑需要避免。

人不是代码。一切对人的影响，都不能 git revert。我们做出的大量有关人的决策，都具有不可逆性。因此作为 HR，在推动任何新机制、新规则时，都要保持敬畏之心。

相比程序的改变，人的改变慢得多。测试程序可以在几分钟内跑上万次，程序员可以快速修改程序，并测试新程序是否运转良好。但人的改变是极其缓慢的，如果你急于去验证人的变化，往往会铩羽而归。

语言是人类最低效的接口，必须用真诚来仔细倾听。 一个 API 每秒能传输几百 MB 的数据，而人类说话，即使是专业播音员，每分钟也只能清晰表达 250 个字，换算下来不过几千比特每秒——这是百万倍量级的差距。更要命的是，语言还自带有损压缩：你说“这个项目很重要”，对方听到的可能是“要加班了”，理解成“又要被压榨”，最后记住的只有“我很累”。也许这是不少程序员看起来比较自闭的原因。——相比于跟机器交流，跟人交流太低效了。—— 但真正能打动人的、改变人的，唯有真诚。很多时候语言不仅要用耳朵听，还要用眼睛观察，最重要的信息可能就隐藏在皱起的眉宇间，或者藏在一个令人紧张的深呼吸之中。

言行不一带来的破坏力远超你的想象。在程序世界，不同的程序之间需要联动，会设定互相的通信协议。此时最让程序员头痛的一个词叫做“breaking change”（破坏性变动），指程序 A 与程序 B 之间的通信方式变化了，你只有按新规范修改程序，才能使其正常工作。程序员们讨厌 breaking change。而在人的世界，这种 breaking change 可以类比为人与人之间的承诺被毁（言而无信），或对既定规则的践踏。当 HR 作为规则的制定人，却在不断自己打破规则时，这对团队的负面影响是非常巨大的。

结语：这个时代的 HR 是幸福的

回到开头那个问题：“技术人做HR，靠谱吗？”

我的答案是：如果 HR 的工作本质是设计一个让人自由生长的系统，那程序员可能是最合适的人选之一。因为我们习惯了系统化思考，习惯了快速迭代，习惯了在混沌中寻找秩序。

但我也时刻提醒自己：人不是代码，组织不是程序。技术思维可以帮我们更好地理解问题，但真正能打动人、改变人的，唯有真诚。

这个时代的HR是幸福的——我们有了更强大的工具（AI），有了更大的空间去思考人的本质。而作为一个从技术转型过来的HR，我很庆幸自己在这个时间点涉足了这个复杂而充满魅力的领域。

如果你也对HR这个职业感兴趣，或者对“组织运转的底层逻辑”这个话题有想法，欢迎联系我的微信（JerryZou121），我们可以聊聊。