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.
That's indeed how I wrote it, but I could have worded it better. Very much agree that the insights in The Goal go far beyond the scope of The Phoenix Project.
I think unfortunately the conclusion here is a bit backwards; de-risking deployments by improving testing and organisational properties is important, but is not the only approach that works.
The author notes that there appears to be a fixed number of changes per deployment and that it is hard to increase - I think the 'Reversie Thinkie' here (as the author puts it) is actually to decrease the number of changes per deployment.
The reason those meetings exist is because of risk! The more changes in a deployment, the higher the risk that one of them is going to introduce a bug or operational issue. By deploying small changes often, you get deliver value much sooner and fail smaller.
Combine this with techniques such as canarying and gradual rollout, and you enter a world where deployments are no longer flipping a switch and either breaking or not breaking - you get to turn outages into degradations.
This approach is corroborated by the DORA research[0], and covered well in Accelerate[1]. It also features centrally in The Phoenix Project[2] and its spiritual ancestor, The Goal[3].
Sure, a bullet the same size or smaller will 'fit' in a given barrel, but a depending on its weight and dimensions it will, at best perform equally, and at worst destroy the barrel.
But a bullet isn't the whole story; the rest of the cartridge has to fit snugly for the action of the gun to lock properly. Again, best case - the gun doesn't fire. Worst case, the action blows up.
This is a pretty simplified overview, but unfortunately the assertion above is a (pretty absurd) myth. Sorry :(
Sounds like you are being overworked. A 9-5 as an Eng Manager is achievable, but you might need to jump ship to find it.
Working late has a huge knock-on effect on your social life and ability to interact with society around you. That's probably contributing to your burnout.
If there's budget or willingness, having someone in that timezone who can perform your role for that meeting may be possible.
I'd be very wary of taking any regular work outside of your contracted hours unless there is a lot of $$$$ involved and your relationships can survive it.
You might get some mileage out of a long vacation, or agressively pruning your work hours.
Last year I taught myself a good deal of category theory, and you're right, five minutes is not really enough to learn most things - but it is enough time to start an exercise - and those five minutes often turn into something longer!
We used this to make updates to the NHS Patient Demographic Service (which stores names, addresses, contact information). The records are pretty detailed (FHIR) and there's a lot of business rules and deep nesting.
It worked really well, and our users had no problems making JSON Patch requests.
Fantastic. First time I saw something similar to this was Edwin Brady’s recent demo of Idris 2. It’s quite amazing just how much of a program can be machine-written when the types are strict enough.
I hope holes & case-splitting get into many more languages.
I don't know, some of that is at least starting to happen with Idris 2, though not in the exact way predicted: https://www.youtube.com/watch?v=mOtKD7ml0NU (Type Driven Development with Idris 2)
Short summary of linked video: when your type system is powerful enough you can restrict the set of possible implementations to the point that the compiler can make a decent guess as to what the program should be to satisfy the type signature.
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.