Say what you like about a meeting… A bunch of people around a table, if an issue comes up, it usually ends up on someone’s agenda.

Regular project meetings can filter this stuff really well, but someone needs to be on top of tracking open issues.

In my business we’d use checklists of active issues and circulate them.

There are a lot of great ideas in this thread, so thanks to Merlin for throwing this open. I think we are all talking in this thread about several slightly different but related issues. There is lots of good discussion on how to deal with delegation of action or requests from outside the team.

I think the original meat of the question though is about how to deal with team members probing each other for knowledge and for that I think I have to say that email is absolutely the wrong tool. The essential components of this communication seem to be: 1) to make sure that everybody can see the question and 2) to see whether someone else has responded. Once those objectives are achieved, the rest of the team is absolved of the task and the conversation can continue in private. To fulfill those objectives some sort of instantaneous communication is necessary and I think that is why bug tracking systems and wikis will not suffice. The problem with email for this task is that while responses are being drafted no notification arrives that a draft is underway which would absolve the remaining team members of the question.

If I were working on a team that had this problem I would want to try to get everyone on the team using Twitter or a Twitter-alike for these sorts of queries. In using Twitter a query can easily go out to all members of a team, and then an immediate response can come back from the party who has the knowledge claiming responsibility. At that point everybody else is absolved and goes on with their lives.

Caveats are that the Twitter tool easily becomes a source of distraction. A solution is that any team using such a tool needs to be establish a boundary that reserves use for business and forbids non essential chat or other distractions. Another solution is for individuals to hide their Twitter reader while working and make disciplined decisions about when to check it (and act on or respond to it!) as they would do with any other technology (email, RSS reader, etc).

Hope this helps.

It was said a bunch of times above but bears repeating. The low level problem here is, if two people are responsible for some thing, then no one is responsible for it.

The only way around it is to set it up so someone is primary for catching list things and handling them. Ideally you find a way to prevent the other people from even seeing the requests unless necessary. If it is important set up a heel to toe watch, even go as far as to have a little informal handoff ceremony.

It can help to have a visible token, a huge dunce cap or a traffic cone or a stuffed animal, anything. This will help remind the person they are on watch, and they will be very happy to get rid of this token so they won’t forget to make the hand off. It also can serve as a clue to other employees who run of to the first random tech team member to ask a question. It can put extra strain on the person catching, but it really helps keep other people from unnecessary, unplanned for interruptions.

Most commenters here seem to get the nature of the problem and the solution. Nod to Brandon who knows my context and what I was about to blather on about. E-mail as the input interface for asking questions/requesting action is ok, not great though. We permit people to submit to our two-person “help desk”, via a single email address, their requests - which are then automatically converted into a “ticket” within a popular open source issue tracking program. The next part is up to us to “take ownership” of individual requests as we see them streaming into the queue. Since the ticket owner’s and ticket requestor’s conversation is both stored in the database and telecast via e-mail to both of us we can keep up with just what we own or follow the other guy’s work when doing so is helpful.

Making the input interface as easy and convenient for both requestors and techs is key. When people submit questions to our individual email address we usually scold them but simply forward it to the correct address for capture anyway. When we don’t take ownership of a ticket we work on, or handle problems without using the tracking software we shoot ourselves in the foot by duplicating efforts or, worse, giving conflicting information. Keeping it simple so that we use our “system” is very important.

The mailing list as the total “system” for generating actions/answers may seem to be a simple solution, but it really isn’t a solution at all. It isn’t anything more than screaming out loud and expecting that someone, somewhere will give a crap and come to your rescue. Children, infants especially, do this. Managers and “knowledge workers” should not do this. It is a recipe for failure.

I agree that email is the wrong tool for this kind of question, because not every response is visible to every other user.

I knew a Senior Vice President client of min who deliberately would ask several of his Vice Presidents the same request, because he “didn’t know who would get the task done.”

Over time, I discovered, he taught them all to ignore his requests, because they figured out that his game.

By the time I got there he was disgusted, and they were angry, and little was getting done.

I see a parallel here. An email sent in this manner is a poor use of the medium, and a wiki or some other kind of fixed community is a much better way to tackle these kinds of questions.

My team that works as production support for several applications does what many others have written about. The on-call person for the week has the responsability for answering all emails that are sent to our group. If the email is for a problem or a request for service, they are sent back a email telling team to open a problem ticket or request ticket to our team. General information emails are answered by the on-call person, topics that a specific person is the best to handle are sent to that person.

The important thing is that problems and requests for services are sent into tools that are better at tracking status and generating metrics than email. If a SLA is missed because the problem was reported only in a email it is on the sender. If it is missed and it was in the problem tracking tool it is on us. This doesn’t happen often or at all because of the tracking features in the tool.

I used to work on a team that handled this issue by taking it out of e-mail. Any such e-mail would be responded to with a template by anyone in the TO: field (CCs ignored it). If you had 20 people in the TO: field, you got flooded by template responses, which usually broke people of that habit.

The template would redirect them to a ticketing system. We’ve used Trac and TasksPro, but any ticketing system will work. In the ticketing system, the submitter is forced to select a single owner (often by default, as the owner of the component they’re ticketing).

The other aspect that made this work for us, so that people did not have to constantly check the ticketing system was RSS feeds. By adding the feeds for your projects to your news reader, which you probably have open anyway, you get updates on your tasks regularly. We also provided RSS feeds for lots of other stuff, like spec changes. Worked really well right up until that team was disbanded. The other teams still haven’t caught up. ;)

I saw this post the other day on Lifehacker about turning your mailing list into an RSS feed. At least then the info is out of the mailbox and into an RSS reader, which is an app designed to make unmanagable streams of information managable…

http://lifehacker.com/software/how-to/turn-mailing-lists-into-an-rss-feed-283353.php

When I worked in customer service for a bank this was a major issue, we (the dept. I worked in) did one thing created an “email wrangler” position that had two responsibilities.

1) Parsing. Everyone in the office regardless of department received the same email update/newsletter. These emails contained information for departments about changes in S.O.P.s, meetings, targets etc as well as question for the team. To free up time for the team the email wrangler for the day would parse out anything about our department and email anything urgent back out to all of us there and then and anything else was kept for an email synopsis at the end of the day.

2) Question cascading. The “email wrangler” would if possible handle any team-based question and if they couldn’t they would email the next person in the list, if they couldn’t answer they would email the next person and so forth until someone who could answer it would email the original question and answer to the whole team and whoever asked the question.

The list for the question cascade and the list for “email wrangler” was the same one and to make sure no-one was always hit with being the first asked to answer a question the email wrangler would email the person after their self rather than starting from the top.

It worked pretty well. The problem with team based questions is that it is like cars at an intersection and there is no traffic lights, everyone stops and waits for someone else to make the move but if traffic is to get moving again the lights either start working again but that means talking to the city council(management) or someone needs to start directing traffic(team member)

I work in a law firm, and this happens all the time. Since I’m too busy, I usually ignore any requests not specifically meant for me. The sender can always specifically ask me if they would like.

I can think of a number of ways of handling these though, I probably go through some form of the following process sometimes:

If you don’t know how to answer; then delete/archive. If you know the answer, and can respond quickly (~5min), do so; delete/archive If you know someone who would know, respond suggesting delegation to that person, delete/archive. If you know the answer, but it would take a while, let them know and ask them to reply directly if they would like you to work on it, then delete/archive.

I think the key is realizing that you need clear responsibility before doing something significant. So just exchange info quickly until it’s clear that you are or aren’t going to get the responsibility. Be helpful, but don’t care (in terms of tracking or worrying about it) about the problem until the sender clearly asks you to. Ask for that clear assignment.