Put an Interruption Budget on Engineering Teams
Engineering leaders often plan capacity as if teams spend every week executing roadmap work. The plan accounts for features, migrations, and technical debt, but treats interruptions as random noise. They are not random. Production support, security requests, dependency upgrades, access issues, and urgent questions create a recurring demand on engineering capacity. When that demand remains invisible, teams appear slow and commitments become unreliable. Measure the demand before fixing it An interruption budget makes this work explicit. It is not a target for how many disruptions a team should tolerate. It is a planning mechanism that shows how much capacity is being consumed outside the intended backlog. Start with lightweight categories rather than detailed time tracking: Production incidents and support Security and compliance requests Developer environment or platform issues Unplanned dependency and infrastructure work Cross-team assistance Review the pattern every few we...