This is my personal summary of the book Making Work Visible: Exposing Time Theft to Optimize Work & Flow. It’s a recap to jog my memory, and may not be useful without reading the book. The book is short and to the point and well worth a read.


Modern-day work involves never-ending lists of requests, with bad processes resulting in multi-tasking and over-committing with relatively little progress and constant stress.

We need to stop saying yes to everything, and ensure that we are only working on the most important things at the time, using a workflow system that:

  1. Makes work visible
  2. Limits work in progress (WIP)
  3. Measures and manages the flow of work
  4. Prioritises effectively
  5. Adjusts based on learnings from feedback and metrics

Part 1 - The Five Thieves of Time

The book introduces the “five thieves of time” that prevent you from getting work done:

1.1 Too much Work In Progress (WIP)

  • Too much WIP can delay delivery, increase cosrs, decrease quality, confuse priorities, and lower morale.
  • WIP is a leading indicator of cycle time - the more items that are worked on, the higher the likelihood of dependencies and interruptions creeping in.
  • More context switching means more time lost focusing on the new task .
  • We need to learn to say no to requests when our schedules are full - these requests effectively jump the queue.

1.2 Unknown dependencies

  • Every dependency added doubles the chance of failing delivery.
  • Smaller teams are able to move faster than big teams due to inner dependencies - but breaking teams up one also needs to be careful about creating intra-team dependencies (individual team performance may be detrimental to company performance).
  • Architecture, expertise and activities on hold are common dependencies.
  • Reduce dependencies to save time and money.

1.3 Unplanned work

  • Adds unpredictability to the system.
  • Higher performing companies tend to spend more time on planned work than lower performing companies.
  • Steals time away from planned works and delays planned projects.
  • Plan for unplanned work by reserving capacity for it when it arrives.

1.4 Conflicting priorities

  • There should only be one most important thing!
  • Conflicting priorities leads to too much WIP, which leads to longer cycle times.
  • Your are competing for the same people and resources.

1.5 Neglected work (partially completed work on the bench)

  • Aging software is much like an older car that needs regular oil changes and tune-ups to keep it functioning.
  • It is often technical debt that is neglected, as short-term thinking prioritises new features over important maintenance (revenue-generating work rather than revenue-protection work).
  • “Zombie” projects (low-value projects that are not proactively being worked on) should be killed! Get the important work done, and resurrect these later if they become important - don’t flog the dead horse.
  • If not dealt with, neglected work will become an emergency.

Part 2 - How to Expose Time Theft to Optimise Workflow

2.1. Make Work Visible

  • Two-thirds of the population are visual-spatial learners (as opposed to audio-sequential learners), thinking in pictures rather than words.
  • Making work visible improves our work because the human brain is designed to find patterns and structures in what it sees.
  • Seeing work on a visual map can highlight business pain points and other information.
  • Use visual systems like kanban to make work visible.

2.2 Dealing with too much WIP

  • You know you have too much WIP when
    • context switching is common
    • new tasks start before old ones are finished
    • work gets neglected for ages
  • Too much WIP magnifies all the thieves of time, upping the damage of them all.
  • Horizontal swimlanes on a kanban board can help put work into different categories (e.g. Expedite, business requests, teamwork, etc.) - this can add extra visibility and also help set up WIP limits.
  • Limits should be assigned to all swimlanes and to WIP in general.
  • WIP limits create tension in the system - they enforce constraints that enable people to complete work and foster conversation about priorities.
  • Categorising work by who requested it can be beneficial - it brings visibility for internal, external, and leadership stakeholders.
  • Use pictures, colours, writing, symbols, acronyms - whatever conveys information quickly in a unified language.

2.3 Expose Dependencies

While small teams can move fast, dependencies can impact them and slow them down. Consider:

  • Specialist dependencies
  • Architectural dependencies
  • Team dependencies (if your success is dependent on another team who has a long backlog, what then?)
  • Domain knowledge dependencies
  • The more teams, the higher the chance of dependencies between them.
  • Projects themselves create dependencies if you transition project teams off them too quickly - coming back to help fix issues when you have moved onto a new project results in context switching and dependencies
  • It is better to organise teams around products than projects, and keep the team consistently working on that product (no set up and organisation cost of establishing the team).

2.4 Unplanned Work

  • You need to plan for unplanned work - it will always exist.
  • Use metrics to track the ratio of unplanned work, and then assign resource accordingly.

2.5 Prioritise (x3)

  • Beware the lack of good rules for prioritisation - when everything is Priority 1, nothing is priority 1!
  • Making priority policies visible is vital - it drives the right conversations for delivering ideal outcomes.
  • It is not unusual for wait times to be more than 80% of the total time - organisations are often blind to the issue of queues, and focus on resource efficiency instead of applying systems thinking to improve efficiency of the whole system, end to end. Remove impediments before adding resource!
  • Many ways to prioritise
    • Cost of Delay (CoD)
    • First In First Out (FIFO)
    • Highest Paid Person’s Opinion (HIPPO)
    • Weighted Shortest Job First (WSJF)
  • Cost of Delay (CoD) is a good way to prirotise. Value and time are two constantly changing variables. CoD asks what value is lost by the delay of something? How much will we lose if we deliver this feature 12 months later?
  • People take on more WIP when they are unclear on priorities.
  • It’s important to note that bringing new work into the folder competes with other projects, increasing their cost of their delay.

2.6 Multitasking and Neglected Work

  • Multitasking is an effective way to get less done - your are likely to do each of them as effectively and sometimes you won’t finish them at all.
  • Neglected work is another term for partially completed work. Consider a partially completed bridge - it is already expensive but provides zero value until it is finished. This needs to be constantly reviewed, and decisions must be made to complete, park, or discard. Neglected work is not a priority, but it still consumes some mental budget. Purge low-value projects.
  • Important work that is delayed becomes urgent, unplanned work!

Part 3 - Metrics, Feedback and Circumstances


  • Lack of visible data in IT makes us blind to problems because we don’t have anything to tell us how we are actually doing.
  • Some of the best metrics that show actual progress (or lack thereof) are lead time, cycle time, WIP and aging reports.
  • Flow time is a measure of how long something took to do from beginning to end.
  • Leave unallocated capacity for you and your team - we don’t let our servers get to 100% capacity, so let’s not do that to ourselves.
  • Keep your deliverables small and regular
    • Focusing on efficiency produces better cost accounting results for large batch size projects, such as manufacturing commercial airplane engines or publishing books. In knowledge work, howver, problems with coordination costs grow nonlinearly with batch size. Old school management assumptions about economy of scale do not apply to knowledge work problems such as software development.
    • Small batches have an even greater advantage in software development because code is hard to see and spoils quickly if not integrated into production.
    • Look for optimal batch size to help you acheive efficiency while keeping transaction costs down
  • Delays are common; use metrics, particularly flow metrics, to help you make good decisions on priroties, WIP limits, and capacity utilisation.

Operations Review

  • Operations reviews are an opportunity to present objective metrics that can form a foundation for improvement.
  • Use time-boxing to keep operations reviews and speakers from running long.
  • Good metrics for operations reviews include throughput, flow time, and time theft along with with issues and blocked items.
  • Track metrics over time so that you can see what improvements have been made or still need to be made.


  • Using a board to show the status of work allows stand-up time to be spent discussing problems and uncovering visible work.
  • Holding stand-ups at a regular cadence at the same location reduces uncertainty.

Final Points

  • Don’t exclude times when people aren’t “supposed” to be working from metrics or the metrics will be skewed.
  • Look for alternatives to ineffective accounting methods. Just because they are “the way things have always been done” doesn’t mean they represent the only (or best) way to do them.
  • Consider replacing Gantt charts with queues.
  • Simplify meeting tools whenever possible.
  • Make kanban boards visually appealing to engage viewers.
  • Best practices have their place, particularly when it comes to simple routine tasks, but it’s often a better idea to conduct your own experiments to discover what truly works for your situation and organisation.