打造高效能技术组织的逆向法则

From：https://avivbenyosef.com/unpopular-defaults-for-high-performing-tech-organizations/

“从来没有人离职！” “看看我们的黑客松！” “我们硬性规定时间来解决技术债。” 表面上看，这些都是好事。但实际上呢？这些建议……只适合那些想带领平庸团队的人。

作为技术领导者，你时常会想遵循那套“通用剧本”。但如果正是这本剧本阻碍了你组织的发展呢？这里有六个非传统的预设法则，它们虽然不受欢迎，却能帮助你建立有韧性、有创意且真正有影响力的团队。

杜绝纳米团队 (No Nano Teams)

当你创建一个由一位经理和一到两名成员组成的团队时，你其实只是在增加管理成本，却没有带来实质的影响力。这些纳米团队很少能自给自足，而且往往寿命很短（或不必要地长寿）。为了安抚人们的自尊心，你最终只能在一个支离破碎的组织中疲于分配工作。

我经常看到一些组织的管理成本高达100%。毫不夸张地说，我们可以裁掉一半的经理，才能达到合理的团队规模（并减少组织层级）。这不是在扩展；这是在放纵低效率。只有当没有团队的痛苦变得无法忍受时，才应该创建团队。一个团队需要足够的关键成员以实现自主运作，而不是一个仅具备基本人力、美其名曰的项目小组。

告别黑客松 (No Hackathons)

黑客松是肾上腺素飙升的混乱场面，非常适合吃比萨和团队建立感情，但很少能带来长期的创新。最终你只会得到一堆半生不熟的项目，在活动结束的那一刻就宣告死亡。如果你对创新是认真的，那就放弃黑客松，改为采纳“间歇期”（intermissions）。

“间歇期”是一种结构化的工作暂停，让团队有时间去推动有意义的项目。与黑客松不同，“间歇期”的目的不是证明你能在36小时内做出点什么，而是要创造持久的影响力。无论是提升工程效率、实验新产品概念，还是解决棘手的运营问题，“间歇期”都专注于品质而非速度，并确保工作成果不会消失在一个被遗忘的代码分支中。想了解更多相关内容，可以在此处获取我书中专门讨论这些的免费章节。

不设硬性的“工程时间” (No Hard-Set “Engineering Time”)

技术领导者太常挥舞“技术债”这张牌，来为非结构化的工程时间辩护。虽然初衷是好的，但执行上通常有缺陷。我们视为“技术债”的大部分东西，其实并不是。

反之，你待办清单上的任何事项都应该像其他任务一样对待：让它变得可见，量化其影响，并与产品部门合作，权衡它与新功能之间的投资回报率（ROI）。当技术债被视为路线图的一部分时，它会强迫团队遵守纪律，并确保大家对真正重要的事情达成共识。

别过度呵护工程师的时间 (Don’t Coddle Engineers’ Time Too Much)

工程组织中的一些人觉得开发者的时间非常宝贵，必须不惜一切代价保护——手指必须尽可能地敲键盘。他们期望产品部门提供完美的规格文件，并让工程师远离客户和技术支持工单的混乱现实。这正是导致脱节的根源。

你的工程师应该花时间去了解他们工作背后的更广泛背景。鼓励他们每季去观摩（shadow）客户成功或技术支持团队的工作。更好的做法是，让他们不时地轮换到这些岗位上一天。不要让他们事事寻求产品部门的“签核”，而要期望他们进行协作和迭代式的工作。目标不是给他们增加负担，而是让他们接触到自己工作所带来的真实世界影响。理解客户痛点和业务优先级的工程师能做出更好的决策——而不是困在象牙塔里。

追求健康的流动率 (Aim for Healthy Turnover)

你的团队从来没有人离开？这不是荣誉勋章——而是一个危险信号。这意味着没有人受到足够的挑战来超越自己当前的角色。同样地，如果从来没有人被解雇，那么你要么是在招聘上过于谨慎，要么是在回避那些能推动真正成长的艰难对话。

健康的流动率是一个充满活力的组织的标志。它意味着人们在成长。它也意味着你愿意承认某人不再适合，并为新的人才腾出空间。要把流动率视为进步的副产品，而不是一个需要解决的问题。

打破过度专业化分工 (Break Over-Specialization)

把人们最擅长的任务交给他们，可能感觉像是一个提高生产力的技巧，但这会创造出脆弱的团队。当一个人成为特定领域的首选专家时，你就是在为自己埋下瓶颈与停滞的隐患。

鼓励工程师去承担他们舒适圈之外的任务。更好的做法是，每12到24个月创造内部轮调的机会。团队内的跨领域交流能培养韧性、防止孤岛效应，并保持员工的参与感。这不是要把人直接扔进深水区；而是要建立一种学习和适应的文化。

这些准则或许不会为你赢得人气竞赛，但它们将创建一个更强大、更具创新力、且更符合其使命的组织。如果你的目标是打造真正伟大的东西，那么是时候停止墨守成规，开始书写你自己的规则了。