你好，我是葛俊。今天，我来和你继续聊 Facebook 的工程师文化及相关管理实践。

在上一篇文章中，我与你详细介绍了 Facebook 工程师文化的核心：黑客之道，并给出了一些落地实践。从这些实践中，我们可以体会到，这种工程师文化推行得非常成功，已经融入了 Facebook 的血液中。

也正因为如此，Facebook 的工程师文化大大激发了员工的创造性、生产力和凝聚力，对整体的研发高效能和良好的个人成长环境起到了关键作用。

与工程实践等方法论一样，知道好的实践还远远不够，我们更需要弄清楚的是，这些实践背后的原则，才能把它应用到自己的公司和团队。

所以，在接下来的三篇文章中，我会与你系统分析 Facebook 是如何真正落地工程师文化的。同时，我会结合我在其他公司、团队推行工程师文化的实战经验，与你分析落地工程师文化的切入点，以及需要注意的问题。

我希望这样的讲述思路，能够帮你更深入地理解这些实践和原则，将工程师文化更顺畅地引入自己的团队，提高研发效能。

Facebook 工程师文化落地的三大支柱

在讨论 Facebook 工程师文化实践落地的 how 之前，我们先看看 why 吧。

我们首先需要明确的是：归根结底，推行工程师文化的目的是，提高开发人员的积极性和创造性，从而更高效地进行软件生产，在竞争中取胜。而要最大化地激发开发人员的自我驱动能力，根本出发点是，开发者这个群体的特性。

每一名开发者首先都是知识工作者。管理学大师彼得 · 德鲁克（Peter Drucker）在《卓有成效的管理者》中说：“我们无法对知识工作者进行严密和细致的督导，我们只能协助他们。知识工作者本人必须自己管理自己，自觉地完成任务，自觉地做出贡献，自觉地追求工作效益。”从这个角度来看，每一个知识工作者，都是管理者。

也就是说，要提高开发者的效率，强管理不是办法，根本之道在于激发他们的内驱力。正因为如此，有效激励员工的积极性，正是硅谷高效能公司文化的共同点。

那，怎样才能有效激发开发者的积极性呢？在我看来，Facebook 主要关注以下三个原则：

  1. 让员工做感兴趣的事；
  2. 让员工拥有信息和权限；
  3. 用绩效调节员工和公司方向的一致性。

员工能做自己喜欢的事儿，并有施展拳脚的空间，自然能最大限度地激发积极性；再加上绩效的调节，能够让团队成员的积极性与公司利益更有效的对齐，从而最大化员工积极性带来的成果。

所以说，这三点就是 Facebook 工程师文化落地的三大支柱。

接下来，我们就先看看第一个支柱，让员工做感兴趣的事儿的一些具体实践吧。

让员工做感兴趣的事

我首先要说明的是，这里的感兴趣，不只是狭义地觉得任务有意思，而是开发者对工作的整体状况感兴趣，包括项目前景、技术栈、挑战性、团队成员等。

有研究证明，如果任务有意思、有挑战，同时又是加以努力就能完成的，员工的 engagement 和满意度就会非常高。那么，让团队成员灵活地选择岗位和转岗，就成了一个绕不开的话题。

但，团队成员灵活选择岗位和转岗，在短期内会直接给公司，尤其是小团队带来负面影响。另外，如果公司比较小的话，每个人都很关键，自由转岗更难实现。

接下来，我们就通过几个实践，看看 Facebook 是如何用好这把双刃剑的吧。Facebook 让员工做感兴趣的事，包括了入职、日常工作和转岗这 3 个场景。

其实，这 3 个实践，也并不是在 Facebook 成立之初就都有的，而是在不同的发展时期引入的。

第一个场景：入职时

在 Facebook，新员工入职时都要参加 Bootcamp，一方面可以帮助员工熟悉公司产品、研发流程和工具，另一方面可以帮助员工灵活选择岗位。

Bootcamp 的具体操作是：几乎所有的工程师在入职时，都没有明确会到哪一个团队工作。进入公司的前六周，新员工会先到一个特殊的区域办公，并从任务池中挑选任务工作。

这个任务池中的任务，是公司各个产品团队放进来的，一般是难度不太大、优先级不太高，但又能让新员工快速了解业务的任务。新员工通过完成任务来了解产品和流程，并通过沟通了解这个产品团队的成员。

在 Bootcamp 结束时，新员工和感兴趣的团队主管沟通，决定最后加入哪个团队，是一个双向选择的过程。不过，因为公司业务一直在扩张，很多团队都缺人，而且这些新员工的素质普遍不错，所以一般都是卖方市场，绝大部分新员工都能进入自己感兴趣的团队。

让新员工选择并进入自己感兴趣的团队，可以极大提高其积极性，还可以在员工间建立关系网，提高凝聚力，长期收益非常可观。但，这个实践的弊端是，有些团队可能一直招不到合适的成员，在短期内影响产品进度。

所以说，这个实践比较适合有一定规模并发展较快的公司，因为新员工多容易调节些。Facebook 也是在 2008 年员工数接近 1000 时，才开始实施的。如果你的公司也具备这些特点，可以考虑尝试 Bootcamp。

如果你想了解 Bootcamp 更多细节的话，可以参考这篇文章。

第二个场景：日常工作

在日常工作中，提高员工工作兴趣的一个实践是 Hackathon。

Hackathon 有一个有趣的原则是，鼓励大家尽量不要做与日常工作直接相关的项目，而是做一些感兴趣的项目。所以，我们在做 Hackathon 的时候，都是把它当作一个好玩的事儿，而不是当成任务来完成。

Hackathon 在开始的时候，还有一些好玩儿的仪式。组织者和参与者会敲锣打鼓，在公司里做一个游行，才正式宣布 Hackathon 开始。另外，Hackathon 一般会在公司的餐厅进行。餐厅会被摆放些桌椅、提供些小零食，被整理得很舒适，适合三四个人的小团队讨论问题。

值得一提的是，Hackathon 并不会明确要求做出可落地的产品，但有趣的是，大家感兴趣的项目往往会和工作相关，所以实际上产生了很多很有价值的项目。在上一篇文章中，我也提到了，Facebook 最成功的产品中有些就是来自 Hackathon，除了时间线（Timeline）、聊天、视频、点赞按钮外，更典型的是 Image Tagging 和 the Like Button(大拇指)。

总结来说，Hackathon 没有强制的业务目标，做不出东西也没关系，所以大家都很放松，抱着创造一个新东西的心情去做事，很爽。

在落地实践方面，Hackathon 不涉及转岗，所以比较容易实施。也正因为如此，国内不少公司都尝试过这条实践，也取得了不少成果。但需要注意的是，在实施时要注意些细节，否则会事倍功半。

第三个场景：转岗

在转岗上，Facebook 采用的是 Hackamonth，即离开当前工作岗位，去另一个团队全职工作一个月。每个员工在一个团队工作满一年后，都可以参加这个活动。

跟 Bootcamp 类似，Hackamonth 也有一个任务池。每个团队都会把一些一个月左右即可完成的、独立的项目，放入这个任务池里。有兴趣参加 Hackamonth 的员工，在这个池子中寻找感兴趣的任务，并跟新团队负责人确认之后，就可以和自己的主管提出参加 Hackamonth 的要求。

接下来，你需要和主管沟通做好安排，以确保这一个月，原工作岗位上的任务有人处理。安排妥当后，你就可以进入新团队，并直接到他们的办公区工作了。

Hackamonth 结束后，你可以决定加入新团队还是留在原来的团队，当然前提是你想加入的团队愿意接收你。这实际上是一个通过做项目的方式来让员工和他感兴趣的团队互相了解并双向选择的过程。

另外，Hackamonth 还提供了更进一步的灵活性。在做 Hackamonth 的时候，如果你觉得这个团队不是很满意，你也可以私下接触其他团队。如果双方觉得合适的话，等 Hackamonth 结束后，你可以选择加入这个团队。

Hackamonth 对提高开发人员的工作兴趣，有两大好处：

  1. 一是，开发人员可以比较自由地转岗，而且大概率能够找到感兴趣的项目；
  2. 二是，即使最终没有转岗，也可以通过这一个月的工作转变，减少 Burnout 的感觉。

我有一个同事在 Facebook 呆了五年，参加了三次 Hackamonth，但每次都回到原来的组。用他的话说就是，去度一个月的假。是不是很有意思呢？

但采用 Hackamonth 的弊端是，会直接影响原团队的工作进度，更容易对公司和团队造成短期伤害。与 Bootcamp 相比，Hackamonth 更不适合小公司。Facebook 是在 2011 年员工数达到几千时，才开始采用 Hackamonth 政策的。

在 Facebook，只要你在一个团队工作满一年了，即使团队主管不情愿，也没有权利阻止你去参加 Hackamonth。可见，Facebook 在执行 Hackamonth 政策上，再次果断选择了长期利益。

以上就是 Facebook 为达成让员工做感兴趣的事这个目标，在入职时、日常工作和转岗这三个场景下的 3 个重要实践。

接下来，我再和你分享些我在国内一家公司落地 Hackthon 的具体经验吧。

Hackathon 落地经验

当时，我所在团队的执行力非常强，但员工的自我驱动不够。考虑到对公司和团队的影响，我权衡之后决定引入 Hackathon。

在引入 Hackathon 时，我采用了和 Facebook 类似的方式：举行时间为周五和周六，下周一下午在团队内部进行演示和评选。

这样一来，只会占用一天多一点的工作时间，大家还可以选择周日继续进行。通常情况下，大家虽不会通宵，但也会做到比较晚，并且周日还会持续。

在这之前，公司其他团队也尝试过 Hackathon，但效果都不太好。所以，这次的 Hackathon，我制定了两大规则：

  1. 明确要求，Hackathon 的目的是 Have Fun，不追求产品落地，尽量不做与工作直接相关的任务。
  2. 评选结果时，由团队成员投票决定优胜者，而不是由专家或者管理层评选。

对这两个原则，我的主管和人事部门是有些怀疑的，但在我的坚持下还是执行了下来。

这次 Hackathon 下来，效果出奇得好：

  1. 大家热情高涨，80 人左右的开发团队基本可以产生 12 个项目；
  2. 虽然没有要求项目落地，但还是产生了很多有意思、有价值、可落地的项目。

比如，一次 Hackathon 时，3 个同事做了一个卫生间管理系统：登录网页即可查看办公楼的卫生间占用情况。这个项目，既解决了大家的痛点，又很有意思，所以高票当选第 1 名。

再比如，一次 Hackathon 时，几个运维同事做了一个 ChatOps 的项目。他们开发了一个聊天机器人放到聊天室中，在产品发布上线时，实时、自动发布部署进展，开发人员还可以直接询问聊天机器人当前的部署状态。这个项目，很大程度上解决了部署上线时团队的沟通不畅问题，所以成功落地到实际工作中。

这种形式的 Hackathon，在结束后仍对团队有正向影响：一是，团队氛围更活跃、成员间衔接更紧密了；二是，大家对技术更感兴趣，也更愿意讨论用技术实现各种项目的可能性了。

总结来讲，几乎所有包含开发人员的团队都可以尝试 Hackathon，但为了保证效果，需要注意些细节，尤其是上面我提到的两个规则。

小结

今天，我首先和你介绍了 Facebook 工程师文化落地的三大支柱：让员工做感兴趣的事、让员工拥有信息和权限，以及用绩效调节员工和公司方向的一致性。

然后，在让员工做感兴趣的事方面，我从入职、日常工作和转岗三个场景，和你分享了 Facebook 的 Bootcamp、Hackathon、Hackamonth 这三个实践。这些实践，都对提高员工内驱力有非常关键的作用。

在这三个实践中，Bootcamp 和 Hackamonth 比较适合规模较大（千人左右或者以上）且发展较快的公司。如果你的公司符合这样的特点，可以考虑落地这两个实践，并根据实际情况做一些调整。比如，引入 Bootcamp 后，如果有一些冷门团队新员工都不愿意去，怎么办呢？一个可能的办法是，对这些职位进行定向招聘，专门寻找感兴趣的员工。

而如果你的公司不具备这些特点的话，可以尝试 Hackathon 这个轻量级的实践。Hackathon 花费的时间不多，但执行合适的话，效果会非常好。

除此之外，作为技术管理者，我的建议是，在安排日常工作时可以多考虑团队成员的意向，尽量在条件允许的情况下，提高员工兴趣和任务的吻合度。

思考题

在你的公司或者团队，有什么措施让员工尽量做自己感兴趣的事吗？

感谢你的收听，欢迎你在评论区给我留言分享你的观点，也欢迎你把这篇文章分享给更多的朋友一起阅读。我们下期再见！