Live data from Hacker News

Oncall shift should be Tuesday to Tuesday

arthur-johnston.com

1–10 of 230 posts

Re: Oncall shift should be Tuesday to Tuesday

#4
I never understood why companies didn't simply leverage 24x7 internet MSPs.

They are able to staff 24x7 by spreading the cost over multiple customers and working through the process of making your application manageable by a 3rd party is super beneficial.

Most of these companies will also do performance monitoring and analysis as well.

They see issues and optimization opportunities across multiple applications and know more than a single team who's only built one.

Re: Oncall shift should be Tuesday to Tuesday

#5
I have occasionally convinced teams to adopt both oncall and sprint cycles aligned with Tuesday [1] - the dev teams all loved it. Management was a harder sell, but by and large were happier with the extra days to communicate results/get metrics before their own Friday deadlines.

[1] also Wednesday/Thursdays. Wednesdays were my favorite in good working environments, it felt like running a successful marathon, but it was more prone to falling apart due to short-term thinking.

Re: Oncall shift should be Tuesday to Tuesday

#6
post #4

I never understood why companies didn't simply leverage 24x7 internet MSPs. They are able to staff 24x7 by spreading the cost over multiple customers and working through the process of making your application manageable by a 3rd party is super beneficial. Most of these companies will also do performance monitoring and analysis as well. They see issues and optimization opportunities across multiple applications and kn…

Are you speaking from personal experience having worked with one? What was the feedback between application management back to engineering like?

Re: Oncall shift should be Tuesday to Tuesday

#7
I’ve always been partial for Friday night through Friday night.

You start off over the weekend, when you have energy and can survive the two days alone. Ideally no Friday releases so the transition is calm, but as the writer says the batches might fail.

You spend the week fixing whatever breaks. You’re cleanly off the Monday to Monday sprint, just doing on-call/ops.

You finish Friday evening and immediately get Friday night and the weekend to recover when you need it most.

Re: Oncall shift should be Tuesday to Tuesday

#8
My team does Wednesday to Wednesday for many of the same reasons mentioned in the article, and it works great. We switch at 11am and hold a hand-off meeting at that time, and invite the whole team.

Hand-off meetings with the whole team work really well (in my opinion!) when you have a relatively small team--we have 9 FT teammates. Often someone else may have been delegated the page or bug that arose and can discuss how they handled it, or someone who wasn't involved may have insight for how to handle a situation better the next time. Since we're all going to be on rotation at least once during a quarter, it's great to know what happened in case a similar page pops up later.

Finally, we also fill out a running Doc before/during the meeting with links to the pages/bugs, along with short descriptions of how they were handled. This forms a great living memory of how to deal with incidents, and is also often the birthplace of new playbooks for handling new types of incidents.

Re: Oncall shift should be Tuesday to Tuesday

#9
post #4

I never understood why companies didn't simply leverage 24x7 internet MSPs. They are able to staff 24x7 by spreading the cost over multiple customers and working through the process of making your application manageable by a 3rd party is super beneficial. Most of these companies will also do performance monitoring and analysis as well. They see issues and optimization opportunities across multiple applications and kn…

That works well for generic IT systems and running the desktop/laptop fleets, but doesn’t work at all for running the software a company builds.

We typically split our teams, so we have ~16 split across two time zones so that our shifts are just 12 hours during the day. It works well, but it is expensive, so we support a lot of services (or a small number of very high priority services) as a result.

Post reply on HN