Week 39 Day 6: What Your Team Accomplishes When They Stop Trying to Do Everything

A team working on three priorities with full focus will finish all three faster than a team working on three priorities while also juggling four others. The math from Day 1 explains why: context-switching wastes 20-60% of capacity depending on how many items are in flight. Cutting priorities does not mean doing less. It means finishing more.

Here is what happens when a team cuts from many priorities to few -- a pattern I have seen play out three times with my own teams and observed in half a dozen teams I have coached. Phase one -- the uncomfortable week: the team cuts from 7 active workstreams to 3. Stakeholders whose projects are paused are unhappy. The team feels anxious because they have 'stopped working on important things.' This anxiety is normal and it passes. Phase two -- the focus week: by week two, something shifts. Engineers who were spending 30 minutes per day re-contextualizing between projects now sit down and write code for 4-6 continuous hours. Pull requests that used to take 3 days to complete take 1 day. Code review quality improves because reviewers are not splitting attention across five projects. Phase three -- the momentum quarter: by week four, the first of the three priorities is complete. Completely done. Shipped. This is remarkable because under the old system, nothing was ever completely done -- everything was perpetually 'in progress.' The completion creates visible momentum. The team sees that their work is producing finished results instead of incremental progress across seven fronts. Morale improves. Phase four -- the throughput surprise: by the end of the quarter, the three focused priorities are complete. The team then picks up the next three priorities from the backlog, and often completes one or two of those in the remaining time. Total items completed: 4-5, compared to the previous quarter's 2-3 (with 7 items in progress). The team completed more items with fewer items in flight. The math is counterintuitive but consistent: focused teams finish more than scattered teams. The throughput increase comes entirely from eliminating waste (context-switching, decision overhead, partial work inventories) and is free -- no additional headcount, no additional hours, no additional tools. Just fewer priorities.

The throughput paradox is predicted by Little's Law (Little, 1961) from queueing theory, which mathematically proves that reducing work-in-progress (WIP) reduces cycle time proportionally, assuming constant throughput. When context-switching overhead is included as variable throughput loss, the effect is multiplicative: reducing WIP both reduces cycle time (Little's Law) and increases throughput (by reducing context-switching waste), producing the counterintuitive result that doing fewer things simultaneously produces more total output. Empirical validation comes from Anderson (2010), who documented multiple case studies of software teams implementing WIP limits: one team at Corbis reduced WIP from 28 items to 14 and saw cycle time decrease by 75% with no decrease in throughput. Another team that reduced WIP from an average of 5 items per person to 2 items per person saw throughput increase by 33%. The four-phase pattern (discomfort, focus, momentum, throughput surprise) is consistent with what Tuckman (1965) calls the 'forming-storming-norming-performing' model applied to process change: the initial resistance (storming) gives way to new norms (the focused work pattern) and eventually to high performance (the throughput increase). Research by Reinertsen (2009) on 'the principles of product development flow' provides the theoretical foundation for why WIP reduction is the highest-leverage process improvement available to knowledge work teams: unlike other improvements that require skill development or tool investment, WIP reduction is a pure management decision that immediately reduces queuing delay, which is typically 80-90% of total cycle time in knowledge work.