如何长期运营一个企业的技术团队博客？

导语

对比运营技术团队博客的人所写的内容时，可以发现，与一家估值在亿级级别的公司相比，个人博客比技术团队博客有更多阅读量，而且这种情况相当普遍。此外，在个人博客频道里，拥有数量级流量的博文也并不少见。

这很奇怪，因为企业技术团队通常拥有数百至数千名员工，与拥有个人博客的人群相比，他们应该拥有比个人更有能力撰写优质博客的员工；企业员工做过更多技术工作，同时拥有更深入的知识量和更多有趣的故事。而拥有优质博客内容的技术团队博客，应该会获得比个人博客多得多的阅读量。

目录

• 技术团队博客为什么重要？
• 技术团队博客为什么不好做？
• 技术团队博客的优秀样例有哪些？

---

 

技术团队博客为什么重要？

企业拥有技术团队博客，意味着他们将拥有技术影响力。Cloudflare和Segment等众多企业通常都很乐意公开谈论其撰写博客的过程，从而向全世界传播他们的产品。

此外，拥有个人博客可以帮助其找到更多的工作机会，而博客对于企业招聘也会有帮助。对个人而言，只需要一份工作，所以更多的博客曝光充其量能使其找到更好的工作而已；而对于公司而言，由于所有公司都在拼命地招聘，公司在招聘时会存在直接竞争，如果另一家公司相对更有价值，对候选人来说会更具吸引力。

Cloudflare和Segment拥有自己的技术团队博客，复制他们的套路会是一个巨大的招聘优势。面试时，应聘者们其实并没有处于竞争状态；即使他们面试相同的岗位，但如果公司喜欢他们中的多个候选人，通常也会提供更多的工作岗位。对应聘者来说，求职类博客重要的是，在求职过程中是否可以收到有效的非面试反馈，或者说如果在常规面试中失败，那么由此可知，其他额外职位的边缘价值可能会很低。

 

技术团队博客为什么不好做？

博客内容不合理

拥有好的技术团队博客有显而易见的好处，但大多数技术团队博客中充斥着技术人不想阅读的内容，比如描述事情如何奇妙但含糊不清的高层虚假信息、营销内容以及追逐热点的帖子。

博客审批制不合理

此外，通过对Cloudflare、Heap和Segment这三个公司的采访，对这些运营技术团队博客的公司了解得更加深入，并明确了他们的共同点。

引人注目的技术团队博客具有以下审批流程：

1. 简单的审批流程，不需要很多审批
2. 很少甚至不需要非工程的审批
3. 隐式或显式快速SLO（服务级别目标）审批
4. 审批/编辑的主要目的是为了使博客对工程师更具吸引力
5. 高层直接支持（联合创始人、C级或VP级），可保持博客流程的轻量级

不太引人注目的技术团队博客具有以下审批流程：

• 审批流程缓慢
• 需要许多审批
• 非工程审批是必要流程
  • 非工程审批结果的变更令作者感到沮丧
  • 审批过程来回持续数月
• 审批过程的主要目的是为了降低博客风险，通过删除对特定内容的引用，使信息变得模糊，但同时也使博客变得不那么令人感兴趣
• 博客没有有效的高层支持
  • 领导层可能会认同博客是良好的方式，但是采取实际行动的优先级还不够高
  • 为了使写博客变得容易而进行的改革，实现起来非常困难，先前进行的尝试都以失败告终
  • 要想更改流程以减少成本，需要所有的利益相关者签署文件（一种情况下为14个）
    • 任何一个利益相关者都可以阻止
    • 没有单独的利益相关者可以审批
  • 对于可减少成本的审批，利益相关者都保持警惕
    • 对利益相关者而言，审批所要承担的相关风险（如果最坏的事情发生）并不能给他们可预期的收益

一个在拥有优秀企业博客公司中的受访者指出，仅拥有一个审批人或一个主要审批人的不利之处在于，如果这个人很忙，则可能需要数周才能获得审批。这是获得统一审批的弊端。

同可借鉴的某家公司的流程进行比较，可以发现，他们的审批通常需要三到六个月的时间，有的甚至可能需要一年时间来进行审批。对于以前在高速发展公司工作的人来说，数周时间似乎很长，而那些在发展缓慢公司工作的人会欣喜若狂，认为其审批过程只需要两倍的时间。

 

技术团队博客的优秀样例有哪些？

Heap

• 有想写帖子的人
• 技术作者与负责审批帖子的编辑配合
  • 编辑需为具有写作经验的技术人
  • 过程可能需要几轮，但可能会改变帖子的推荐权重
• 首席技术官阅读并审批
  • 通常只有很少的反馈
  • 可能会提出类似“一个设计师可以使此图看起来更好”的建议
• 发布帖子

在编辑阶段，Heap以前是将初稿发布到一个开放的频道，所有人都会在该频道中发表评论，需要大量的修订。这是一个不太令人愉快的方式。

Heap的审批流程旨在避免有“太多”反馈。

 

Segment

• 有想写帖子的人
  • 帖子内容通常来自于内部文档，外部讨论、交付的项目，开源工具（由Segment构建）
• 由技术人作者撰写初稿
  • 可能会有一位高级技术工程师与他们一起撰写初稿
• 直到最近，还没有真正给出反馈的流程
  • 通常，Calvin French-Owen（联合创始人）和Rick（技术经理）会提供最多的反馈
  • 也许还会得到经理和技术领导层的反馈
  • 通常第三稿被认为是终稿
  • 现在拥有全职编辑
• 还可以与技术团队进行社交活动，可以获得15到20个人的反馈
• 公关和法律部门将会审阅，但属于轻量级的审批

已进行的一些更改包括：

• 一方面，在试图建立技术团队博客时，将深层次的技术文章作为头等大事
• 设立“博客静修会”，花一个星期去写一篇文章
• 增加了写作和口语的明确标准，可从绩效考核和职业升级中获得奖励

尽管已获得法律和PR的批准，但Calvin指出：“总的来说，我们试图使它保持相对的轻量级。我认为，博客更大的问题是缺乏帖子，或者充斥着含糊的、高层次但并不有趣的内容。

 

Cloudflare

• 有想写帖子的人
  • 其中一些帖子来自于内部发布的博客
• John Graham-Cumming（CTO）会阅读每篇文章，其他人阅读并发表评论
  • 由John审批博客
• Matthew Prince（首席执行官）通常也审阅博客
• “非常快速”的法律审批流程，SLO为1小时
  • 审批流程是非常轻量级的，以至于没有人将其视为审批，也根本没有人提及它，但审批步骤的确被提到了

需要注意的是，这仅适用于技术博客文章。产品公告的过程较繁重，因为它们与销售内容、新闻稿等相关。

Marek因在Cloudflare看到的一篇博客（2013年有关第四代服务器的文章），接受了Cloudflare的采访。现在他既是他们的核心技术人，也是Cloudflare博客帖子的主要发布来源之一。在这一情况下，Cloudflare博客至少吸引了几代访问用户；用户在看到一篇文章后访问博客，进而在该博客撰写更多引人注目的帖子。

 

优秀的博客文章

以下是一些优秀的博客文章样例，并简要指出了该博客具有吸引力之处。

（博客排序以相反的sha512哈希顺序）

Cloudflare

• https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/
  • 文中谈论了涉及到很多人的实际技术问题且问题深度合理；
  • 文章在停电后仅8个小时就及时发布了，那时人们仍然对听到发生的事情非常感兴趣。大多数公司无法快速处理好的博客文章，或者只能在特殊情况下处理，而Cloudflare能够半定期地发布实时文章。
• https://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/
  • 关于一些数据的探索。
• https://blog.cloudflare.com/the-story-of-one-latency-spike/
  • 关于调试的故事。
• https://blog.cloudflare.com/when-bloom-filters-dont-bloom/
  • 关于调试的故事，以数据结构的开发为背景。

 

Segment

• https://segment.com/blog/when-aws-autoscale-doesn-t/
  • 关于广泛使用的服务中，陷阱的具体说明。
• https://segment.com/blog/gotchas-from-two-years-of-node/
  • 关于广泛使用的工具中，陷阱的具体示例和说明
• https://segment.com/blog/automating-our-infrastructure/
  • 展示了公司运作方式的具体细节；从理论上讲，任何公司都可以写这方面的内容，但是很少有公司会去做。

 

Heap

• https://heap.io/blog/engineering/basic-performance-analysis-saved-us-millions
  • 文中谈论了一个真正的问题和解决方案。
• https://heap.io/blog/engineering/clocksource-aws-ec2-vdso
  • 文中谈论一个真正的问题和解决方案；
  • 在HN评论中，工程师（malisper，kalmar）对问题的实际原因用技术做出响应，而不仅仅是大多数情况下常见的掩饰行为。
• https://heap.io/blog/analysis/migrating-to-typescript
  • 关于公司第一次推动的技术变革，文中真实谈论了其尝试以及失败过程。

 

公众观点

• 企业博客应该非常有趣，人们可以从中获得一些真实深入的反馈，这会使技术方面的写作变得有趣。要想拥有一个有趣的博客，公司必须让工程师积极发布有趣的内容。然而，大公司更倾向于规避写作风险，以防引起法律或公关等其他问题。
• 个人贡献者（ICs）可能认为，阻止技术人 撰写低风险的技术博客是荒谬的，同时C级高管和VP经常公开发表评论，会引发PR灾难；但是大公司的个人贡献者却无权或者认为自己无权做这样的事，仅仅因为这是有道理的。并且考虑到要简化流程，在所有利益相关者中，不会有一个必须签署审批文件的人。这样不会对公司真正产生影响，而且不需要对简化流程可能带来的风险承担责任，尽管其风险很小。执行人员或者高级VP乐意承担风险，可以为后果负责；若他们对工程招聘或团队士气感兴趣，他们可能会这样做。
• 经常听到官僚主义公司的人说，“我们这样规模的公司都是这样”，但事实并非如此。Cloudflare是一家市值600亿美元的公司，拥有近1000名员工，与许多拥有同等规模的其他公司相比，其博客流程更为繁重，但其企业博客看起来是在提供真实的面试反馈。有些公司的确提供了真实的面试反馈，并普遍认为，这不仅给了他们招聘优势，而且几乎没有什么其他方面的弊端。但大部分公司不这样做，他们表示提供面试反馈是不可能的，这将会被起诉或者公司将被取缔。然而，提供面试反馈的公司通常不会发生这种情况，甚至在整个行业中也普遍提供面试反馈。当风险来自多个组织时，人们很容易对存在的风险视而不见，很少有人有权力对这种模糊的风险视而不见。
• 虽然样本很小并且从小样本中过度概括是很危险的，但突破官僚主义需要高层支持的现象，与在其他领域所看到的是一致的；大多数大型公司都很难做到价值显著但分散的事情，即使这些事很容易。

 

参考链接：https://danluu.com/corp-eng-blogs/?utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website

标签：Cloudflare,技术,博客,https,运营,审批,团队
来源： https://blog.csdn.net/csdnassistant/article/details/113615342