Splitting engineering teams into defense and offense

Having a proportion of the team act as triage for issues / alerts / questions / requests is a generally good pattern that I think is pretty common - especially when aligned with an on-call rotation. I've done it a few times by having a single person in a team of 6 or 7 do it. If you're having to devote 50% of your 4-person team to this sort of work, that suggests your ratios are a bit off imo.

The thing I found most surprising about this article was this phrasing:

> We instruct half the team (2 engineers) at a given point to work on long-running tasks in 2-4 week blocks. This could be refactors, big features, etc. During this time, they don’t have to deal with any support tickets or bugs. Their only job is to focus on getting their big PR out.

This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration and I think you'd benefit from adopting a much more continuous integration and deployment process.

> This suggests that this pair of people only release 1 big PR for that whole cycle - if that's the case this is an extremely late integration

I don't think it suggests how the time block translates into PRs. It could very well be a series of PRs.

In any case, the nature of the product / features / refactorings usually dictates the minimum size of a PR.

> In any case, the nature of the product / features / refactorings usually dictates the minimum size of a PR.

Why not split the big tickets into smaller tickets which are delivered individually? There's cases where you literally can't but in my experience those are the minority or at least should be assuming a decently designed system.