This is definitely true and insightful, but I think it's also important to understand the difference between global logistics and operations vs software engineering teams.
In the case of an airline, the job to be done is very very clear, but is logistically difficult and subject to all manner of physical disruption, not the least of which is you simply don't have the right people in the right cities at the right times.
With software development, the job to be done is more nebulous. Sure you have operations (on-call), but the bulk of the work is building new things, which have variable scope, and are all one-off builds. In this environment you can't even really measure efficiency in any objective way. When the MBAs try, they get subtle (or open) rebellion and Goodhart's Law slaps them down. Best case sane engineering management steps in and saves the day, worst case the elves leave middle-earth and the bean counting fantasy land develops its own self-perpetuating superstitions and mythology while the business runs its natural course.
As an engineering manager, it's always a losing argument to suggest that we need slack in the system. The reasons for this are two-fold: first, upper management never wants to hear this, we're not paying people to sit around idle. More importantly, software engineers also don't want to be bored. Fortunately writing software is not operations. There is always an unbounded list of improvements that the team could undertake at any moment. So balancing efficiency with resiliency really just means having everyone working on the most important thing at the moment, while breaking things down small enough that people can switch gears without a massive context switch, or working around huge, unwieldy in-flight migrations, and also ensuring that 90% of the time people are working less than 40 hours a week, so when crunch time is necessary they are fresh and not burnt out. Easier said than done, but still easier to manage than resilient logistics.
Hard to answer this without more context as it really depends on the personalities and viewpoints of those you're dealing with. I could see a world where it could work with very technical leadership that had high trust in you, but my gut instinct is it doesn't come off well.
Is the problem you're trying to solve that leadership doesn't feel you're responsive enough? Or is the problem that the team is being pulled in too many directions to maintain focus and momentum?
In the case of an airline, the job to be done is very very clear, but is logistically difficult and subject to all manner of physical disruption, not the least of which is you simply don't have the right people in the right cities at the right times.
With software development, the job to be done is more nebulous. Sure you have operations (on-call), but the bulk of the work is building new things, which have variable scope, and are all one-off builds. In this environment you can't even really measure efficiency in any objective way. When the MBAs try, they get subtle (or open) rebellion and Goodhart's Law slaps them down. Best case sane engineering management steps in and saves the day, worst case the elves leave middle-earth and the bean counting fantasy land develops its own self-perpetuating superstitions and mythology while the business runs its natural course.
As an engineering manager, it's always a losing argument to suggest that we need slack in the system. The reasons for this are two-fold: first, upper management never wants to hear this, we're not paying people to sit around idle. More importantly, software engineers also don't want to be bored. Fortunately writing software is not operations. There is always an unbounded list of improvements that the team could undertake at any moment. So balancing efficiency with resiliency really just means having everyone working on the most important thing at the moment, while breaking things down small enough that people can switch gears without a massive context switch, or working around huge, unwieldy in-flight migrations, and also ensuring that 90% of the time people are working less than 40 hours a week, so when crunch time is necessary they are fresh and not burnt out. Easier said than done, but still easier to manage than resilient logistics.