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