4 ms·

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 'acknow

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 13y 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 13y ago
  [deleted]
ankitml 14y ago
Any developer can tell this is not a good idea. Developers need uninterrupted time of intense concentration.
- davidkatz 13y 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 13y ago
    certainly, but the comment on which i commented wanted me to reply to every query within 1 minute.
mef 14y ago
In your 5 years running a remote team, nobody has ever taken a bathroom break or a lunch break of more than 1 minute?
- davidkatz 13y ago
  Sure, I should have clarified what I mean. Responsiveness in remote environments should be like in a physical office. If you need to, you can walk up to someone and talk to them. Sometimes they're on a break, sometimes they left early, sometimes they didn't come in that day, no problem. Generally though, you can count on being able to talk to someone when you walk up to their station. When running a remote team, I want people to generally "be around". We work very closely together though, so maybe our needs are not a good example.
Swizec 14y ago
As a person working exclusively from home. Screw you, even if I was sitting right next to you, you have no right to expect a response to your query in a minute. I will get to you when it's the appropriate moment in my workflow, otherwise I'm just running around like a headless chicken all day getting nothing done. Working time is headphones on time. You do not distract me when my headphones are on. We are not doctors in an operating room, you can wait 20 minutes. Hell, if I let you wait 20 minutes there's a 90% chance you'll solve the problem without me.
- darkxanthos 14y ago
  Having also been a remote developer your reaction is extreme. There are definitely times where people weren't available within 5 minutes, but if that were the norm our team wouldn't have been nearly as productive.
  - Swizec 14y ago
    I really really don't like going through a 20+ minute interruption cycle every time somebody needs me for two minutes. I would much rather devote a solid 20 minutes, even an hour, to you than half-arsedly devote 20 minutes spread out over 10 hours in one minute chunks.
  - ankitml 14y ago
    As a developer, you either work or you communicate. Try multitasking and your productivity drops. This is not an opinion, but a hard truth that our minds are not meant for multitasking. Secondly, if someone interrupts you during a highly focused session of coding, there is no way you would reach same session immediately after interruption. Think of it as Inturruptability Quotient for every task. It can be roughly defined as ratio of time required to reach same state as before to the time required to finish the job. There are some tasks like writing documentation or editing a proposal, where you can reach similar state of mind as you were before interruption fairly quickly. However for tasks like programming, designing a db or simply thinking abut a hard problem can take even hours to reach the same level. Inturruptability Quotient is sufficiently high here, maybe more than 1 sometimes. Do you even realize how much grave damage it does to productivity.

_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 13y 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 13y ago
[deleted]

ankitml 14y ago

Any developer can tell this is not a good idea. Developers need uninterrupted time of intense concentration.

davidkatz 13y 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 13y ago
  certainly, but the comment on which i commented wanted me to reply to every query within 1 minute.

mef 14y ago

In your 5 years running a remote team, nobody has ever taken a bathroom break or a lunch break of more than 1 minute?

davidkatz 13y ago
Sure, I should have clarified what I mean. Responsiveness in remote environments should be like in a physical office. If you need to, you can walk up to someone and talk to them. Sometimes they're on a break, sometimes they left early, sometimes they didn't come in that day, no problem. Generally though, you can count on being able to talk to someone when you walk up to their station. When running a remote team, I want people to generally "be around". We work very closely together though, so maybe our needs are not a good example.

Swizec 14y ago

As a person working exclusively from home. Screw you, even if I was sitting right next to you, you have no right to expect a response to your query in a minute. I will get to you when it's the appropriate moment in my workflow, otherwise I'm just running around like a headless chicken all day getting nothing done. Working time is headphones on time. You do not distract me when my headphones are on. We are not doctors in an operating room, you can wait 20 minutes. Hell, if I let you wait 20 minutes there's a 90% chance you'll solve the problem without me.

darkxanthos 14y ago
Having also been a remote developer your reaction is extreme. There are definitely times where people weren't available within 5 minutes, but if that were the norm our team wouldn't have been nearly as productive.
- Swizec 14y ago
  I really really don't like going through a 20+ minute interruption cycle every time somebody needs me for two minutes. I would much rather devote a solid 20 minutes, even an hour, to you than half-arsedly devote 20 minutes spread out over 10 hours in one minute chunks.
- ankitml 14y ago
  As a developer, you either work or you communicate. Try multitasking and your productivity drops. This is not an opinion, but a hard truth that our minds are not meant for multitasking. Secondly, if someone interrupts you during a highly focused session of coding, there is no way you would reach same session immediately after interruption. Think of it as Inturruptability Quotient for every task. It can be roughly defined as ratio of time required to reach same state as before to the time required to finish the job. There are some tasks like writing documentation or editing a proposal, where you can reach similar state of mind as you were before interruption fairly quickly. However for tasks like programming, designing a db or simply thinking abut a hard problem can take even hours to reach the same level. Inturruptability Quotient is sufficiently high here, maybe more than 1 sometimes. Do you even realize how much grave damage it does to productivity.