Slack

Slack is spare capacity — time, resources, or optionality — that is not committed to the current plan. It absorbs shock, allows reallocation when priorities change, and reduces the cost of being wrong. Systems run at 100% utilisation are brittle: any delay or failure propagates immediately. Systems with slack can absorb a missed deadline, a sick team member, or a surprise demand without breaking. The trade-off is explicit: slack costs resources in the normal case (idle time, unused capacity) and pays off when the unexpected happens. The question is how much slack is optimal — enough to be resilient, not so much that the system is lazy or wasteful.

Tom DeMarco argued in Slack (2001) that organisations that eliminate all slack lose the ability to change direction, innovate, or handle crisis. Efficiency maximisation can minimise resilience. The same applies to personal capacity: a calendar with no buffer means one overrun destroys the day; a project plan with no contingency means one slip cascades. The strategic implication: treat slack as a design choice, not waste. Name the risks you're hedging (demand spike, key person out, priority change) and hold enough slack to absorb them. Revisit when the environment changes.

Slack has a dark side: too much slack can enable procrastination (Parkinson's Law — work expands to fill time) or hide inefficiency. The discipline is to hold slack where the cost of failure is high and to use it when needed — not to fill it with low-value work by default.