5 ms·

> Respond to any inquiry in up to 24 hours in working days Acknowledge any inquiry within 5-10 minutes unless on a lunch break. Otherwise it means you are afk.

> Respond to any inquiry in up to 24 hours in working days Acknowledge any inquiry within 5-10 minutes unless on a lunch break. Otherwise it means you are afk. (edit) To elaborate - there are two issues involved with this. First is that you are unlikely to ever work on a fully self-contained task that doesn't require collaboration with other people. As such having shared work hours is required. Second issue is that of trust. In common tongue "working from home" means "sleeping in, sitting on a couch, going for two hour lunch breaks, etc". It's a way to slack while pretending to be working. I'm working from home, wink, wink, quote-unquote. In a perfect world you would be judged on deliverables and perfectly met deadlines. In real world, you will frequently need to prove that you've been working and that 1 page of code has indeed been a result of a week of research and numerous rewrites.

drdaeman 14y ago
I'd suggest making several communication channels available, with several priorities. For example, for me a phone call is something that prefers a quick response, an IM message can wait for some time, and a bugtracker ticket or an email is "I'll reply when I'll have time to do it".
- daleharvey 14y ago
  I would put direct email as 'reply asap', usually people ping in irc and if they dont get a response its a direct email. Phone calls are only for very urgent / no point if you dont answer right now, bug tracker is certainly 'when you have time'
davidkatz 14y ago
Absolutely. Working remotely and responding within 24 hours is a complete non starter. Teams need to work tightly together. I'd even go as far as saying 'acknowledge all messages within 1 minute'. Being able to talk to people immediately is critical. (I've been running a remote team for 5 years)
- _pmf_ 14y ago
  > Teams need to work tightly together. I'd even go as far as saying 'acknowledge all messages within 1 minute'. If your units of work are so badly partitioned that this is a requirement, remote or local is not really the problem.
  - davidkatz 14y ago
    I'd disagree, just because people should respond fast when needed doesn't mean they get interrupted all the time. In a physical location, you have the option of interrupting someone when necessary, and you have the option of carrying out a real time conversation with quick response cycles when necessary. Since these things are often necessary, you need to be able to have that happen in a remote environment. I agree with you though on one important thing - issues of interruption have little to do with remote/local. I try to interrupt people as little as possible either way, but I don't want remote working to sacrifice on real time communication when necessary.
  - deleted 14y ago
    [deleted]
- ankitml 14y ago
  Any developer can tell this is not a good idea. Developers need uninterrupted time of intense concentration.
  - davidkatz 14y ago
    I am a developer, and having the option to communicate real time with someone doesn't mean they get interrupted all the time.
    - ankitml 14y ago
      certainly, but the comment on which i commented wanted me to reply to every query within 1 minute.
- mef 14y ago
skidding 14y ago
I'm assuming people will be working from all places around the world, which means different timezones. Maybe one person starts their "shift" just as another one finishes it. You don't want to be wired 24/24. The 24h margin is the longest it can take for an answer before people start getting frustrated. As I mentioned, the average should be way lower, 1-2 minutes preferably, but you can't enforce that at all times when people are working together from different continents. Of course a person who ONLY replies after 24h will be considered unreliable. Also, you must account for no-interruption working blocks. You must be able to take at least 30 minutes w/out having to answer any IM in order to get sh*t done. That's the main reason why 37signals built Campfire in the first place...
- michaelhoney 14y ago
  We're (mainly) in Australia, with one worker currently in Belgium an another in Tokyo. Europe checks in to Campfire before breakfast to catch us "live" at the end of the day for an hour or so of realtime interaction. Asking a remote worker to do something at the end of your day and getting it done while you sleep is a win. When someone's working solo, they still use Campfire to announce what they're doing/thinking: "refactored widget X", "Think I have that validation working". It helps us all understand what's going on. Some of that is just primate grooming behaviour, but we're still primates, so it's useful.
tommoor 14y ago
We're working on a new tool at the minute that helps address some of these problems, by having a persistent visual channel with remote people you can tell if they are really away much more easily, it actually solves a lot of frustrations.
peterkelly 14y ago
> Acknowledge any inquiry within 5-10 minutes unless on a lunch break. Otherwise it means you are afk. Quite possibly the worst piece of productivity advice I've ever seen. Given that if you're concentrating on a task it takes more than that amount of time to get back your train of thought, if you're doing this regularly during the day you'll get almost zero work done. http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html
- huhtenberg 14y ago
  There are Paul's essays and there is real life. In real life, if I have a critical bug that falls into remote dev's domain, he'd better be damn sure to take his headphones off and get back pronto. Because that's exactly what would've happened if he were sitting across the room. Nobody expects a telecommuter to answer right away, but quickly acknowledging a question is a rudimentary communication requirement that goes a long way in building functional team. The "I will get back to you within 24 hours" provision from the linked article is as laughable as it is absolutely ridiculous.

drdaeman 14y ago

I'd suggest making several communication channels available, with several priorities. For example, for me a phone call is something that prefers a quick response, an IM message can wait for some time, and a bugtracker ticket or an email is "I'll reply when I'll have time to do it".

daleharvey 14y ago
I would put direct email as 'reply asap', usually people ping in irc and if they dont get a response its a direct email. Phone calls are only for very urgent / no point if you dont answer right now, bug tracker is certainly 'when you have time'

davidkatz 14y ago

Absolutely. Working remotely and responding within 24 hours is a complete non starter. Teams need to work tightly together. I'd even go as far as saying 'acknowledge all messages within 1 minute'. Being able to talk to people immediately is critical. (I've been running a remote team for 5 years)

_pmf_ 14y ago
> Teams need to work tightly together. I'd even go as far as saying 'acknowledge all messages within 1 minute'. If your units of work are so badly partitioned that this is a requirement, remote or local is not really the problem.
- davidkatz 14y ago
  I'd disagree, just because people should respond fast when needed doesn't mean they get interrupted all the time. In a physical location, you have the option of interrupting someone when necessary, and you have the option of carrying out a real time conversation with quick response cycles when necessary. Since these things are often necessary, you need to be able to have that happen in a remote environment. I agree with you though on one important thing - issues of interruption have little to do with remote/local. I try to interrupt people as little as possible either way, but I don't want remote working to sacrifice on real time communication when necessary.
- deleted 14y ago
  [deleted]
ankitml 14y ago
Any developer can tell this is not a good idea. Developers need uninterrupted time of intense concentration.
- davidkatz 14y ago
  I am a developer, and having the option to communicate real time with someone doesn't mean they get interrupted all the time.
  - ankitml 14y ago
    certainly, but the comment on which i commented wanted me to reply to every query within 1 minute.
mef 14y ago

skidding 14y ago

I'm assuming people will be working from all places around the world, which means different timezones. Maybe one person starts their "shift" just as another one finishes it. You don't want to be wired 24/24. The 24h margin is the longest it can take for an answer before people start getting frustrated. As I mentioned, the average should be way lower, 1-2 minutes preferably, but you can't enforce that at all times when people are working together from different continents. Of course a person who ONLY replies after 24h will be considered unreliable. Also, you must account for no-interruption working blocks. You must be able to take at least 30 minutes w/out having to answer any IM in order to get sh*t done. That's the main reason why 37signals built Campfire in the first place...

michaelhoney 14y ago
We're (mainly) in Australia, with one worker currently in Belgium an another in Tokyo. Europe checks in to Campfire before breakfast to catch us "live" at the end of the day for an hour or so of realtime interaction. Asking a remote worker to do something at the end of your day and getting it done while you sleep is a win. When someone's working solo, they still use Campfire to announce what they're doing/thinking: "refactored widget X", "Think I have that validation working". It helps us all understand what's going on. Some of that is just primate grooming behaviour, but we're still primates, so it's useful.

tommoor 14y ago

We're working on a new tool at the minute that helps address some of these problems, by having a persistent visual channel with remote people you can tell if they are really away much more easily, it actually solves a lot of frustrations.

peterkelly 14y ago

> Acknowledge any inquiry within 5-10 minutes unless on a lunch break. Otherwise it means you are afk. Quite possibly the worst piece of productivity advice I've ever seen. Given that if you're concentrating on a task it takes more than that amount of time to get back your train of thought, if you're doing this regularly during the day you'll get almost zero work done. http://www.paulgraham.com/makersschedule.html http://www.paulgraham.com/makersschedule.html

huhtenberg 14y ago
There are Paul's essays and there is real life. In real life, if I have a critical bug that falls into remote dev's domain, he'd better be damn sure to take his headphones off and get back pronto. Because that's exactly what would've happened if he were sitting across the room. Nobody expects a telecommuter to answer right away, but quickly acknowledging a question is a rudimentary communication requirement that goes a long way in building functional team. The "I will get back to you within 24 hours" provision from the linked article is as laughable as it is absolutely ridiculous.