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.

That's also been my experience. It's part time work for a single on call engineer on a team of 6-8. If it's their full time work for a given sprint then we have an urgent retro item to discuss around bug rates, code quality and so on.

> 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.

> This suggests that this pair of people only release 1 big PR for that whole cycle

I think that's a too-literal reading of the text.

The way I took it, it was meant to be more of a generalization.

Yes, sometimes it really does take weeks before one can get an initial PR out on a feature, especially when working on something that is new and complex, and especially if it requires some upfront system design and/or requirements gathering.

But other times, surely, one also has the ability to pump out small PRs on a more continuous basis, when the work is more straightforward. I don't think the two possibilities are mutually exclusive.

> 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.

> Why not split the big tickets into smaller tickets which are delivered individually?

Because it is already the smallest increment you can make. Or because splitting it further would add a lot of overhead.

> There's cases where you literally can't but in my experience those are the minority

I think in this sentence, there's a hidden assumption that most projects look like your project(s). That's likely false.

> I think in this sentence, there's a hidden assumption that most projects look like your project(s). That's likely false.

You left out the part of that quote where I explained my assumption very clearly: A decently designed system.

In my experience if you cannot split tasks into <1 week the vast majority of the time then your code has massive land mines in it. The design may be too inter-connected, too many assumptions baked too deeply, not enough tests, or various other issues. You should address those landmines before you step on them rather than perpetually trying to walk around them. Then splitting projects down becomes much much easier.

> You left out the part of that quote where I explained my assumption very clearly: A decently designed system.

That's one possible reason. Sometimes software is designed badly from the ground up, sometimes it accumulates a lot of accidental complexity over years or decades. Solving that problem is usually out of your control in those cases, and only sometimes there's a business driver to fix it.

But there are many other cases. You have software with millions of lines of code, decades of commit history. Even if the design is reasonable, there will be a significant amount of both accidental and essential complexity - from certain size/age you simply won't find any pristine, perfectly clean project. Implementing a relatively simple feature might mean you will need to learn the interacting features you've never dealt with so far, study documentation, talk to people you've never met (no one has a complete understanding either). Your acceptance testing suite runs for 10 hours on a cluster of machines, and you might need several iterations to get them right. You have projects where the trade-off between velocity and tolerance for risk is different from yours, and the processes designed around it are more strict and formal than you're used to.

I thought that at first, but the article literally says "getting their big PR out".

Might be quick nice-to-have features too (not only bugs)

Yeah, but again you might be being too literal. You could get a half dozen "big PRs" out in a month or so, but you'd still want to be able to just focus on "getting your (current) big PR out", you know?

The important part is that you're not interrupted during your large-scale tasks, not the absolute length of those tasks.

Ticket can have multiple smaller PRs.

Lots of time it is true that ticket == pr but it is not the law.

It sometimes makes sense to separate subtasks under a ticket but that is only if it makes sense in business context.

> extremely late integration

That's only late if there are other big changes going in at the same time. The vast majority of operational/ticketing issues have few code changes.

I'm glad I had the experience of working on a literal waterfall software project in my life (e.g. plan out the next 2 years first, then we "execute" according to a very detailed plan that entire time). Huge patches were common in this workflow, and only caused chaos when many people were working in the same directory/area. Otherwise it was usually easier on testing/integration - only 1 patch to test.

And also you have to backport all the changes that have been made on the main branch. Especially for upgrading or stack switching tasks.

A PR that moves the needle is worth 2-4 weeks or more. Small improvements or fixes can be handled by the team on the defense rotation.

That's fair: even if their team has a problem with PR size, this doesn't have all that much to do with the pattern the article describes.