[mfonda]

As true as this is, unexpected problems happen. Kevin may be the only one that can fix it, or at least be able to fix it a lot more effectively than others. The issue might not be Kevin's fault (i.e it's really a process problem), but being able to talk to him immediately (or at least know his schedule) will go a long ways in getting the issue resolved in an acceptable time frame.

Nothing against remote work, but knowing everyone's typical working hours makes things run a lot more smoothly.

[AstralStorm]

If your process cannot revert a breaking change with a figurative snap of fingers, the process is broken. It is like driving a car with no brakes.

About the only time where I've seen this fail is if it was a publicised feature launch that was way premature.

[jpatokal]

And when it's the build server itself that's broken? No process can account for every possible edge case, and you need to have flexibility to handle the unexpected.

[vonmoltke]

At some point problems reach the "Call Kevin now, I don't care what time it is" level. Your processes should enable anyone to handle problems that are not at this level.

[IOT_Apprentice]

if the build system is broken, then no new code gets built to roll to production. Your build system has no resiliency in terms of having more than one, or ability to roll back? Do you even have version control implemented along with a mature change control process, with automation and monitoring in place?

[megaman22]

Kevin's available hours should be common knowledge, or easily findable in a system of some sort, ranging from text file to excel sheet to Exchange to massively overpriced time-tracking software.

[nounaut]

Doesn't really help to know peoples hours. If they're not overlapping with yours then you have a potentially crazy overhead on time it takes to get responses to issues that could hold up your work completely.

[organsnyder]

That's a fundamental problem of teamwork. This also happens when the coworker sitting right next to you, working the same hours, has a higher-priority task than the one you're waiting for.

[nounaut]

It absolutely does, although in my personal experience far, far more rarely. And even if that person was sitting remotely at their own hours you’ld then have to wait for them to get ”to work” and then do that higher-priority task and then get to your request so the overhead is still waaaaay bigger.

[lagadu]

And what happens when Kevin is on vacation or is sick or quits?

[mfonda]

This was in response to Practical Tip #1: "People don't have to say when they are working."

I'm arguing that this tip is harmful. I should know he was on vacation, and thus have a plan in place to handle anything that might come up while he's on vacation. If I'm completely in the dark about when he's working, things are going to be a lot more difficult.

[mellett68]

Vacation / Sick time is a bit different than needing to run errands till 10am, either shifting the working day round a bit or spreading the time out over the next days or week etc.

Doesn't hurt to check in when you're available again as a courtesy but the benefit is NOT having to get permission to do something like this up front.

If you're remote as an employee then presumably the company has process around holidays and stuff that would be followed. If you're a freelancer then part of what stops you, and your client, from being fined by HMRC (in Britain) is setting your own working hours and days.