我完全同意这两点。随之而来的一个主要挑战是，需要协调众多拥有相互冲突利益的人员，以免搞砸自己的职业生涯：
- 得罪你的上司，预算和申请就会变得棘手
- 得罪你的用户，数据就会下滑，投诉会上报到你的上司那里，于是你又得罪了上司，导致预算和申请变得棘手
- 得罪你上司的同事，结果你会陷入与那些自认为懂行却要求你做毫无意义之事的人的会议中。如果你的上司懂社区运营，这还不太糟。如果你的上司不懂社区，那你为了向这些人普及知识，就会练就一身制作 PowerPoint 的绝活
- 得罪你上司的上司……好吧，你懂的
那么，谁最适合在企业层面主导社区工作？
在我看来：对外社区应由客户服务部门负责，对内社区应由在业务中发挥某种支持作用的团队负责，例如 DevOps、IT 或学习与知识管理团队。如果你的社区既对外又对内，我会设立一个专门的社区部门，该部门基本上由来自客户服务、产品等各部门的代表组成。这样可以兼得两者之长：由社区负责人提供自主领导，并由各部门代表组成的“大熔炉”提供跨职能治理。
你可能已经注意到，我从名单中省略了最常见的社区所有者——市场部门。我个人不喜欢由市场部门主导的社区。我只是觉得那些社区不符合我的最佳利益。我的意思是，它们怎么可能符合呢？市场部的目标是寻找/吸引可能购买产品的人，这通常意味着“即使该产品并非对该人最佳的选择，也要说服他们购买”。并非总是如此，但这种情况足够频繁，让我带着先入为主的怀疑态度看待他们。
另一方面，我非常喜欢将社区视为客户支持的一部分：这里是由那些以改善我作为用户/客户的体验为存在理由的人所主导的地方。如果社区是面向外部的，我会将其交给客户支持部门——并要求他们与产品团队建立非常良好且紧密的关系。