“Where’s will?” “I don’t know, our manifesto says nobody gets to know when he’s working.” “Well he broke the site.” “That’s his right as a sovereign citizen.” The end.
The team broke the site.
Nothing against remote work, but knowing everyone's typical working hours makes things run a lot more smoothly.
About the only time where I've seen this fail is if it was a publicised feature launch that was way premature.
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.
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.
"Oh, but if you ask in a public Slack channel, someone else will answer!", is the inevitable response from someone here on HN. Unfortunately, that is not always the case for a multitude of reasons.
Whenever I've worked remotely, I've always clocked in and out on slack, either through posting in a channel or sending a DM, or by using statuses. That way people can know that I've gone for lunch and will be incommunicado for the next hour.
It's the same as working in a physical office, if you're out of office, your colleagues should know how long for.
After all in remote work productivity is measured about communication, issues , commits and pull requests done.
What you lose in having a fairly rigid schedule, you more than gain back by not having to carry around that “always on” feeling.
I agree with you (and OP) that there has to be some visibility into what work is going to be done when, and there are lots of ways to solve it, that said, I'm sympathetic to the notion that "I don't care how or when you work, as long as the work gets done." I'm a big fan of measuring developers more by the velocity of their Jira queues and commit history than how often they're available to be bothered with non-coding stuff.
Sure, have core hours, and make them known.
If I know someone won't be "at" work for the next 20 hours (part time, different timezone) I can factor that into how the teamwork will... Work.
Is something on fire, and only a single person can put it out? A) that's sad B) sometimes happens anyway (and then you can try and fix A after the fire is out) C) depending on what's on fire, contracts etc - you can always call and wake someone up.
But mostly it's just nice to know people's schedules - so one can plan work.
Maybe there's some pair programming to be done (via shared screen session or whatever) - obviously try and schedule that when both parties are available...
It's really not that different to chasing after a manager that's busy with meetings or a co-worker who's part time out of the office doing on-site consulting work.
Even in a shared office, developers need to plan "deep" time when they have time to focus - or nothing will get done due interruptions.
Just because someone is sitting right there does not mean they're "free" for a chat. They could be deep in the debugger chasing a bug.
If that's the case, I hope I don't own any stock of it, as you're a single injury away from disaster.
This comment hits the nail on the head [0]. Everyone's butt is on the line. It should never be one person's fault that the website was taken down. If one person has the power to damage your business and only they can repair the error, then you have a process problem.