我一直在跟运营企业工程博客的人交流心得，发现一件挺有意思的事：我个人的博客流量常常超过一家估值九到十位数的公司整个工程博客的流量，甚至有时会高出整整一个数量级。

这让我觉得很奇怪，因为这类科技公司通常有几百到几千名员工。他们比我更有条件写出引人入胜的博客，而且公司从优质博客中获得的收益也远比我个人大得多。

就前者而言，公司员工做过更有趣的工程工作，有更多好玩的故事，知识深度也远超任何一个个人博客作者。至于后者，我的博客能帮我找工作，也能帮公司招人。但我只需要一份工作，所以更多曝光最多让我找到一份稍好一点的工作；而我待过的科技公司，除了一个之外，全都急需招人，还经常被其他公司抢走候选人。而且，我面试时其实不是在和其他候选人竞争（即使我们面试同一个职位，如果公司喜欢我们不止一个人，通常也会多设岗位）。这个博客在求职方面的关键点，在于面试过程能否接受非面试形式的反馈，还是说我会因为常规面试而失败，而多写一篇文章在这方面的边际价值可能非常低。另一方面，公司在招聘时是直接竞争的，所以比另一家公司更有吸引力对他们来说很有价值；复制Cloudflare或Segment在工程“品牌”上的做法，会是一个显著的招聘优势。这套做法并非秘密：这些公司向全世界传播他们的内容，并且通常很乐意谈论他们的博客运营流程。

尽管拥有一个“好”的企业工程博客好处显而易见，但大多数企业工程博客充斥着工程师不想读的内容。模糊、高层次的吹嘘一切多么美好，内容营销，关于新热点的空泛文章（今天可能是把深度学习用在不合适的场景；十年前可能是把“大数据”用在不合适的场景），等等。

为了弄清楚那些拥有优秀企业工程博客的公司有什么共同点，我采访了三家拥有引人入胜的企业工程博客的公司（Cloudflare、Heap和Segment）的员工，以及三家拥有乏味的企业工程博客的公司（我就不点名了）的员工。

从高层次来看，那些引人入胜的工程博客的运营流程都具备以下共同特点：

  • 审批流程简单，所需审批环节不多
  • 很少或无需非工程类审批
  • 对审批有明确或隐含的快速 SLO 要求
  • 审批/编辑流程主要让文章对工程师更具吸引力
  • 高层（联合创始人、C 级或 VP 级）直接支持保持博客流程轻量化

而吸引力较弱的工程博客则具有以下流程特征：

  • 审批流程缓慢
  • 需要大量审批环节
  • 需要大量非工程类审批
    • 非工程类审批往往导致作者感到挫败的修改建议
    • 反复沟通可能持续数月
  • 审批/编辑流程主要为了降低风险，删除具体细节，使文章更模糊，对工程师的吸引力下降
  • 高层实际上不支持博客写作
    • 领导层可能口头认同博客有益，但优先级不足以推动具体行动
    • 改革流程以简化博客写作非常困难；之前的尝试均告失败
    • 减少流程负担需要所有“利益相关者”签字同意（某案例中多达 14 人）
      • 任何单一利益相关者均可否决
      • 无人能单独批准
    • 利益相关者对任何减少流程负担的举措持谨慎态度
      • 批准意味着承担潜在风险（万一出问题怎么办），而自身无明显收益

一家拥有优质博客的公司员工指出，仅设一名审批人或主要审批人的缺点是：若此人忙碌，文章审批可能耗时数周。这确实是个问题，属于集中审批的弊端。但对比其他流程：某公司员工反映，审批通常需要三到六个月，极端案例甚至长达一年。

虽然数周等待对习惯了快节奏公司的人来说显得漫长，但节奏较慢公司的员工若能拥有仅需双倍时间的审批流程，已会欣喜若狂。

以下是我访谈的三家公司的实际流程（按 sha512sum 排序，巧合地对应公司规模递增——从数百人到近千人）：

Heap

  • 有人提出撰写文章的想法
  • 写作者（工程师）与一名“搭档”配对，由搭档编辑并审批文章
    • 搭档是具备良好写作能力的工程师
    • 可能经过多轮修改，甚至调整文章主旨
  • CTO 审阅并批准
    • 通常仅提供少量反馈
    • 可能提出建议，如“设计师可优化此图表”
  • 发布文章

早期编辑阶段曾将草稿发布到 Slack 频道，让“所有人”评论。由于“所有人”都会提出意见，导致大量修改，体验不佳。此流程旨在避免获得“过多”反馈。

Segment

  • 有人想写一篇文章
    • 通常来源于：内部文档、外部演讲、已发布的项目、开源工具（由 Segment 构建）
  • 作者（工程师）撰写初稿
    • 可能会有一位高级工程师协助撰写初稿
  • 直到最近，没有人真正负责反馈流程
    • Calvin French-Owen（联合创始人）和 Rick（工程经理）通常会给出大部分反馈
    • 也可能从经理和工程领导层获得反馈
    • 通常，第三稿被视为完成稿
    • 现在，有一位全职编辑负责编辑文章
  • 同时也会在工程团队内部进行讨论，收集 15-20 人的反馈
  • PR 和法务会进行审查，审批流程较为轻松

一些已实施的改动包括：

  • 曾有一段时间，为了建立“工程品牌”，将深度技术文章列为最高优先级
  • 举办了“博客写作静修周”，用一周时间专注于撰写一篇文章
  • 将写作和演讲明确列为绩效评估和职业晋升中的奖励标准

尽管有法务和 PR 的审批，Calvin 指出：“总的来说，我们尽量保持流程的轻量化。我认为博客写作更大的问题在于缺乏文章，或者内容模糊、过于高深而缺乏趣味性，而不是泄露了太多信息。”

Cloudflare

  • 有人想写一篇文章
    • 内部博客是文化的一部分，有些文章来自内部博客
  • John Graham-Cumming（CTO）会阅读每一篇文章，其他人也会阅读并评论
    • John 是文章的审批人
  • Matthew Prince（CEO）也普遍支持博客写作
  • “非常快速”的法务审批流程，服务等级目标为 1 小时
    • 这个流程非常轻量，以至于有人并不认为这是一种审批，另一个人甚至完全没有提及这一步（第三个人确实提到了这一步）
    • 公关部门通常不参与

需要注意的是，这仅适用于技术博客文章。产品公告的流程更为严格，因为它们与销售材料、新闻稿等相关联。

我觉得有趣的一点是，Marek 是因为 Cloudflare 的博客而面试入职的（这篇 2013 年关于第四代服务器的博客文章吸引了他的注意），现在他不仅是公司的关键工程师，也是 Cloudflare 博客上引人入胜文章的主要来源之一。如今，Cloudflare 的博客已经至少吸引了几代求职者，他们因为看到一篇博客文章而前来面试，现在又为博客撰写精彩的文章。

反面示例 #1

  • 许多人建议我将这家公司作为正面例子，因为早期他们采用了类似上述的半轻量级流程
  • 唯一让流程不轻量化的因素是，一位创始人坚持要审批所有文章，并且经常大幅重写，但博客取得了成功，成为招聘的重要推动力
  • 随着公司规模扩大，创始人审批时间越来越长，导致博客流程出现长时间延误
  • 某个时候，公司聘请了一位外部人员接管博客发布流程，因为领导层认为这很重要
  • 之后，流程充满了典型的反模式，审批需要数月时间，工程师们对多次修改感到沮丧，这使他们的博客文章吸引力下降
    • 多人告诉我，他们发誓再也不会为公司写博客文章，因为流程太痛苦
    • 好消息是，尽管博客拥有合理流程的时代早已过去，但博客曾产出优质内容的记忆仍让许多外部人士对公司及其工程团队留下积极印象

反面例子 #2

  • 我的一位朋友试图发表一篇博客文章，结果花了六个月才获得“公关部门”批准
  • 大约一年后，由于“反面例子 #1”的声誉，“反面例子 #2”聘请了在“反面例子 #1”负责该流程的人，担任公关/传播部门的高级职位，并管理这家公司的博客流程。在“反面例子 #1”中，这个人接手时，博客已从工程师愿意撰写的内容，变成流程繁重到工程师发誓写完一篇后绝不再写
  • 聘请曾主导“反面例子 #1”博客衰落的人来改进“反面例子 #2”的流程，并未简化流程，也未带来更多或更好的产出

总体评论

我的观点是，一个企业工程博客的自然状态——人们获得一些反馈——会是一个相当有趣的博客。真正深入的技术写作非常匮乏，这使得任何半像样、诚实、公开的技术工作写作都显得有趣。

为了让博客变得无聊，公司必须主动阻止工程师发布有趣的内容。不幸的是，大型企业的自然状态似乎倾向于规避风险，并阻止人们写作，以防引发法律、公关或其他问题。个人贡献者可能认为，阻止工程师撰写低风险的技术文章是荒谬的，与此同时，C级高管和副总裁却经常发表公开言论，最终演变成公关灾难。但在大公司里，个人贡献者没有权力，或者觉得自己没有权力去做一件仅仅因为合理的事情。而需要签署批准简化流程的十四个利益相关者中，没有人关心简化流程，因为这对公司有好处，但对他们个人影响不大，更何况这似乎意味着要为简化流程带来的风险承担责任——无论风险有多小。一位愿意承担风险的高管或高级副总裁可以为后果负责，如果他们关心工程招聘或士气，他们可能会看到这样做的理由。

我经常听到来自更官僚公司的人说“我们这种规模的公司都这样”，但这并不正确。Cloudflare，一家市值60亿美元、接近1000名员工的公司，与许多其他拥有更繁琐博客流程的公司属于同一规模级别。公司工程博客的情况似乎与提供真实面试反馈的情况类似。interviewing.io声称，这样做的好处很大，而风险很小。有些公司确实提供真实反馈，而且这些公司通常发现，这让他们在招聘中轻松获得优势，风险很小。但绝大多数公司不这样做，这些公司的人会声称提供反馈是不可能的，因为你会被起诉，或者公司会被“取消”，尽管这通常不会发生在提供反馈的公司身上，甚至有些整个行业都普遍提供面试反馈。很容易模糊地指出存在某种风险，而很少有人有权驳回来自多个组织的关于风险的模糊说法。

虽然这只是一个小样本，从小样本中过度概括是危险的，但你需要高层支持才能突破官僚主义的想法，与我观察到的其他领域一致：大多数大公司在做一件容易但价值明显却分散的事情时都会遇到困难。虽然这篇文章恰好是关于博客的，但我听到过许多不同主题的类似故事。

附录：引人注目的博客文章示例

以下是一些来自上述博客的文章，并附有简短评论，说明为什么我认为这些文章引人注目。这次按sha512哈希值的逆序排列。

Cloudflare

Segment

Heap

值得注意的是，这些博客风格各异。就个人而言，我更喜欢 Cloudflare 博客的风格，其技术深度文章比例更高，但不同人偏好不同。实际上，多种风格都能取得成功。

感谢 Marek Majkowski、Kamal Marhubi、Calvin French-Owen、John Graham-Cunning、Michael Malis、Matthew Prince、Yuri Vishnevsky、Julia Evans、Wesley Aptekar-Cassels、Nathan Reed、Jake Seliger、一位匿名评论者，以及未具名公司的信息来源，感谢他们提供的评论、修正与讨论；致谢中明确提及的人员均非那些不够引人入胜的博客的信息来源。