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

导语

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

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

目录

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

 

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

企业拥有技术团队博客,意味着他们将拥有技术影响力。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

 

Segment

 

Heap

 

公众观点

  • 企业博客应该非常有趣,人们可以从中获得一些真实深入的反馈,这会使技术方面的写作变得有趣。要想拥有一个有趣的博客,公司必须让工程师积极发布有趣的内容。然而,大公司更倾向于规避写作风险,以防引起法律或公关等其他问题。
  • 个人贡献者(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

上一篇:ContOS Docker 开启 2375 端口


下一篇:docker-maven-plugin详细使用方法