4 ms·

> Minimum size of 3. 3 is risky. One person has a baby and goes on leave, or gets long Covid, or is poached by a FAANG. Until a substitute can be found, the te

> Minimum size of 3. 3 is risky. One person has a baby and goes on leave, or gets long Covid, or is poached by a FAANG. Until a substitute 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.

martin_a 4y ago
That's exactly the situation with my two teams now. Make teams of 4.
- dmitriid 4y ago
  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.
tpankaj 4y ago
My team is 3 right now and 33% time oncall is still pretty bad.
- ecshafer 4y ago
  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.
- beberlei 4y ago
  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.
  - hn_go_brrrrr 4y ago
    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.
marcosdumay 4y ago
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.

martin_a 4y ago

That's exactly the situation with my two teams now. Make teams of 4.

dmitriid 4y ago
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.

tpankaj 4y ago

My team is 3 right now and 33% time oncall is still pretty bad.

ecshafer 4y ago
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.
beberlei 4y ago
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.
- hn_go_brrrrr 4y ago
  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.

marcosdumay 4y ago

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.