> Could you go more into detail about the 'taking a hit in the worse before better' way of getting out of it? The case studies in the first paper are worth rea

> Could you go more into detail about the 'taking a hit in the worse before better' way of getting out of it? The case studies in the first paper are worth reading, but essentially you make it clear to everyone that you are going to take a hit on your primary production output in order to restore capability: > Policy analysis showed that escaping the capability trap necessarily meant performance would deteriorate before it could improve: While continuing to repair breakdowns, the organization has to invest additional resources in planned maintenance, training and part quality, raising costs. Most importantly,increasing planned maintenance reduces uptime in the short run because operable equipment must be taken off-line for the planned maintenance to be done. Only later, as the Reinvestment loop begins to work in the virtuous direction, does the breakdown rate drop. The reason that it's called the capability trap is that nobody wants to accept things getting worse. Everyone wants the improvements to be (1) free and (2) monotonic. But once you get stuck in the trap it's (1) expensive and (2) initially backwards. You slow primary production to make improvements and all the skeptics can see is that the numbers are worse, and didn't you promise to improve it? But the way out means going backwards on the primary metrics before you can free up capacity to improve capability. And it doesn't even need skeptics to be hard. Even with all the good intentions in the world, it's very hard to avoid the temptation to prioritise your primary output over everything else. Sure, we should improve our CI/CD ... once we ship this feature. Sure, we should automate our disaster recovery ... but put out this fire first. Yes, we should create systems to manage the fleet better ... but can't let you refuse anyone's requests, we have a business to run. Yes, of course we need reserve capacity to deal with uncertainty, but don't you dare run anything less than maximum utilisation ... and also don't you dare say we're at maximum utilisation when I give you more to do.