Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.
You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.
The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.
Well, this is not that much about fairness or respect, the new job is to:
Direct the dev team (mostly by personal example and creating imagery depicting the goal).
Be an abstraction layer between the team and other organisational units.
Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:
Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.
Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).
Always gives meaningful feedback.
Acts consistently.
These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.
Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:
Decide what sequence of actions needs to be taken,
or just acknowledge and store for future reference,
or follow up,
or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.
This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.
There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:
TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:
E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).
CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).
Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.
Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.
Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.
Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.
But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.
The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.
Definitely don't create a culture of BCCing.
One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.
And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.
It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.
He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:
Once the spec was finished and the development team got down to work, I had two responsibilities: resolving any questions that came up about the design, and talking to all the other teams so that the developers didn’t have to.
If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.
顺便说一句，从电子邮件剪切/粘贴到 wiki 似乎是一件奇怪的事情，有谁知道我也可以通过电子邮件发送内容的 lightwieght .Net wiki 吗？
I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.
BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?
One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.
I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.
I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:
Important info comes in (depending on urgency this can wait up to a week)
Developers are in the office, preferably for other reasons (developer-to-developer meetings)
Client is available (not much choice there, but I try to do meetings and connect developers with single hands-on expert on the client's side later)
I need design advice (since I'm a technical lead, I'm responsible for most of the high-level architectural decisions)
For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.
For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:
Customer reported bug via e-mail
There are a lot of important small details and developer will probably go through that e-mail a lot of times during implementation
There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).
This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.
If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).
发布评论
评论（7）
虽然回复晚了，但仍然相信到目前为止给出的极好的建议还有一些可以补充的地方。 为了回答你的问题，我们需要更高的水平，因此回复很长。
您已被任命为负责团队的技术主管，尽管您日常工作的许多方面可能看起来与您的开发日相似，但您需要处理这些问题的方式已经发生了变化。 在软件开发环境中，当您任命技术主管时（您可能仍然坐在同一张桌子上，穿着相同的衣服），与成为建筑工地或工厂的工头相比，通常不会有太大的实际变化。 不过，令人高兴的变化是，您现在被邀请参加所有这些会议，并开始收到来自开发团队之外的人的所有这些电子邮件和电话。
缺乏切实的改变可能会欺骗你的思维，让你认为你只需要继续以基本相同的方式对待你的工作。 情况并非如此，您需要对自己在新身份下的行为和反应保持警惕。 看起来你现在在外部似乎“更受尊重”，而你可能倾向于在内部分享一些“尊重”，发挥一点民主，总体上是公平的。
好吧，这与公平或尊重无关，新工作是：
指导开发团队（主要是通过个人例子并创建描述目标的图像）。
成为团队和其他组织单位之间的抽象层。
就像在编程中一样，您经常创建一个抽象层来封装和隐藏复杂性，组织中也会发生同样的情况。 您是必须封装开发团队的层、界面。 从局外人的角度来看，任何良好的封装都是：
向外部观察者隐藏与手头任务（例如算法的具体实现）无关的内部复杂性。
使可能影响外部用户的事情显式化（可以引发的异常、任何限制和约束等）。
使可能影响外部用户的
始终提供有意义的反馈。
行为始终如一。
这些原则同样适用于团队的对外沟通。 遵循这些原则并不是一件容易的事； 实际上，它涉及很多具体工作，例如决定哪些细节是内部的，哪些事实需要沟通，何时沟通，如何最好地构建反馈并以一致的方式呈现，以及应该向外部通知谁什么内容，以及谁需要跟进以及何时跟进。 这是一项繁重的工作，即使其中一些看起来只是微不足道的管理工作。
现在进行内部、内部的沟通。 一种方法是广播。 但它会堵塞内部网络，每个人都必须花时间来决定通信是否与他们相关。 这就像有一个非常通用的算法，无论输入如何，总是执行完全相同的工作量。 这当然是可能的，但你为什么要这样做呢？ 显然，更有效的方法是根据输入调整处理，这里必须有人的工作来决定团队应该如何处理某件事、调度或转换输入：
决定需要什么顺序的操作决定
或者只是确认并存储以供将来参考，
或者跟进，
或推迟问题以供稍后审核，然后确保对其进行审核并反馈到决策循环中。
这也不是一项小工作，必须有人来做。 显然，现在管理向外和向内的沟通是你的工作，你必须花费你大脑的一些处理能力才能做好这件事，这样其他人就不需要这样做，开发人员可以专注于他们的任务。
无论您的职位如何，还有一些其他好的理由不要抄送或密送每个人：
TO 表示“采取行动”，CC —“记下以供将来参考”，BCC —“窃听或群发邮件” 。 当您使用一个或另一个电子邮件向一群人发送电子邮件时应该小心：
向一个人发送电子邮件是一个直接的“收件人”，而向一群人发送电子邮件时，仅“向”那些您需要采取行动（包括简单的确认）的人。 这是默认含义，在任何其他情况下明确告诉他们期望什么（即仅供参考，无需采取任何行动等）。
仅抄送那些您想要记下该信息以供将来参考的人。 如果您预计在达成协议或问题解决之前会收到大量电子邮件，请不要“抄送”，最好稍后向需要通知的其他方发送确认摘要。 除了节省每个人的时间，避免由于有人记录非最终沟通而产生误解，这将有助于使交流更加个性化，更加自然，并减少形式主义和繁文缛节。 通常抄送电子邮件会被正式处理，这并不总是一件好事（但有时正是您想要的）。
使用密件抄送几乎永远都行不通。 如果有人窃听你的谈话，这种情况一旦曝光，很容易就会毁掉你的可信度。 这只是一个“何时”的问题。 那么您的团队是否应该担心您可能会将他们的对话密件抄送给其他人？ 在大多数情况下，通过密件抄送进行群发邮件也是错误的，它会造成电子邮件是专门发送给收件人的印象。
转发、抄送和密件抄送不需要什么努力，但会增加噪音并削弱信号。 在撰写通信之前，值得考虑一下您到底需要一个人做什么，以及他们应该知道什么来对您的通信采取行动。
有些对话最好完全“离线”进行（通过电话或面对面更好），因为这样可以给你更多的回旋余地。 广播或以书面形式形式化就像把自己逼到了一个角落。 您可以稍后以书面形式确认。
转到技术主管职责的第二部分（通过个人例子和描述目标的图像来指导团队）。 为了实现这一目标，您不需要将收件箱中的每一条信息传递给团队。 你必须创造一个故事，任何好故事都是对真实事件的抽象，仅包含与特定受众相关且有趣的细节。 根据你的日常经验创建这个简短的故事，判断什么是相关的和有趣的，然后定期向团队展示也是一项艰巨的工作。
但不要忘记，通过指导团队并充当抽象层，您可以帮助开发人员和外部世界更有效地交互，完成更多任务并解决更大的复杂性，这项工作是有意义的。
Answering late, but still believe there is something to add to the superb advice given so far. To answer your question we need to go a level higher, hence the long response.
You’ve been made a tech lead responsible for team and although many aspects of your everyday job might seem to resemble your dev days the way you need to go about them has changed. In software development environment there is usually not that much of a tangible change when you appointed a tech lead (you’re probably still seating at the same desk, wearing the same outfit) as opposed to becoming a foreman on construction site or a factory. The flattering change though is that you now get invited into all these meeting and start getting all these e-mails and phone calls from people outside the dev team.
The lack of tangible change might trick your mind into thinking that you just need to keep treating your job mostly the same. This is not the case and you need to be conscious about your actions and re-actions in the new capacity. It might seem you’re now a bit “more respected” externally and you might be inclined to share some of that “respect” coming your way internally, play a bit of democracy and generally be fair.
Well, this is not that much about fairness or respect, the new job is to:
Direct the dev team (mostly by personal example and creating imagery depicting the goal).
Be an abstraction layer between the team and other organisational units.
Pretty much like in programming you often create an abstraction layer to encapsulate and hide complexity, the same happens in organisations. You’re the layer, the interface that has to encapsulate the dev team. And any good encapsulation from an outsider point of view:
Hides inner complexity that is not relevant to the task at hand (such as concrete implementation of an algorithm) from the outside observer.
Makes things that could affect the outside user explicit (exceptions that can be thrown, any limitations and constraints etc).
Always gives meaningful feedback.
Acts consistently.
These principles are equally applicable to the team’s outward communication. It’s not an easy task to follow these principles; actually it involves a lot of concrete work, such as deciding what details are internal and what facts need to be communicated and when, how the feedback needs to be best structured and be presented in a consistent manner and who should be notified externally of what, and who needs to followed up and when. This is a lot of work, even if some of it seems to be just trivial admin.
Now to internal, inward communication. One way is to broadcast. But it clogs the internal network and everyone has to spend their time on deciding whether the communication bears any relevance to them. It is like having a very generic algorithm that regardless of input always does the exact same amount of work. It’s sure possible, but why would you want to do that? A more efficient way is obviously to adjust processing depending on the input and here it has to be someone’s job to make a decision how the team should go about something, to dispatch, or convert the input:
Decide what sequence of actions needs to be taken,
or just acknowledge and store for future reference,
or follow up,
or put an issue off for a later review and then make sure it is reviewed and fed back into the decision-making loop.
This is not a small job either and someone has to do it. Obviously now it’s your job to manage the outward and inward communication, and you have to spend some of your brain’s processing power to do it well, so no one else has to and devs can concentrate on their tasks.
There are some other good reasons for not CC-ing or BCC-ing everyone regardless of your job title:
TO means “take action”, CC — “take note for future reference”, BCC — “eavesdrop or mass mail”. You should be careful when you use one or another e-mailing a group of people:
E-mailing a single person is a straight forward “TO”, when E-mailing a group of people only “TO” these who you need to take action (including a simple acknowledgement). This is default meaning, in any other case explicitly tell them what is expected (i.e. FYI, no action needed etc).
CC only these who you want to take note of the information for the future reference. If you expect a number of e-mails to go back and forth before an agreement is reached or issue is resolved don’t “CC”, it’s best to send a summary confirmation later to other parties that need to be notified. Besides saving everyone’s time and avoiding misinterpretation due to someone taking note of a non-final communication that will help make exchange more personal, flow more naturally, and reduce formalism and red-tape. Often CC-d e-mails treated formally and this isn’t always a good thing (but sometimes exactly what you want).
Using BCC is almost never ok. The knowledge of someone eavesdropping on your conversations if come to light will easily ruin your trustworthiness. It is simply a question of “when”. And should your team worry then that you might be BCC-ing their conversations to someone else? Mass mailing through BCC in most cases is also wrong, it creates an impression that e-mail is specifically addressed to the recipient.
Forwarding, CC-ing and BCC-ing require little effort, but multiply noise and dilutes signal. It is worth to give some thought to what exactly you need a person to do and what they should know to act on your communication before composing it.
Some conversations are best taken completely "off line" (phone or better still face-to-face), because it gives you more room for maneveour. Broadcasting or formalising in writting is just like putting yourself into a corner. You can always confirm in writing latter.
Moving to the second part of a tech lead responsibility (directing the team through personal example and imagery depicting the goal). To accomplish that you don’t need to pass on to the team every single piece of information that happen to end in your inbox. You have to create a story and any good story is an abstraction of real events that consists of only relevant and interesting detail for a particular audience. Creating this brief story on the basis of your everyday experience and judging what is relevant and interesting and then presenting it regularly to the team is also quite a job.
But don't forget that by directing the team and serving as abstraction layer you help developers and outside world to interact more efficiently, accomplish more and tackle greater complexity, the job has a point.
工程团队需要了解他们被要求在宏观层面上做事的业务原因。 工程团队将从中获得理解和动力。 但过多的闲聊是禁忌，正如您所指出的，您的工作之一是过滤，其中一部分意味着不要让他们暴露在大量噪音中。 您的开发人员可能对如何做特定的事情或为什么选择特定的技术有意见和见解，并且他们应该在这些领域发挥专业知识。
绝对不要创造密件抄送的文化。
一种选择是建立感兴趣的各方可以订阅的单独的邮件列表，但当然，并非所有的聊天内容都会出现在这些列表上。
当然，定期的公司会议是必须的。 让工程人员知道为什么业务依赖于交付稳定、完整的产品（或即将到来的里程碑所需的任何内容）。 20 分钟，没有幻灯片，没有废话，这对我来说很有效。 您的团队& 情况可能会有所不同。
The engineering team needs to understand the business reasons of why they are asked to do things on a macro-level. The engineering team will gain understanding and motivation from this. But too much chatter is a no-no, as you note, part of your job is to filter, and part of that means not exposing them to tons of noise. Your developers likely have opinions and insights as to how to do particular things or why to pick particular technologies, and they should be fielded for their expertise in those areas.
Definitely don't create a culture of BCCing.
One option is to have separate mailing lists that interested parties can subscribe to, but of course, not all chatter will be on those lists.
And of course, a regular company meeting is a must. Let the engineering guys know why the business depends on delivery of a stable, complete product (or whatever the upcoming milestones require). 20 minutes, no slides, no bullshit is what works for me. Your team & situation may vary.
听起来您是技术人员，所以我会给您以下建议：遵循 Joel Spolsky 关于项目经理做什么的建议。 基本上，尝试尽可能地隔离您的开发人员，以便他们尽可能提高工作效率。
他刚刚在最近的文章如何成为项目经理，但他之前已经更深入地讨论过这个话题。 查看他过去的著作以获取更多信息：
如果您不是技术人员，那么您需要从团队中选择某人来帮助设计工作，他们将必须与客户进行一些交流，以弄清楚需求是什么以及最佳设计是什么。
编辑：
Joel 的主页上有两个部分，标题为“技术主管”和“项目经理”。 请参阅那里的文章，了解有关程序管理器的更多信息，尤其是被认为有害的人类任务切换。
It sounds like you're technical so I would give you this advice: Follow Joel Spolsky's advice on what Program Managers do. Basically, try to isolate your developers as much as possible so they can be as productive as possible.
He just mentioned this briefly in this recent article, How to be a program manager, but he has gone into more depth on this topic before. Look through his past writings for more info:
If you aren't technical then you need to select someone from your team to help with the design work and they will have to interface with the customer a little to figure out what the requirements are and what the best design is.
EDIT:
On Joel's home page there are two sections titled Tech Lead and Program Manager. Look at the articles there for some more info on program managers, especially Human Task Switches Considered Harmful.
我会使用 Wiki，您不想添加到电子邮件风暴中，并且您的开发人员也可以贡献和更改内容。 它对于共享文档也非常有用，如果做得好，它将变得自给自足。
顺便说一句，从电子邮件剪切/粘贴到 wiki 似乎是一件奇怪的事情，有谁知道我也可以通过电子邮件发送内容的 lightwieght .Net wiki 吗？
I'd be using a Wiki, you don't want to add to the email storm, and your developers can also contribute and change things. It's also really useful for sharing documents, and if done well it will become self-supporting.
BTW Cut/Paste from email to wiki seems like an odd thing to have to do, does anyone know a lightwieght .Net wiki that I can email content too?
一种方法可能是不转发所有这些电子邮件，而是每周一次将所有相关信息、设计变更等汇总到每周一次的会议中。 我绝对不会向开发人员发送大量电子邮件。 当然，如果讨论了一些关键的事情，那么应该引起他们的注意。 然而，尝试每周回顾并讨论相关细节。
One way might be to not forward all those emails and once a week compile all the relevant information, design changes, and so forth into a weekly meeting. I definitely wouldn't send out a barrage of emails to the developers. Of course, if something critical is discussed, then that should be put to their attention. However, try for a weekly recap and discussion of relevant details.
我在发布一年后看到这个问题，但是我可以添加我的经验以及针对我的案例的一些具体数据。 对于项目中的 2-3 名开发人员，我主要进行一对一的交流。 很多时候我通过即时消息或电话来完成此操作，因为我的团队大部分时间都在家庭办公室度过。 时不时的会议是不可避免的，主要是在项目开始时（1-2 次开发人员会议往往足以启动相当复杂的项目），但通常情况下，与公司其他部门的所有沟通都通过我进行，开发人员得到摘要。 唯一的例外是当我直接将开发人员与用户（而不是管理层！）联系起来以制定项目的详细信息时。
我倾向于避免定期会议（每周或每天），并且仅在至少发生其中两种情况时才安排会议，按以下顺序：
对于 4-8 人的团队（8 人通常意味着两个团队）我发现大约每周一次简短的 30 分钟会议就足够了让每个人都了解最新情况。 当然，这是我每天为初级开发人员进行的一对一交流以及每周为高级开发人员进行的大约两次的一对一交流之外的活动。
对于一对一的交流，我更希望开发人员在需要做更多事情或对刚刚开始执行的任务有疑问时与我联系。 这也是我关注事情进展情况的好方法，而开发人员不需要考虑让我了解最新情况。 当 IM 足够时，我倾向于避免使用电子邮件，否则在以下情况下切换到电话（当有事情需要解释或讨论时）并发送电子邮件：
当需要协调某些事情时（例如，当 Java 和 Javascript 开发人员需要制定接口细节时），还会召开开发人员之间的会议。
这种工作方式意味着我必须尽快响应 IM，并且我通常会处理很多中断，以便开发人员只需为我或其他开发人员处理中断。 这没关系，因为我工作的重要部分是提高开发人员的效率。
如果我需要安静地编码（并且负担得起），我发现将客户沟通委托给非技术项目经理甚至 beta 测试人员（他们比程序员更能处理干扰问题）。
I'm seeing this question one year after it's been posted, however I can add my experience with some specific data for my case. For 2-3 developers on the project, I mostly do one-on-ones. Lot of times I do this over the IM or phone since most of my team spends a lot of time in home office. Meeting from time to time is inevitable, mostly when project is starting (1-2 developer meetings tend to be enough to kick off reasonably complicated project), but as a rule, all communication with the rest of the company goes through me and developers get a digest. Only exception is when I connect developer directly with the user (not management!) to work out details of the project.
I tend to avoid regular meetings (weekly or daily) and schedule meetings only when at least two of these happen, in this order:
For teams of 4-8 people (8 people usually means two teams) I found out that short 30-minute meeting roughly once a week is more then enough to keep everyone up to date. This, of course, is in addition to one-on-ones which I do daily for junior developer and about twice a week for senior developers.
For one-on-ones, I prefer that developers contact me when they're looking for more to do or when they're have questions on task they just started doing. This is also a great way for me to keep eye on how things are going without developers needing to think about keeping me up to date. I tend to avoid e-mail when IM is enough, otherwise switch to phone (when there's something to explain or discuss) and to e-mail when:
There are also developer-to-developer meetings when they need to coordinate on something (for example, when Java and Javascript developer need to work out interface details).
This way of working means that I have to respond to IM as fast as possible, and that I usually deal with a lot of interruptions so that developers have to deal only with interruptions for me or other developers. Which is OK, since important part of my job is to make developers effective.
If I need peace for coding (and can afford it) I found that delegating client communication to non-technical project managers and even beta testers (who are much better with distractions than programmers).
询问他们更喜欢什么。 我认为他们宁愿不抄送每封电子邮件，而会选择定期进行简短的口头更新。
Ask them what they'd prefer. I assume they would rather not be cc'd on every email and would opt for a short verbal update on a regular basis.