Big projects are an illusion of progress until the very end, when you discover that ninety percent of the work was actually only seventy percent done. The remedy is to break every project into units of work that can each be finished, end to end, in a week or less. Small enough to ship, big enough to matter.
The illusion has a name in every team's memory: the initiative that reported green for two months and slipped in week nine. Percent-complete on a big batch is self-graded fiction, because the hard integration problems live in the unfinished remainder, invisible until contact. A finished unit, by contrast, cannot lie. It works or it does not, and someone other than its author can check. Replacing reported progress with demonstrated progress is the entire trick.
What counts as a unit
A unit of work has a clear definition of done, a single owner, and a delivery surface. "Improve onboarding" is not a unit; "ship the first-run welcome screen for new accounts" is. The test is whether the unit, when finished, produces something a user could see and a teammate could review.
The subtle rule: split vertically, not horizontally. Horizontal slices ("the database layer", "the API", "the UI") each finish without proving anything, because value only exists where they meet, and the meeting is deferred to an integration phase where all the risk was hiding. A vertical slice cuts a thin path through every layer and delivers one real, narrow capability end to end. Vertical slices are harder to define and worth the effort every time: each one retires risk instead of accumulating it.
Why this changes execution
Units make progress visible at a weekly cadence instead of a quarterly one. They make bottlenecks impossible to hide, because the unit is either finished or it is not. They give people a sense of completion every week, which compounds into much higher sustained throughput than the big-batch alternative.
The weekly cadence also changes steering. A quarter-long batch offers leadership two decision points: kickoff and the unveiling. Ten shipped units offer ten, and re-aiming after unit three (when the evidence says the plan was slightly wrong, which it always is) costs almost nothing, while discovering the same thing at the unveiling costs the quarter. Small units are how speed compounds into learning: each finished unit is a fact about reality that the next unit gets to use.
The discipline of splitting
The hardest part is splitting work into units without losing coherence. Practise this; it is the leverage point. A team that splits well moves four times faster than a team with the same skills but worse splits.
Splitting is teachable, and three moves cover most cases. Shrink the scope of who: the feature for one segment, one account tier, one geography first. Shrink the scope of what: the manual version before the automated one, the read-only view before the editor. Shrink the scope of how well: the version with known rough edges behind a flag before the polished general release. What never gets shrunk is done-ness: a unit ships finished or it is not a unit, merely a fragment with optimism attached. When a unit will not compress below two weeks, that is not a failed split; it is the work telling you where the genuinely hard part lives, which is exactly the information a plan is for.