3 ms·

This is a good example of the "capability trap" dynamic[0][1]: there is always short-term pressure that crowds out long-term capability building. The longer you

This is a good example of the "capability trap" dynamic[0][1]: there is always short-term pressure that crowds out long-term capability building. The longer you neglect the capability-building, the worse your capability gets, the higher the pressure. The only way out is to acknowledge that you will take the hit in a "worse before better" phase. [0] http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.pdf http://web.mit.edu/nelsonr/www/Repenning=Sterman_CMR_su01_.p... [1] https://www.systemdynamics.org/assets/conferences/2017/proceed/papers/P1325.pdf https://www.systemdynamics.org/assets/conferences/2017/proce...

cableshaft 8y ago
Could you go more into detail about the 'taking a hit in the worse before better' way of getting out of it? My department is drowning in endless toil (from the parent article) right now, and I'd like to figure out some way to get out of it besides just leaving the company like so many others have (although I might end up doing that too, but maybe I can course correct the department just a little bit before doing so).
- gtirloni 8y ago
  Dedicate some people to automate the toil away. Review past decisions that led to the adoption of systems that create a lot of toil. Avoid that in the future. Change those systems or the incentives that led to them. There's no secret or quick way, people have to make hard decisions.
- jacques_chester 8y ago
  > 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.
colordrops 8y ago
The J curve

cableshaft 8y ago

Could you go more into detail about the 'taking a hit in the worse before better' way of getting out of it? My department is drowning in endless toil (from the parent article) right now, and I'd like to figure out some way to get out of it besides just leaving the company like so many others have (although I might end up doing that too, but maybe I can course correct the department just a little bit before doing so).

gtirloni 8y ago
Dedicate some people to automate the toil away. Review past decisions that led to the adoption of systems that create a lot of toil. Avoid that in the future. Change those systems or the incentives that led to them. There's no secret or quick way, people have to make hard decisions.
jacques_chester 8y ago
> 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.

colordrops 8y ago

The J curve