Yup. I always liked to have my team (been in the infra/ops/sre/devops/sysadmin areas) focussed on latency rather than throughput by having slack. Luckily we've

Yup. I always liked to have my team (been in the infra/ops/sre/devops/sysadmin areas) focussed on latency rather than throughput by having slack. Luckily we've usually been able to avoid Scrum etc, and work in a way closer to Kanban. There have been times though (like right now sigh) where we're forced into a throughput oriented mode by commitments made elsewhere out of our control. It sucks, and we end up ignoring too much of the little stuff for long enough that they end up becoming fires you need to put out (is ops debt a thing?), your tooling and automation suffer, knowledge silos build up within the team, and the throughput will end up tanking anyway. I like to use 50% allocation on "project" work as a nice rule of thumb for reactive ops oriented teams. Any higher can only be sustained for short periods without negative effects. This article resonated with me pretty deeply.