Slack & Utilisation: Why Busy Teams Ship Slowly

Your team is at 100% capacity, every sprint is full, and leadership still asks why delivery is so slow. This talk explains the paradox with three books:

• Slack by Tom DeMarco: the human view. Without spare capacity, organisations become efficient on paper and fragile in practice.
• Thinking in Systems by Donella Meadows: the structural view. Feedback loops and incentives, not individual effort, decide the outcome.
• The Principles of Product Development Flow by Donald Reinertsen: the economic view. Queues grow exponentially with utilisation, and the cost of delay is real money.

Together they form one framework, followed by practical actions for teams (visualise WIP, set WIP limits, reduce batch size, build in slack) and for individuals.

Daniel Schmeiß · https://www.linkedin.com/in/danielschmeiss/

Transcript

1. // FIELD NOTES Slack & Utilisation Why busy teams ship slowly — and what to do about it Daniel Schmeiß linkedin.com/in/danielschmeiss
2. Have you ever wondered… → Your team is at 100% capacity → Every sprint is fully loaded → Every team member is on multiple projects Yet leadership keeps asking: “Why are we shipping so slowly?” daniel schmeiß / slack & utilisation 02/35
3. 01 Slack Tom DeMarco — the degree of freedom required to effect change daniel schmeiß / slack & utilisation 03/35
4. 01 / SLACK Slack is the degree of freedom required to effect change. — Tom DeMarco daniel schmeiß / slack & utilisation 04/35
5. 01 / SLACK What is slack? → Not laziness. Not wasted capacity. → The breathing room that lets a system respond, adapt and improve → Without it, organisations turn inflexible — efficient on paper, fragile in practice daniel schmeiß / slack & utilisation 05/35
6. 01 / SLACK The efficiency trap ON THE HIGHWAY 70% CAPACITY 100% CAPACITY Traffic Flows smoothly Gridlocked Merging Easy, room to manoeuvre Every lane blocked Incidents Absorbed by the system One problem stops everything A highway at 100% capacity isn’t flowing faster — it’s stuck. Your team works the same way. daniel schmeiß / slack & utilisation 06/35
7. 01 / SLACK Mutually exclusive goals, zero slack Ship faster and maintain quality daniel schmeiß / slack & utilisation Take on new work and finish current work Be responsive to interruptions and focus deeply 07/35
8. 01 / SLACK People under time pressure don’t think faster. daniel schmeiß / slack & utilisation 08/35
9. 01 / SLACK The queue effect → A pull request waiting for review → A design waiting for feedback → A question waiting for an answer Everyone is “busy”, so queues grow. Work moves slower — even though people work harder. daniel schmeiß / slack & utilisation 09/35
10. 01 / SLACK Efficiency is the enemy of responsiveness. Slack is not waste — it is an investment in your organisation’s ability to respond, learn and change. daniel schmeiß / slack & utilisation 10/35
11. 02 Thinking in Systems Donella Meadows — see the structures that drive behaviour daniel schmeiß / slack & utilisation 11/35
12. 02 / THINKING IN SYSTEMS What is a system? → Elements — people, tools, codebase, skills → Interconnections — communication, processes, dependencies → Purpose — deliver value to users “A system is an interconnected set of elements that is coherently organized in a way that achieves something.” — Donella Meadows daniel schmeiß / slack & utilisation 12/35
13. 02 / THINKING IN SYSTEMS Stocks and flows New work (inflow) → Work in progress (stock) → Completed (outflow) → Stock — what accumulates: WIP, backlog, open PRs → Flow — the rate of change: throughput, velocity → The catch — in software, queues are invisible; you have to measure them to see them daniel schmeiß / slack & utilisation 13/35
14. 02 / THINKING IN SYSTEMS Feedback loops REINFORCING LOOPS BALANCING LOOPS DELAYS Amplify. Overload creates more overload. Stabilise. WIP limits pull the system back. Cause oscillation. Overhiring, then layoffs; crunch, then burnout. daniel schmeiß / slack & utilisation 14/35
15. 02 / THINKING IN SYSTEMS Policy resistance PRODUCT ENGINEERING LEADERSHIP “We need more features!” Every roadmap gap is another commitment added to the plan. “We need time for tech debt!” The interest on yesterday’s shortcuts comes due today. “We need to hit the deadline!” The date was set before the work was understood. Everyone optimises their part. Nobody optimises the whole. daniel schmeiß / slack & utilisation 15/35
16. 02 / THINKING IN SYSTEMS Resilience over efficiency → Resilient — absorbs shocks and recovers → Self-organising — learns, diversifies, evolves → Hierarchical — reduces the information any one part must handle “People often sacrifice resilience for stability, or for productivity, or for some other more immediately recognizable system property.” — Donella Meadows daniel schmeiß / slack & utilisation 16/35
17. 02 / THINKING IN SYSTEMS Behaviour emerges from structure THE COMMON INSTINCT THE SYSTEMS INSIGHT Blame the people. Swap the team. Add more process. Push harder on the individuals inside the system. Change how it’s connected — the feedback loops, the information flows, the incentives. Structure, not effort, sets the outcome. daniel schmeiß / slack & utilisation 17/35
18. 03 The Principles of Flow Donald Reinertsen — the economics that prove it daniel schmeiß / slack & utilisation 18/35
19. 03 / THE PRINCIPLES OF FLOW $30,000 A feature worth $10,000 a month, delayed by three months. That is the cost of delay — and most teams never put a figure on it. daniel schmeiß / slack & utilisation 19/35
20. 03 / THE PRINCIPLES OF FLOW Cost of delay → Every day a feature waits carries an economic cost → Most teams never quantify it — so it loses every prioritisation debate → Quantifying it turns “gut feeling” into an economic argument The value of a decision diminishes the longer it waits. daniel schmeiß / slack & utilisation 20/35
21. 03 / THE PRINCIPLES OF FLOW Push past 80% and the wait explodes. wait 10× 5× 2× 0% 50% 80% 100% utilisation → daniel schmeiß / slack & utilisation 21/35
22. 03 / THE PRINCIPLES OF FLOW Batch size matters LARGE BATCHES SMALL BATCHES Queues Long Short Feedback Delayed Fast Risk High Low Surprises Big ones at the end Small corrections along the way Small PRs get reviewed faster, frequent deploys are less risky, and splitting work accelerates delivery. daniel schmeiß / slack & utilisation 22/35
23. 03 / THE PRINCIPLES OF FLOW WIP limits → Stop asking: “Is everyone busy?” → Start asking: “How much work is waiting?” → Control the queue, not the people — whether you run Scrum or Kanban Managing queue size controls cycle time far better than managing utilisation. daniel schmeiß / slack & utilisation 23/35
24. 03 / THE PRINCIPLES OF FLOW Decentralised control CENTRALISED Problem → Escalate → Wait → Decision → Wait → Action Every loop adds queue time, and the information decays before it is used. DECENTRALISED Problem → Decision → Action The choice is made where the information already lives, so the loop closes in a single step. Fast feedback + small batches let teams decide locally — that is how you get speed and quality. daniel schmeiß / slack & utilisation 24/35
25. 03 / THE PRINCIPLES OF FLOW Decide on economics, not intuition 01 Quantify the cost of delay 02 Limit work in progress 03 Reduce batch size 04 Decentralise decisions to where the information lives daniel schmeiß / slack & utilisation 25/35
26. 04 Three Lenses, One Framework Combining the books for product and tech teams daniel schmeiß / slack & utilisation 26/35
27. 04 / THREE LENSES, ONE FRAMEWORK Three books, one problem BOOK LENS KEY INSIGHT Slack Human & organisational Efficiency creates stress and slowness Thinking in Systems Structural Feedback loops drive behaviour, not individuals Flow Economic & quantitative Queues are exponentially expensive Together they answer one question: why do busy teams ship slowly? daniel schmeiß / slack & utilisation 27/35
28. 04 / THREE LENSES, ONE FRAMEWORK The overload spiral 100% utilisation → Slack — 100% utilisation leaves no room to respond Lower throughput Queues grow Context switching Cost of delay rises → Flow — queues grow exponentially, cost of delay rises → Systems — the pressure to do more becomes a reinforcing loop Pressure to do more daniel schmeiß / slack & utilisation 28/35
29. → lens → solution 04 / THREE LENSES, ONE FRAMEWORK Problem PROBLEM SLACK SAYS SYSTEMS SAYS FLOW SAYS SOLUTION 100% utilisation Creates queues Overloads the loops Queues explode Build in slack Invisible WIP Work waits unseen Stocks pile up silently Hidden cost of delay Visualise work Large batches Long handoff delays Amplifies variability Delayed, high risk Ship smaller Central decisions Bottleneck at top Policy resistance Wait in every loop Decentralise daniel schmeiß / slack & utilisation 29/35
30. 04 / THREE LENSES, ONE FRAMEWORK For teams: practical actions 01 · VISUALISE WIP 02 · SET WIP LIMITS Boards make queues visible. Count the items in each stage — you can’t manage what you can’t see. One or two items per person, a team limit set to real capacity, a cap per column. daniel schmeiß / slack & utilisation 03 · REDUCE BATCH SIZE Smaller PRs under ~400 lines, more frequent deploys, feature flags for incremental release. 04 · BUILD IN SLACK Protect ~20% for unplanned work, schedule improvement time, don’t fill every sprint to 100%. 30/35
31. 04 / THREE LENSES, ONE FRAMEWORK For individuals: practical actions 01 · BLOCK FOCUS TIME 02 · LIMIT PERSONAL WIP 03 · BATCH CONTEXT SWITCHES 04 · MAKE YOUR QUEUE VISIBLE Protect two-to-fourhour deep-work blocks. Respect the maker’s schedule against the manager’s. One or two things at a time; finish before starting. Every “yes” is a “no” to finishing. Group meetings on set days, check messages at intervals, default to asynchronous. Know what’s waiting for you, and set clear expectations with the people waiting on you. daniel schmeiß / slack & utilisation 31/35
32. 04 / THREE LENSES, ONE FRAMEWORK Slack is not laziness. It is the degree of freedom required to effect change — an investment in your team’s ability to respond, learn and improve. daniel schmeiß / slack & utilisation 32/35
33. 04 / THREE LENSES, ONE FRAMEWORK People often sacrifice resilience for stability, or for productivity, or for some other more immediately recognizable system property. — Donella Meadows daniel schmeiß / slack & utilisation 33/35
34. 04 / THREE LENSES, ONE FRAMEWORK Go deeper THE QUICKEST READ THE MOST MIND-BENDING THE MOST COMPREHENSIVE Slack Thinking in Systems Tom DeMarco Donella H. Meadows The Principles of Product Development Flow Why efficiency is the enemy of responsiveness. See the structures that drive behaviour. Donald G. Reinertsen The economics of queues, batches and WIP. daniel schmeiß / slack & utilisation 34/35
35. // THE END Thank you. Slack is not laziness — it is the freedom to change. Daniel Schmeiß linkedin.com/in/danielschmeiss