[sourceless]

My reading was that there were two paths the author highlights:

1) Increase deployment capacity (which I'm reading as frequency, and I fully agree with)

2) Increase change capacity per deployment by making it less likely that a set of changes will fail through tests, monitoring, structural, and team changes

#2 is very much geared to "ship more changes in one deployment" which is where my disagreement lies. I think you should still do all those things, but that increasing the size of the bundle is explicitly an anti-goal.

I think you're better off, as a rule of thumb, making fewer changes per deployment if you want to reduce risk.

But -- that is my particular reading of it.

[sciurus]

My reading is that the author posits there is a fixed amount of change that can be safely made in a single deployment. The solution is to make it possible to deploy more frequently. This is hard, so organizations will often instead introduce overhead that slows down changes. Engineers might be tempted to blame the overhead and try to eliminate it, but that won't be successful and may even backfire. They need to tackle the underlying issue of deployment capacity instead.