我是一位经验丰富的 C# 开发人员（大约 5 年经验），最近被任命为我的第一个开发团队的技术主管（在 3-5 名其他开发人员之间变化）。在担任这个职位的过去 4 个月里，不断出现的一个难题是试图找到适当程度的共享意识，以了解项目经理、客户经理、客户、设计师、CEO 和我自己之间进行的沟通（尤其是通过电子邮件） .
一方面，我知道每个开发人员对项目总体方向的了解越多，他们就越能理解他们的特定功能在大局中的范围。
然而另一方面，我的很多时间似乎都浪费在所有不同利益相关者和经理之间的电子邮件海洋中，所以我喜欢认为将开发人员隔离到“他们需要做他们当前的工作” "将使他们免受干扰。
我曾考虑只密件抄送所有开发人员，以便他们可以过滤这些电子邮件并基本上“选择加入”所有电子邮件，但我担心一些开发人员只会将此视为需要处理的额外噪音。如果所有开发人员都想为太多讨论做出贡献，它可能会为“太多厨师”打开大门。然而另一方面，其他意见可以帮助我做出更好的决定（即 House MD 风格）。
呼……要考虑的太多了。有人在这方面有一些明智的指导吗？
回答晚了，但仍然相信有一些东西可以添加到迄今为止给出的极好的建议中。要回答您的问题，我们需要更上一层楼，因此需要较长的回复。
您已被任命为负责团队的技术主管，尽管您日常工作的许多方面可能看起来与您的开发日相似，但您需要处理它们的方式已经改变。在软件开发环境中，与成为建筑工地或工厂的领班相比，当您任命技术负责人（您可能仍然坐在同一张桌子上，穿着相同的衣服）时，通常不会有太大的变化。不过，令人高兴的变化是，您现在被邀请参加所有这些会议，并开始收到来自开发团队以外人员的所有这些电子邮件和电话。
缺乏切实的改变可能会欺骗你的思想，认为你只需要保持基本相同的工作即可。情况并非如此，您需要意识到自己在新身份中的行动和重新行动。看起来你现在在外部有点“更受尊重”，你可能倾向于在内部分享一些“尊重”，表现出一点民主，而且总体上是公平的。
好吧，这与公平或尊重无关，新工作是：
指导开发团队（主要通过个人示例和创建描述目标的图像）。
成为团队与其他组织单位之间的抽象层。
就像在编程中经常创建一个抽象层来封装和隐藏复杂性一样，在组织中也会发生同样的情况。你是层，必须封装开发团队的接口。从局外人的角度来看，任何好的封装：
向外部观察者隐藏与手头任务（例如算法的具体实现）无关的内部复杂性。
使可能影响外部用户的事情变得明确（可以抛出的异常、任何限制和约束等）。
总是给出有意义的反馈。
行动一致。
这些原则同样适用于团队的对外沟通。遵循这些原则并非易事；实际上它涉及很多具体的工作，例如决定哪些细节是内部的，哪些事实需要传达，何时，反馈需要如何以最佳方式组织和以一致的方式呈现，以及应该向外部通知谁，谁需要跟进，何时跟进。这是很多工作，即使其中一些似乎只是微不足道的管理员。
现在到内部，内部沟通。一种方法是广播。但它阻塞了内部网络，每个人都必须花时间来决定通信是否与他们有任何关联。这就像拥有一个非常通用的算法，无论输入如何，它总是做完全相同的工作量。这当然是可能的，但你为什么要这样做呢？一种更有效的方法显然是根据输入来调整处理，这里必须有人的工作来决定团队应该如何做某事、调度或转换输入：
决定需要采取的行动顺序，
或者只是确认并存储以供将来参考，
或跟进，
或者将问题推迟到以后审查，然后确保对其进行审查并将其反馈到决策循环中。
这也不是一项小工作，必须有人去做。显然，现在管理外向和内向的沟通是你的工作，你必须花费你大脑的一些处理能力才能把它做好，所以没有其他人需要，开发人员可以专注于他们的任务。
不管你的职位是什么，不要抄送或密送所有人还有其他一些很好的理由：
TO 表示“采取行动”，CC - “记下以备将来参考”，BCC - “窃听或群发邮件”。当您使用一个或另一个电子邮件给一群人时，您应该小心：
给一个人发电子邮件是一个简单的“收件人”，当给一群人发电子邮件时，只“给”那些你需要采取行动的人（包括一个简单的确认）。这是默认含义，在任何其他情况下明确告诉他们预期的内容（即仅供参考，无需采取行动等）。
只抄送那些你想记下的信息，以备日后参考。如果您希望在达成协议或解决问题之前来回发送大量电子邮件，请不要“抄送”，最好稍后将摘要确认发送给需要通知的其他方。除了节省每个人的时间并避免由于有人注意到非最终沟通而产生的误解，这将有助于使交流更加个人化、更加自然地进行，并减少形式主义和繁文缛节。通常 CC-d 电子邮件被正式处理，这并不总是一件好事（但有时正是你想要的）。
使用密件抄送几乎是不可能的。如果有人窃听你的谈话，一旦曝光，很容易破坏你的可信度。这只是一个“何时”的问题。那么您的团队是否应该担心您可能会将他们的谈话密送给其他人？在大多数情况下，通过密件抄送群发邮件也是错误的，它给人的印象是电子邮件是专门针对收件人的。
转发、CC-ing 和 BCC-ing 需要很少的努力，但会增加噪声并稀释信号。值得考虑一下您到底需要一个人做什么，以及在撰写之前他们应该知道什么来对您的沟通采取行动。
有些对话最好完全“脱机”（电话或更好的面对面），因为它为您提供了更多的操作空间。广播或书面形式化就像让自己陷入困境。您可以随时以书面形式确认后者。
转到技术主管职责的第二部分（通过个人示例和描绘目标的图像来指导团队）。要做到这一点，您无需将碰巧在收件箱中结束的每一条信息都传递给团队。你必须创造一个故事，任何好的故事都是真实事件的抽象，只包含特定受众的相关和有趣的细节。根据你的日常经验创建这个简短的故事，判断什么是相关的和有趣的，然后定期向团队展示它也是一项艰巨的工作。
但是不要忘记，通过指导团队并充当抽象层，您可以帮助开发人员和外部世界更有效地交互，完成更多工作并解决更大的复杂性，这项工作是有意义的。
工程团队需要了解为什么要求他们在宏观层面上做事的商业原因。工程团队将从中获得理解和动力。但是太多的喋喋不休是一个禁忌，正如你所指出的，你的工作的一部分是过滤，其中一部分意味着不要让他们暴露在大量的噪音中。您的开发人员可能对如何做特定事情或为什么选择特定技术有意见和见解，他们应该因为他们在这些领域的专业知识而被派上用场。
绝对不要创造一种密件抄送的文化。
一种选择是有单独的邮件列表，感兴趣的各方可以订阅，但当然，并不是所有的聊天都会在这些列表中。
当然，定期的公司会议是必须的。让工程人员知道为什么业务依赖于交付稳定、完整的产品（或即将到来的里程碑所需的任何东西）。20 分钟，没有幻灯片，没有废话对我有用。您的团队和情况可能会有所不同。
一种方法可能是不转发所有这些电子邮件，而是每周一次将所有相关信息、设计变更等汇总到每周会议中。我绝对不会向开发人员发送大量电子邮件。当然，如果讨论了一些关键问题，那么应该引起他们的注意。但是，请尝试每周回顾和讨论相关细节。
我会使用 Wiki，您不想添加到电子邮件风暴中，并且您的开发人员也可以贡献和改变事物。它对于共享文档也非常有用，如果做得好，它将成为自支持的。
顺便说一句，从电子邮件剪切/粘贴到 wiki 似乎是一件奇怪的事情，有人知道我也可以通过电子邮件发送内容的轻量级 .Net wiki 吗？
听起来你很技术，所以我会给你这个建议：遵循 Joel Spolsky 关于项目经理做什么的建议。基本上，尝试尽可能地隔离您的开发人员，以便他们尽可能高效。
他刚刚在最近的这篇文章《如何成为一名项目经理》中简单地提到了这一点，但他之前已经对这个话题进行了更深入的探讨。查看他过去的著作以获取更多信息：
一旦规范完成并且开发团队开始工作，我有两个责任：解决关于设计的任何问题，并与所有其他团队交谈，这样开发人员就不必这样做了。
如果你不是技术人员，那么你需要从你的团队中选择一个人来帮助设计工作，他们将不得不与客户进行一些交流，以弄清楚需求是什么以及最好的设计是什么。
编辑：在Joel 的主页上有两个部分，标题为 Tech Lead 和 Program Manager。查看那里的文章以获取有关程序管理器的更多信息，尤其是认为有害的人工任务开关。
我在发布一年后看到这个问题，但是我可以为我的案例添加一些特定数据的经验。对于项目中的 2-3 名开发人员，我主要是一对一的。很多时候，我通过 IM 或电话进行此操作，因为我的团队中的大多数人都在家庭办公室度过了很多时间。不时开会是不可避免的，主要是在项目开始时（1-2 次开发人员会议往往足以启动相当复杂的项目），但通常，与公司其他成员的所有沟通都通过我，开发人员得到摘要。唯一的例外是当我直接将开发人员与用户（而不是管理人员！）联系起来以制定项目的详细信息时。
我倾向于避免定期会议（每周或每天），并且仅在至少发生两次会议时才安排会议，按以下顺序：
对于 4-8 人的团队（8 人通常意味着两个团队），我发现每周大约一次 30 分钟的简短会议足以让每个人都了解最新情况。当然，这是我每天为初级开发人员做的一对一以及每周为高级开发人员做两次的一对一的补充。
对于一对一，我更喜欢开发人员在他们寻找更多要做的事情或者当他们对刚开始做的任务有疑问时与我联系。这对我来说也是一个很好的方式来关注事情的进展，而开发人员不需要考虑让我保持最新状态。当即时消息足够时，我倾向于避免使用电子邮件，否则切换到电话（当有一些事情需要解释或讨论时）并在以下情况下使用电子邮件：
当他们需要协调某些事情时（例如，当 Java 和 Javascript 开发人员需要制定接口细节时）也会有开发人员对开发人员的会议。
这种工作方式意味着我必须尽可能快地响应 IM，而且我通常会处理很多中断，因此开发人员只需要为我或其他开发人员处理中断。没关系，因为我工作的重要部分是让开发人员有效。
如果我需要安静地进行编码（并且负担得起），我发现将客户沟通委托给非技术项目经理甚至是 beta 测试人员（他们比程序员更擅长分心）。
问他们更喜欢什么。我认为他们宁愿不要在每封电子邮件上抄送，而是会选择定期进行简短的口头更新。