3 ms·

Honestly, I find it a bit weird so much of this blog post focus on making all information visible and documenting everything (which I agree with) and then there

Honestly, I find it a bit weird so much of this blog post focus on making all information visible and documenting everything (which I agree with) and then there is: > People don't have to say when they are working. That just seems a bit at odds with the rest of the post and I don't really agree with it. Sometimes there are questions that only one person (let's say Nick) can answer or situations where Nick is more valuable than other employees. Let's say I've got a moderately time sensitive issue and I'm pretty sure Kevin knows the answer as he's an expert in the subject, alternatively, I could pull aside Bob, Joe, and Linda and we could probably figure it out after a little while. Knowing when Nick will be back online plays a big factor in what I chose to do next. If Nick is offline for lunch and will be back in an hour, I'll wait for Nick. If Nick started work early and is now offline for a long weekend, well then I need to pull Bob, Joe, and Linda away from their work to help me. Having at least a general idea of when people will be available seems like it'd be even more important in a situation where I can't ask the people around me, "Has anyone seen Nick today?"

varenc 8y ago
If all information is visible and everything is well documented, it should be rare to have the situation where one person is the only one that can answer that question. This will totally still happen for remote teams, but I think it happens more in other organizations that rely on face time and verbal information exchange. I still generally agree that knowing when folks are online can be helpful and don’t see a big issue with that as long as you don’t have a culture that starts measuring people by how many hours they put in. Rather than an upfront “I will be working today from X to Y” something passive like a Slack recent activity indicator could be enough.
- superfrank 8y ago
  > If all information is visible and everything is well documented, it should be rare to have the situation where one person is the only one that can answer that question. This will totally still happen for remote teams, but I think it happens more in other organizations that rely on face time and verbal information exchange. I worked at my last job for just over 2 1/2 years and, while we had an actual office, for the first two years I was there, we also had a true "unlimited vacation/remote work" policy. It wasn't unheard of that some people would take 4-6 week vacations and others would work remote for multiple months. Documentation was great, but you can't document everything you know, so there will always be gaps. I'm a developer, so these will be dev focused, but some scenarios I can remember where one specific person was needed are: - Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) - Specialties. Most developers know this tool, but Bob is an expert. We need to do something that requires an expert. We need Bob. - Bob left an ominous, yet vague comment on my PR. I don't want to merge until I get clarification. (something like "This looks hacky. I guess it works, but we should probably change this ASAP." or "Eww")
  - hobofan 8y ago
    > Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) Not sure how well/different that works in a remote-first company, but at previous workplaces I was, we tried to have one day a week dedicated to refactoring, which might reduce that problem.
  - methyl 8y ago
    > - Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) Not sure if valid, if some legacy code was written a few years before, probably even author will have no clue what's wrong.
    - AstralStorm 8y ago
      The author might have a higher chance of figuring it out. This is playing the likelihood game though. In perfect world, the code would be tight and small enough that you wouldn't take long to understand it, and then the complex components (there are always a bunch of these) are well tested and documented. Especially rationale for design decisions or implementation quirks. Old code does not necessarily mean legacy code.

varenc 8y ago

If all information is visible and everything is well documented, it should be rare to have the situation where one person is the only one that can answer that question. This will totally still happen for remote teams, but I think it happens more in other organizations that rely on face time and verbal information exchange. I still generally agree that knowing when folks are online can be helpful and don’t see a big issue with that as long as you don’t have a culture that starts measuring people by how many hours they put in. Rather than an upfront “I will be working today from X to Y” something passive like a Slack recent activity indicator could be enough.

superfrank 8y ago
> If all information is visible and everything is well documented, it should be rare to have the situation where one person is the only one that can answer that question. This will totally still happen for remote teams, but I think it happens more in other organizations that rely on face time and verbal information exchange. I worked at my last job for just over 2 1/2 years and, while we had an actual office, for the first two years I was there, we also had a true "unlimited vacation/remote work" policy. It wasn't unheard of that some people would take 4-6 week vacations and others would work remote for multiple months. Documentation was great, but you can't document everything you know, so there will always be gaps. I'm a developer, so these will be dev focused, but some scenarios I can remember where one specific person was needed are: - Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) - Specialties. Most developers know this tool, but Bob is an expert. We need to do something that requires an expert. We need Bob. - Bob left an ominous, yet vague comment on my PR. I don't want to merge until I get clarification. (something like "This looks hacky. I guess it works, but we should probably change this ASAP." or "Eww")
- hobofan 8y ago
  > Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) Not sure how well/different that works in a remote-first company, but at previous workplaces I was, we tried to have one day a week dedicated to refactoring, which might reduce that problem.
- methyl 8y ago
  > - Legacy code. Bob was the only one around when this code was written and it hasn't been touched in years, now it's breaking and no one understands why. (In an ideal world, there wouldn't be knowledge silos like this, but there always are) Not sure if valid, if some legacy code was written a few years before, probably even author will have no clue what's wrong.
  - AstralStorm 8y ago
    The author might have a higher chance of figuring it out. This is playing the likelihood game though. In perfect world, the code would be tight and small enough that you wouldn't take long to understand it, and then the complex components (there are always a bunch of these) are well tested and documented. Especially rationale for design decisions or implementation quirks. Old code does not necessarily mean legacy code.