When Can I Expect an Email Response?

An anonymous reader writes "Ever sit there waiting for an email response and wonder what's going on? Did they get it? Did it get filtered? A study looks at the responding habits of a large group of corporate users. They find, among other things, that users would try to 'project a responsiveness image. For example, sending a short reply if a complete reply might take longer than usual, intentionally delaying a reply to make themselves seem busy, or planning out timing strategies for email with read receipts.' Tit-for-tat, 'Users would try to reciprocate email behaviors -- responding quickly to people who responded quickly to them, and lowering their responsiveness to people who responded slowly to them in the past.'"

Comments

Re:Comment on the article

[Anonymous Coward]

I'll often send an email to my boss rather than going down the hall to his office just so that there is a written record somewhere of what I requested from or reported to him.

Re:Priority...

[ZeroExistenZ]

I can assume that a code-monkey who spends his time writing the latest and greatest new program can maybe concentrate on his job at hand for a few hours before dealing with emails.

I write code for a living. My mail-box has typical content like:

• Customer X has problems with a new bug. Please fix.
• I added a bug, please check bugtracker
• FEAUTURE REQUEST! I'd like gizmo special ultra -requires massive redesign- by tomorrow. I saw it somewhere and want it too -Boss
• Meeting at xx/xx/xx about new planned software. Prepare visualizations and analys.
• Manual needed for program in alpha fase. Can you write it? I don't have time for it, too busy on support.
• We wont buy and implement the Novell meta-database. You were on the meeting with Novell, can you make something with the same functionality? Make an analys asap, so we can discuss it.
• I'm still waiting for the update. Customer is growing impatient, CANT YOU JUST QUICKLY UPDATE THE INSTALLER?
• Can you put down a description of the issues we adressed in last meeting? So we can approve the core idea's before you start coding.
• BUG FOUND!! (bug proves to be user configuration-error, described in manual)
• I know product X-version 4 seems to be near completion. But I we might migrate to Linux. I know at first we wanted to use ASP.NET v2.0 (did you use that?) But would it be much work to translate it into PHP? We could cut license-costs that way. These things shouldn't be too hard to translate.
• What's the status on program xzy? The deadline is closing.
• In the meeting we discussed the use case where a new database could solve the problem. Can you design the database, so we can decide to go with it or to drop it? You can skip the specific columns to save time, just make sure you have all the 100 tables we brainstormed about and keep flexibility so we can expand if needed. Can this be done by next week? It would be clearer if you'd explain each table again as a reference.

Trust me, I often don't get around coding as much as I'd want to myself.

Re:And

[Venik]

As a sysadmin I know a thing or two about the way our HR operates. They have things well automated. Emails with job inquiries and resumes are automatically processed and added to the database. They run keyword searches against that database when looking for someone with a specific skillset. Hence the importance of having two versions of your resume: one for sending to specific individuals who might actually read it; and another one optimized for a keyword search.

Let's say they are looking for a sysadmin for their Red Hat cluster. An opening listing appears in the database that says "Red Hat, cluster, system administrator, unix". If you are a Red Hat expert but your resume just says "Linux", you are out of luck. You need to always keep in mind that in many large companies these things are handled by dedicated HR personnel who have no clue about the technical aspects of the job position in question. You goal at this stage is just to get your foot in the door.