Communication is very important, and you need to be sure that everyone knows everything that they need to, or at least how to find it out. Remember that communication has a cost. The cost of reading communication goes up linearly with the number of people who have to read it. Depending on the recipient, the cost of writing also goes up a lot. What I could tell you in the coffee room may have to be put on slides to be presented to the VP. Therefore choose carefully what to communicate, and to whom. Your VP doesn't want to receive every project email. The entire world doesn't need to be invited to every design discussion or CRC session. Your detailed numbers on LoadFactor aren't interesting to anyone, except in the half-hour of discussion after you propose a change for scheduling purposes. --RonJeffries. ---- Most documents should probably be publicly accessible somewhere. I'm talking here about overtly SENDING communications to people. Some examples of communications where I believe you should use judgment about recipient lists, because they aren't useful to everyone or deserve limited distribution for other reasons: 1. System software metrics 2. Detailed test-by-test day-by-day scores. Not the summaries, the details; 3. UML diagrams for the entire system (this one should go to no one). 4. Personnel reviews; 5. Clippings from comp.lang.smalltalk or wiki; 6. The latest emailed political jokes; 7. Minutes of the 40 or so meetings that take place every day in a project of even ten people; 8. Day-by-day person-by-person engineering day statistics; 9. Early drafts of almost anything; 10. Replies to almost any private email. ---- Not communicating has a cost. First, it presumes omniscience about what people do and do not need to know now. Second, it presumes omniscience about what people will and will not need to know in the future. Third, being left out of communication loops leaves people feeling disempowered, particularly for groups like women and minorities for whom there is a tradition of marginalization. Rarely do I see projects suffer from VPs being swamped with every project e-mail (who makes up this stuff?) or from the whole world coming to a CRC session (even if they were invited). However, there is strong empirical evidence that intense communication aids productivity and overall effectiveness. That includes both technical communications and social grooming. And it goes way beyond PairProgramming. It has something to do with culture. And that's something well understood by people who understand organizations that get beyond the point of small talk. -- JimCoplien ''Hi Jim. Thanks for stopping by. I'm sorry you didn't get that I'm not against communication, I'm suggesting not copying everyone on everything. And if you are suggesting that, I'm quite surprised.'' ''The CIO of Chrysler reportedly receives over 1000 emails a day. Even if this is off by an order of magnitude, it's too many. VPs are in fact not swamped, as you report, because people are in fact exercising judgment (not omniscience) about what to tell the VP.'' ''I've put further examples above that seem to me to require less than omniscience.'' ''If possible, please provide any accessible references to "strong empirical evidence'' etc. Esp references analyzing both cost and benefit of communication. --RonJeffries'' ---- Some personal observations: I get a lot of e-mail that I don't need and don't care about. Some can be immediately trashed. Some require reading to determine that they can be trashed. I'm not a VP, but I imagine a competent and conscientious VP is faced with the same thing, but with different types of information. A more typical VP (at least in my organization) relishes this stuff because they are "mining for issues" for political purposes. And when they find (invent) an "issue", it impacts everybody's productivity. A lot of time is eaten up explaining and debating stuff to people who don't and can't understand and don't need to know just because they were in the massive cc: list. There are exceptions. My direct boss, for example, generally can understand the tech details quite well. ''But he doesn't want to be put in loops that he doesn't need to be in.'' I guess it's a sign of a dysfunctional organization, but I ''do'' see projects suffer from too many of the wrong people being given certain information. It's not so much a matter of actively concealing information as it is not actively spreading the wrong information to the wrong people. (WuWei!) That said, JimCoplien makes a valid point that there are also social issues involved. My attitude is that there is a good rule of thumb in PeopleWhoDontNeedToKnow and -- like all rules -- it needs to be applied with intelligence. --KielHodges The other side of this coin is the constant restating of issues or topics. I hear people going over and over the same issues and solutions. Is this because they have the knowledge and wish to demostrate that they understand? At the same time, we have the manager who has to go over things so many times to feel comfortable that at the end you are hoarse, bald (or at least thinning grey) and have kidney stones. --MarkSpanglet ---- I've been in many meetings where some of the participants were more interested in * exercising their power to kill/preserve a project * show-off their ability to technically "wow" the group * performing CYA manuevers All of these impede the meeting. Definitely, there are those who don't need to know, and thus should not be told. --PeteHardie ---- One idea I've had is based on the idea that interaction between groups is greatly aided by facilitator type people who mediate between groups. These are the people that often naturally arise to bridge the group islands that form based on function, politics, whatever. These aren't official people, just people that are good at this sort of thing. If you want to know X you go to one of the facilitator people and they'll generally know what's going on elsewhere or who is the next best person to talk to. So, generally each group has an email list. Representitives from other groups would be put on each others email lists. This representitive would decide if this email should be forwarded on to their own group. This way filtered forwarding rings are created that should filter uneeded email yet forward on important email. It's not perfect of course, but it should be better. I haven't been able to try this theory out yet. --Oogoody Whenever I get tons of stuff on e-mail lists in a company, I always ask myself "Why isn't this on an intranet?" (Or, "Damn, we should get around to building that intranet.") I think e-mails work best as from one person to one another person. When there are groups of people talking, I think there are better tools for it. ''As one who has recently been removed from all most of the communication loops I can testify that it hurts and it sucks. I can delete email easily. Getting the same information otherwise is difficult.'' Use a Microsoft Exchange "shared folder" or Lotus Notes database for such discussions -- something where people can post and read at their own pace, rather than having a serialized version stuffed in their email basket. Late commers can catch up, browse, or drop in at any point for reference. If the discussion becomes stale for you, you can drop out, and easily join again later, if your interests change. EMAIL is a really inapproprate tool for much of this kind of interaction. -- JeffGrigg Later addition: Shared repositories of threaded news posts not only save space, but one can follow them closely (hourly) or occasionally (weekly/monthly) depending on your level of interest, and one can gracefully "opt out" when you find that things are going just fine without your expert input. Later, if your interests change, you can easily "opt back in," review archives, and get "up to speed." On the other hand, written communication is expensive to produce. There's a lot to be said for poking your head over the cube wall and talking to your neighbors. ;-> -- JeffGrigg ---- For 'actually building that intranet', one of the simplest solutions that I have found is to actually create an 'intra-wiki'! It's worked somewhat well at my current employer; the hardest part is actually to convince people that they have a knowledge to share. (Plus, information that is stored is pretty wide open...) -- ChadThompson ---- We have a daily 10 minute meeting. The goal of it is to allow each person to identify whom they need to talk to that day. ''Why not have a 0 minute meeting and talk to whomever you need to when you become aware of the need?'' ---- Another area to consider is duplication of communication. Instead of refactoring information and presenting it once, I frequently send out the same description of my work to overlapping recipients: *Time Entries (category & description of work) *Weekly Meeting Minutes (where we discuss the work, then document it = same thing as work description) *Project Tracker Spreadsheet (projects/tasks/descriptions/estimations) *Online Bug/Enhancement Tracker *Emails to project managers and workers *Project documentation (if the work resulted in a documentable change). *Verbal communication to the client So if I add a new button to a screen, I have to communicate a record the work in at least 7 places. IMO this is a technology barrior. We need the functionality of email/wiki/bug tracker/spreadsheet/document/timesheet/calendar rolled into one killer app with an open API (for programmable metrics). ---- See also:- SimplifyVigorously