一些经理常犯的一个错误是，把管理的责任推给被管理的人。我们中任何曾经当过经理的人都会回过头来看到，我们曾试图把一些事情推给被管理的人，因为这对我们来说更容易，但后来意识到这并不是最好的解决办法。如果员工们使用的一个通用频道来分享知识，这不是一个错误，而是一个优点。如果作为经理，你希望有一种更结构化的方式来传达在这些频道中产生的机构知识，那么就由你来建立这种结构。试图把这种责任往下推，通常会导致这种机构知识通过口头交流或私人电子邮件/私信来分享，以避免记录文档的负担，这实际上是一个负面结果。这种信息对团队来说是一种增效器，也是对新员工入职的宝贵资产。这两者都是经理和公司直接的益处，所以要利用这种自发的文档记录，而不是坚持把认知负担传递下去。
源讨论如果你是远程办公，就随意聊聊原帖 464 条评论 · 导入时统计我理解你所表达的观点，但从经理的角度来看，这种格式是我们一直试图避免的。有一个地方让人们提问是很好的，也是被鼓励的，但任何开始将知识集中到某个人而不是某个主题上的做法都会带来可发现性、可搜索性的问题，并且可能给新员工造成一种印象，即某些特定的人是他们恰好了解很多的项目的中心人物。 因此，虽然问答格式是好的，但我不鼓励围绕某个人创建单独的渠道。我鼓励每个人直接去相应的主题频道讨论。 当有人在 #random 或 #general 中开始提出具体技术问题时，我也会这样做：引导他们到项目特定的频道。那是所有相关人士都会出现的地方。…
完整原文把你的经验，加入这段讨论。
> 如果你作为经理，想要一种更结构化的方式来传达在这些渠道中产生的机构知识，那么这就取决于你去整理了。 这不正是GP所描述的吗？
完整原文在我看来，入职过程中最大的助力是自动化... 开发人员需要经过多少个用户交互步骤才能开始工作？ 我经常将这个过程简化到一个目录和一个需要运行3-4次的主要脚本... 主要是因为需要重新启动，例如在WSL设置之后，还有Docker Desktop中的一些选项需要设置。我也用mac/homebrew做过类似的事情。 从那里，你可以使用docker-compose和shell脚本来针对项目运行... 这些脚本和compose文件是进入项目的入口，实际上也记录了事物的位置以及它们如何连接（在一定程度上）。 有效地尽早地让一个可行的解决方案运行起来。这只是我的个人意见，但为入职自动化开发环境，尤其是如果你是一个大型组织，是一个很好的战术决策。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。