That's exactly the situation with my two teams now. Make teams of 4.
I've worked in a team of 4 (and later, of 5), and it was amazing: everything could still be communicated quickly, but you didn't feel overwhelmed if a team member was inaccessible.
My team is 3 right now and 33% time oncall is still pretty bad.
The biggest source of relief for oncall for me is that even though my "team" is 8 people. We work on larger systems. We have ~5 teams working on a single code base, so around 30 people. Its not really a microservice, but its not really a monolith (since we have many other, and larger codebases). On call is much more bearable when its once every 3-4 months than once a month.
Genuine question, Is the software not reliable? How often do you get paged?
We have 33-50% on call and noone complains because not a lot is happening.
Re:Split Your Overwhelmed Teams
by hn_go_brrrrr on Thursday November 17, 2022 @10:10PM
(#33649529)
Being on call requires being pageable and able to respond. This seriously curtails your ability to live your life. For instance, you can't decide to go hiking over the weekend on a whim, because you couldn't handle an incident, were one to occur.
Re:Split Your Overwhelmed Teams
by marcosdumay on Tuesday November 15, 2022 @11:07AM
(#33610926)
I imagine those restrictions on team size only apply to pure development tasks.
You certainly want more than one of those teams to be able to support each piece of your software. You also want to be able to move people quickly from a team to a close one, so from the training point of view you also want them to know both codebases.
3 is risky. One person has a baby and goes on leave, or gets long Covid, or is poached by a FAANG. Until a replacement can be found, the team of 3 turns into a rather overwhelmed team of 2, each spending 50% time on call. And if either of them goes on vacation to recharge, the remaining one is left with an unbearable workload.