在一个组里待久了可能会腻，如何在公司内部帮助合格的工程师找到新家，是Facebook需要积极面对的问题。为此，公司设计了Hack-A-Month计划来帮助工程师成功换组，重新点燃工作激情。
如果一位工程师在某个组待久了，工作上的挑战日渐减少，自然而然会失去新鲜感，失去学习新东西的机会和动力，这时换一个组可能是最好的选择。
在很多公司里，这么做可能并不现实。
从一般人的角度而言，没有了挑战，工作反而轻松了，没有对成功与否的担忧，也就没有很多压力，这不是好事吗？但对于自我要求很高的牛人而言，失去了挑战，工作就只是一份工作，少了成长的空间，缺乏激情，久而久之，甚至会考虑离开这家公司。等到一个牛人已经慎重考虑、准备离职之时，公司再想挽留的话，精力和物质成本都会高很多，尤其当他已经找到下家时。既然这样，为什么不在他刚刚感觉失去激情的时刻，就早早在公司内部帮他找到合适的下家呢？
对很多团队而言，让一个新人加入，要花费时间、精力帮他适应，劳心劳神，还不一定会成功。的确，这样的风险确实存在，但对于整个公司而言，这样的流动有利于重新激发牛人的战斗精神，而且不同业务背景的牛人可能在新组中带来全新的思路，产生出意想不到的火花，说不定能给一个组带来颠覆性的新思路。正是这种开放的精神，促使Facebook开始了Hack-A-Month计划。
所谓Hack-A-Month，就是允许工程师参与到另外一个组的项目之中，为此连续工作一个月。这一个月里，除了每周例行的和自己老板的一对一碰头会，原则上不需要对自己组里的任何事情操心，就好像已是另外一个组的成员，只是人事关系没有转过去。一个月之后，这位工程师和工作一个月的这个组的组长会进行一次双向反馈，如果都满意对方，那么该工程师就可以正式换组。整个过程中，两个组的领导都积极支持该工程师的个人兴趣和意愿。
但为了Hack-A-Month计划能行之有效，需要设立一些规则。
1.必须在当前岗位待了一年以上。不到一年的，你不能说自己对组里的项目都非常了解，Facebook不希望任何员工在某个岗位上浅尝辄止。
2.必须证明他是一名优秀的工程师。Hack-A-Month不能成为表现差的员工的“免死金牌”。你只有通过在当前岗位上的突出表现，证明自己至少是合格的工程师，才能参加Hack-A-Month。
3.研发经理应该积极去发现可以参加Hack-A-Month计划的工程师。这在其他公司里或许不可想象，因为意味着负责人主动思考要将一位靠谱的员工送到其他组去！很多人会觉得这很疯狂，但Facebook的确是这么做的。某位工程师在一个组待了一年或者更久的时间，经理会在一对一碰头会上讨论目前正在进行的项目对他的吸引力及学习空间。另外，经理也会根据其表现上的变化，来判断是不是该主动地提出让他换组。
4.如果是员工自己提出的，研发经理要积极配合。如果员工还没有找到合适的目标组去进行Hack-A-Month，研发经理要帮他寻找。如果找到了，研发经理要帮助安排交接当前的工作，以保证那一个月之中不被自己组里的事情干扰。
5.在这一个月中，员工可以坐到目标组的区域中去工作，让他对目标组的整个运作有一个切身体会。
6.员工要和目标组讨论出一个可以在一个月内完成的项目。可以是单独的项目，也可以是与人合作的项目。但在Hack-A-Month末期要有成果拿出来，以帮助组员和对方组互相判断这一个月的实际效果。
7.如果员工决定转组，目标组也欢迎，那就成了。
8.如果转组不成功，员工就回归原组，继续原先的岗位，在将来适当的时候根据兴趣决定要不要再进行一次Hack-A-Month。通常两次Hack-A-Month要间隔超过半年以上。
在我们组里，曾经有一位编程高手，他处于兴奋状态时一天可以写出上千行代码，而且质量非常高，所以他是毋庸置疑的优秀工程师。待了一年多之后，我发现他做事的速度明显下降。在一次一对一面谈之中，我们谈到了这个问题，他也承认，由于我们组把最有挑战性的支付欺诈率给降了下来，他觉得其他的挑战对自己没有很大的吸引力。在讨论了组内换项目的各种方案之后，我决定鼓励他参加Hack-A-Month计划。为此，我和好几个可能适合他的目标组的经理聊了几次，也让他去找这几个组聊，最后他在广告前台组找到了Hack-A-Month的项目，并在之后转到了该组。后来我了解到，他在那儿的表现很不错。
把Hack-A-Month计划运行好并不是一件非常容易的事。这要求参与该计划的三方（员工、原组、目标组）都能理解局部利益和全局利益、短期利益和长期利益的关系。毕竟，对原先组而言，这是暂时的损失，但对整个公司而言，这样做可以帮助优秀人才长期保持较高的激情和工作效率。
