首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >海外IT老兵谈996:人才不是加班加出来的,期待有企业能站出来破局

海外IT老兵谈996:人才不是加班加出来的,期待有企业能站出来破局

作者头像
深度学习与Python
发布2021-01-21 11:14:12
3800
发布2021-01-21 11:14:12
举报

作者 | Leo Huang(黄力菲)

要打破这个非合作博弈的均衡,必须有公司的引导和介入。

作为一个美国 IT 的业内人士,我一直关注国内 IT 的发展。35 和 996 这两个数字在微信里,不论是朋友圈还是公众号里,都是屡见不鲜了。最近的这篇文章《40 岁程序员被 90 后训斥不 996,这世界怎么了?》成功的把这两个数字放进了同一个标题。

“他很委屈,我的产出并不低,不比任何一个坚持 996 的 90 后更低。这一点 90 后的领导倒是也承认。他的产出不是问题,但是领导认为,他这样的工作态度不好,希望他改进。他说,我做好我的本职还不够么?做得快,做得更好难道是错误么?非要我每天 996 不就成磨洋工了。但是领导还是坚持,甚至说即使你的能力再强,如果你的态度达不到公司的要求,可能就要谈是不是要他辞职的问题了。”

——摘自 tinyfool 的《40 岁》

这篇文章凸显了大龄软工的尴尬局面,加上最近流行的“内卷”话题,我也想谈谈我的一些想法。

加班文化和 996 是造成程序员这个职业内卷的一个重要原因,在没有制度的约束下,其实这就是一个非合作博弈。程序员上班是没有时间和空间界限的,一天八小时不可能成为博弈的均衡点。一旦一个团队或是公司开始有人加班,并因此拿到薪资或是晋升上的回报后,其他人肯定会效仿跟上,不愿意加班的被淘汰,最后达到的均衡点就是 996。因为这个基本上是程序员还能维持身体健康和家庭和睦的底线了:再增加工作量,个人生活上的损失就会超出事业上的获利;减少工作量,就会在职场上吃亏。如此,没有人能单方面的改变策略来获得更大的综合利益,这就是这场博弈的均衡点。

996 下的产出确实能够为公司带来更多的经济效益,可是最后返回到个人的额外回报和大家的多余付出能否匹配?假设后者远大于前者的情况下,那么这个非合作博弈最后均衡点的最大受益人是公司和他们的高层,而不是大家的福报。

996 造成的另一个局面就是 35。35 岁已经成为程序员公认的职场分水岭,年纪大了,有家有小,确实在体力上拼不过年轻人,在这种加班文化下被淘汰也是很自然的结果。

如何避免 996 和 35 这个内卷的均衡点呢?只能靠企业文化。企业文化,成也萧何败也萧何。

螺丝钉与 10 倍程序员

为什么 996 有它的一席之地呢?我觉得要从程序员的价值讨论起。程序员到底是创造性人才还是技术工人?《40 岁》一文中把普通程序员说成是“炮灰”,我觉得这个是夸张了,作者的意思可能就是做个“螺丝钉”而已。它对“有的公司宁可牺牲一个优秀的 10 倍程序员,也不想让他把 100 个普通程序员给‘带坏了’”的说法,在某种价值体系下是成立的。如果一个公司只是把“普通程序员”当作工人或是螺丝钉,那么他们看中的是执行力和埋头苦干的精神──不一定要有多少创新,因为方向上面都定好了。对他们来说,螺丝钉更好使,更能产生生产力。

为什么 996 这个非合作博弈在另一些 IT 公司不成立呢?在《How Google Works》一书中,谷歌的高管给出了他们的招人准则,就是所谓的“smart creative”:他们不是传统的 knowledge workers(知识工人),而是非常有创造力,敢于尝试,不怕失败,“不听话”的工程师。

这样的人在 Facebook 叫做 hacker。这样的人在网飞叫做 creative worker。你说,他们可以用 996 来约束吗?如果项目充满了挑战,你拿枪杆子顶着他们也无法阻止他们夜以继日的工作;反过来,如果他们觉得分配的项目无聊,三驾马车也拉他们不来,他们或者发掘自己的项目,或者就和你 byebye 了。所以这样的公司是不会推崇加班文化的,也绝对不会有上司质问下属为什么到点就下班了,因为这么做是以最快的速度把你的 smart creative 推向你的竞争对手的怀抱。

所以解决这个问题的第一步是对程序员的定位和价值评估。不同的价值观导致不同的公司文化。如果公司任其自然的话,或者是从根本上认为这个是职工的“福分”,鼓励加班文化(就不说要求加班了),那么这种内卷式的恶性竞争就会发生。

要打破这个非合作博弈的均衡,必须有公司的引导和介入。在美国的很多 IT 公司,管理层费尽心机来阻止 996 的发生。Facebook 的每个 manager──上到 VP,下到一线经理──半年一次的民意调查都会有叫做 work-life balance 的一项指标。为了减少职工的工作压力,公司在办公通讯应用里加上了 silent 模式的消息,以及延时消息,这样不会在工作时间之外打搅大家的正常生活。我相信被微信管理,随时需要回复老板消息的程序员来说,这才是一个不错的福分吧。作为一个技术总监,我的工作繁忙,但是可以自由掌握工作时间。有时我会选择在晚上安静的时候工作,在这种情况下我给团队的 after-hours communication 都尽量采用延迟发布的功能。

影响博弈最重要的要素就是局中人的 incentive(激励),这也是企业文化可以改变的。《40 岁》一文里提到了十倍程序员──实际上还有百倍程序员,这里统称十倍程序员。像谷歌、微软和网飞这样的公司是如何避免十倍程序员的外流的?十倍程序员就应该有十倍的报酬。这里指的十倍,是个虚数,具体多少,每个公司不一样。

网飞在《No Rules Rules: Netflix and the Culture of Reinvention》一书中给的是“rock-star pay”,具体是市场的最高价;谷歌在《How Google Works》里称其为 disproportional;比尔盖茨认为一个伟大的程序员的价值是平均程序员的万倍。所以如果以利益驱动的话,在这样优厚十倍程序员的公司,加班不是一个优秀程序员的博弈策略,他们的目标是十倍程序员。

事实上,十倍程序员的激励更多的来自工作本身的挑战和成就感,而不是薪酬,就像《How Google Works》一书中提到的。改变了大家的 incentive,这个非合作博弈的僵局就自然破解了。这些 smart creative 对公司价值不是以他们的工作时间来衡量的,而是他们的创造力:他们为公司开辟新的方向,给团队和公司带来更多的机会,这再也不是一个零和博弈的内卷,而是双赢;这不是 involution(内卷),而是 evolution(进化)!

天才也需要时间的积累

回到悬在程序员头上的另一个数字“35”岁:这个数字就像一个闹钟一样,滴答滴答,让人焦虑。我在职业生涯里主导和审阅了几百次的面试,招聘了大批的工程师,年龄这个词从来没有在招聘讨论中出现过。

当然我们这里(美国)有法律禁止在招聘中年龄性别等的各种歧视,但这并不是唯一原因。只靠法律的威慑是不够的,因为隐形歧视其实是很难抓住实证的,所以需要在公司文化上把年龄和性别歧视给排除了。

为什么 35 在国内是个坎,就是因为我们前面讨论的程序员的价值定位问题。如果作为智力劳动者,那么拼体力,拼奉献是拼不过年轻人;但如果找的是 smart creative 和十倍程序员,那就是另一回事了。这样的人才不是靠加班加出来的,也不是由年龄决定的,天才也需要时间的积累,具体请参考 Malcolm Gladwell 的一万小时定律。我带的一个十倍程序员就是八年时间培养出来的。

如果程序员都着急转去做管理,那么再好的人才也没有足够的空间发展。解这个局需要整个业界的改变,因为程序员为了保证职场的移动性,必须整体考虑业界的需求,如果整个业界都是那 35 为切割线,那么他们也没有选择。

期待领头羊企业出现

解铃还须系铃人──非合作博弈的僵局同样可以用博弈的方法来解,但是这个需要从公司内部的博弈上升到产业界博弈。

没有人喜欢 996 和 35,现在的年轻人也要考虑自己 35 的时候。

如果在中国有一两家公司能够以 smart creative 为团队,达到像网飞所追求的人才密集度(talent density),摒弃加班文化,产生巨大的创新和十倍的效率,做到产业的第一,以他们的企业文化和竞争力吸引更多的 smart creative,形成正反馈,那么他们就有可能成为这场新的非合作博弈的领头羊,成为竞争者的效仿对象,从此改变产业博弈的走向,走向一个优的均衡点。

国内最近十年的 IT 和互联网迅猛发展,很多领域已经开始领先世界,全球有目共睹。我希望国内的同行在这个 996 和 35 的局面上能够有所突破:“长风破浪会有时 直挂云帆济沧海!”注:本文仅代表作者个人的观点。

作者简介:Leo Huang(黄力菲),在美国科技公司工作多年,有十年以上的软件工程师经验,五年前转型技术管理,现任工程总监,带领近 80 人的跨国团队。个人中文博客 Writing Is Leading:https://writingisleading.com/。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-01-13,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 InfoQ 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档