When a team has to redo work they've already done, the instinct is to look for a people problem. Someone wasn't careful enough. Someone didn't pay attention. Someone should have asked better questions.
This is almost never the real cause.
Rework is usually a work-design problem — specifically, a problem of when and how decisions were made, not a problem of how diligently they were executed. This is not a blame-the-designers argument. "Design failure" here means the system of work was designed badly: uncertainty was left too late, interfaces were stabilized too early, or feedback arrived after the cost of change had already risen.
Rework and the Cost of Delay
Donald Reinertsen's treatment of rework cost in Principles of Product Development Flow distinguishes between the cost of detecting a defect (finding it in review) and the cost of fixing it (actually correcting it). The key insight: the cost of fixing a problem grows exponentially as the work progresses.
A specification problem found in review costs a few hours to fix. The same problem found after the feature has been built, tested, and deployed costs days or weeks — and has consumed engineering time that now has to be redone.
This is why "find it fast" is a quality principle, not just a speed principle. The fastest teams aren't the ones that avoid rework — that's unrealistic. They're the ones that find problems as early as possible, when the cost to fix them is still low.
Dan North's concept of deliberate discovery is relevant here: the goal is to structure work so that uncertainty is resolved as early as possible, not deferred until it's expensive to address.
How to Reduce Rework Without Slowing Down
Resolve uncertainty before you commit. The biggest source of rework is building before the design is stable. This sounds like "move slower," but it's actually the opposite: stabilizing the design first, even if it takes more upfront time, almost always reduces total cycle time because the downstream rework is eliminated.
Involve the reviewer before the work is "done." Don't wait until the feature is fully built to show it. Show it in draft form, at 50%, when corrections are cheap. This is the core of continuous review versus stage-gate review.
Write specs that are falsifiable. "The checkout experience should be better" is not a spec — it's a direction. A spec is falsifiable: "the checkout flow should complete in three taps or fewer from the cart view." If you can't falsify it, you don't know when it's done. When you don't know when it's done, you find out it's not done after you've already shipped it.
Treat interface changes as expensive. The cost of reworking an API contract after implementation has started is not linear — it's high. Build awareness of this cost into the upfront design process so that interfaces are stabilized before they're depended on.
Post-mortems on rework, not just failures. When rework happens, trace it back to the root cause — not "what went wrong" but "where did the decision that caused this get made, and was that the right time and place for that decision?" The answers are usually uncomfortable but diagnostic.
