字节为什么没做好工程师文化&技术影响力？

这个话题有点大，仅仅代表我个人在字节工作一坤年的思考（吐槽）总结。

防杠声明：本文作者只是个对业务没有思考，对平台没有价值的万年 2-2，能力平平却喜欢大放厥词，如果对文中观点不认同，那肯定是您对。

一、字节，AKA 大钟寺小百度

早期中国互联网有一个说法，百度的技术、阿里的运营、腾讯的产品，分别抽象了老牌三巨头 BAT 的优势能力。但随着时间的推移，百度的体量逐渐掉队，而阿里的技术运营和影响力构建投入又非常大，坊间逐渐开始认为阿里的技术也是领先的，尤其是历年双十一极限大促场景的考验，更加增添了阿里的技术符号——虽然每次大促好像都会崩。

百度的技术符号，往前追溯的话，是从谷歌退出中国市场后，当时谷歌的技术人员大多都被百度所吸收——搜索引擎对技术能力的要求，加上谷歌退出以后的人才吸纳，再加上百度创始人 Robin 本身就是非常强的程序员，百度浓厚的工程师文化底蕴和技术能力就不奇怪了。

而在字节的发展初期，“百度帮”的技术人员几乎起到了决定性的作用，现在还有个梗把字节叫做熊厂大钟寺分部。为什么这么说呢，可以盘点一下字节的百度系技术高管名录。

首先是中国互联网名字最具江湖气的两位技术高管——杨震原+洪定坤。这两位加在一起的 scope，就约等于字节跳动的 CTO，定坤管 C 端更多，震原更多在 B 端。

这两位都是百度出来的：

杨震原，2005 年至 2014 年期间在百度工作长达 9 年，并担任大搜索副总监一职，主要负责搜索架构工作；2014 年加入字节跳动，在加入字节跳动后主导了推荐算法。

洪定坤，2007 年至 2013 年于百度任职，担任百度贴吧的技术经理，2014  年加入字节，现为字节跳动技术副总裁。

除了这两位以外，其他的像朱文佳、谭待、许立强、吴海峰、朱时雨等等，都有浓厚的百度背景。

按理说，这么多深谙工程师文化、技术影响力的前百度技术高管加入，做好字节的工程师文化建设和对外技术影响力打造，似乎是顺理成章的事情，为什么从体感上来说，我却觉得字节没有做好呢？

二、如果硬要挑毛病呢？

如果硬要去为这个提问找原因的话，我想大概是这么几个方面。

首先是首位度的问题。字节有三个开发者社区同时存在，只对内的工程师社区 ByteTech，收购来的对外的社区掘金，和挂靠在火山引擎业务下的火山引擎开发者社区。

那么问题来了，对外的技术影响力建设，给谁做？首先 pass ByteTech，因为它只做对内。第二个问题又来了，掘金和火山引擎开发者社区的关系和定位是什么？掘金要做中立第三方，外部认可吗？火山引擎自己做开发者社区，跟掘金如何配合联动？掘金根深蒂固的前端属性，对火山卖 B 端产品有帮助吗？这些问题我在字节两年多，一直找不到答案，倒是听说了各种版本字节收购掘金的八卦内幕消息。

对外的技术影响力存在打架的定位问题，对内的工程师文化建设 ByteTech 承接起来应该舍我其谁了吧？遗憾的是也并非如此。

我一直认为，工程师文化和技术影响力建设，应该是个 CTO 工程。应该是从上往下推，而不是从下往上报。

就提一个非常简单的例子，从汇报关系上看，ByteTech 的业务负责人，是洪定坤的 -3 甚至 -4 这个级别，这样的业务负责人又怎么推得动各个业务的技术负责人去做内容生产、活动策划？

从架构上看，这事儿就更扯淡了。我在职期间的 ByteTech 隶属抖音研发，汇报给抖音研发的负责人。我走了以后，听说 ByteTech 和掘金一起给生活服务部门的负责人汇报了，当时我就缓缓打出了个问号？一个业务属性这么重的部门去管文化、影响力这么虚的方向，合理吗？没过多久，架构关系又变了，转到了定坤下面的又一条线，然后层层转包有了新的负责人。

据说定坤一直对 ByteTech 很不满意，ByteTech 建立也已经差不多 8 年了，换了 N+1 个负责人，一直做不起来，赶上国足换教练的频率了。最大的问题我觉得还是出在首位度上。

我在 ByteTech 的最大功绩，就是做了这本《字节中国研发》期刊。

这个项目的背景是，前文提到的抖音研发负责人想做内部技术影响力，于是牵头搞了这个事儿。拉上了抖音、西瓜、头条、番茄等等部门的技术一把手来配合，光对接的 POC 就给我整了几十个，我要做的只是搭个台子、建个机制，拿着鸡毛当令箭指挥这些大佬给我干活儿就行了，最后事儿做成了，老板也爽了。这就是首位度的力量，没有一把手牵头去做协同，从下往上去做，这些人有一个人愿意鸟我都是字节的企业文化做得超出预期了。

第二个问题，我认为出在业务现状与实际需求存在 GAP 上。得益于过去几年的飞速增长，字节高管们对业务的预期、目标之苛刻，只要是在字节工作过的人都能感同身受。

当业务要增长，要转化的时候，它急需的不是转化链路靠前的漏斗池，它要的是最接近漏斗嘴的那个部分。对外的技术影响力打造，往往只是先把池子水蓄上，把羊给圈起来，后面还得有对应的环节去承接。这法子效率太低了，业务压力大不感兴趣。

这个窘境也是目前国内所有的开发者社区面临的困境问题，这里就不多引申下去聊了，有兴趣的朋友可以看我之前写过的这两篇文章：《6年开发者社区工作经历，聊聊我眼中的社区、开源与商业》《出圈的开发者社区，缺位的开发者运营丨2021年终观察》。

这里多嘴再提一句字节跳动技术团队这个公众号，曾经有一段时间，这个号是我负责在运营。当时从内容属性上来看，发得比较多的内容是客户端的技术分享，因为抖音客户端的研发分享比较强势，阅读量也比较高。现在再去看，你会发现阅读量其实挺惨淡的，发的内容属性也跟火山引擎更相关了，这也可以算是一个佐证。

第三个问题，我认为出在习惯的建立上。在高流动性和业务压力下，如果你是字节的研发，你平常会有主动的意愿去 Bytetech 上学习、吸收一些东西吗？我跟很多研发聊过，他们的答案是比较消极的。

ByteTech 之前曾经有过一次特别成功的产品升级，直接让研发生产的技术文章内容量暴增。怎么做的呢？就是支持飞书文档一键投稿到 ByteTech 平台，自动适配文档格式。当时做这个功能的产品和研发，绩效高低得给个 M+起步。

ByteTech 后来又做了一个非常重磅的功能——话题广场，简而言之，就是把飞书话题群里讨论的那些东西搬到 ByteTech 平台上，让研发进话题广场讨论——一个我评价为脱裤子放屁的功能。

我甚至觉得，飞书作为一款办公 IM 工具过于好用了，它对文档、群聊、会议的丝滑集成，导致研发完全没有上 ByteTech 学习、讨论的必要，不管是技术文档分享、阅读，还是基于兴趣方向的话题群，都可以在飞书这个产品上实现自闭环——那么 ByteTech 对研发人员而言，独有的价值是什么呢？好像只剩下薅活动的羊毛。

当一个业务，永远在试错，永远在错，它还有多少价值就得打一个问号了。

本文来自微信公众号：小智碎碎念，作者：小智碎碎念