Before You Hire More People, Check Your Rework Number
Chaos Cloud fight this too. Your team doesn't need more people—they need to stop doing the same work twice.
Most teams think they need more hands. What they actually need is to stop doing the same work twice.
I call it the Rework Number, and most companies have no idea what theirs is. They know their headcount. They track their PDCA cycles. They measure everything except the hidden tax that's draining productivity from every corner of their operation.
Rework is doing the same work twice because it wasn't clear the first time. It shows up as "quick fixes," new versions, extra alignment meetings, and the dreaded "Can we revisit this?" It hides in plain sight, disguised as normal work, while your team burns twice the energy to get half the results.
The Firefighting Trap
Here's what I see constantly: teams stuck in an endless cycle of redoing work. Not because people aren't capable; they are, but because they're too busy firefighting to build systems that work the first time.
Research shows this creates a vicious cycle: deadline pressure can temporarily boost speed, but it consistently decreases work quality and increases stress without improving overall performance (Capelle et al., 2023). The result? Work that ships faster but needs to be redone later. We're trading tomorrow's stability for today's urgency.
Every "quick fix" becomes tomorrow's rework. Every vague decision creates another round of revisions. Every unclear goal means starting over when someone finally asks, "Wait, what were we actually trying to accomplish?"
"We never have time to do things right, but we always have time to do them twice."
The Cascade Effect
Here's the part most people miss: rework doesn't stay contained. It creates a domino effect across your entire operation:
Unclear goals mean teams finish work only to discover they solved the wrong problem. Research on implementation intentions shows that pre-defining specific goals increases success rates significantly—yet most teams skip this step and pay for it later (Gollwitzer & Sheeran, 2006). (I've written before about the cost of starting without the end in mind—this is where that lack of clarity sends your team into endless revision cycles.)
Priority chaos means work gets started, stopped, and restarted as priorities shift daily. When Everything is Priority 1, nothing gets the sustained focus it needs to ship right the first time.
Meeting overload with unclear decisions means work continues forward, then gets redone after "one more alignment call." If your meetings don't end with clear owners and next steps, you're scheduling rework into your calendar.
Scattered systems mean the latest version lives in six different places, so teams work from outdated information. Tool overload doesn't just slow you down—it guarantees rework when people can't find the current version.
Focus destruction means teams chase new projects while leaving half-finished work that will need rework later. Shiny Object Syndrome creates a graveyard of abandoned work that eventually needs to be picked up, re-contextualized, and redone.
Each of these problems alone is manageable. Together, they create a rework machine that makes hiring feel like the only solution. But adding people to a system that generates rework just means more people doing work twice.
The Wake-Up Call
Calculating your Rework Number is simple: the percentage of tasks that had to be redone in the last two weeks. Most teams don't measure this. They should. Because rework is the hidden tax that makes everything feel harder than it needs to be. Here's how to find yours in 30 minutes:
Count it - Pull up the last two weeks of completed work. Be honest: how many tasks got redone? Not tweaked or polished; actually redone because something was wrong, unclear, or changed. Calculate: reworked items ÷ total items × 100%
Find the cause - Don't stop at the number. Ask why. Was the goal fuzzy from the start? Was there no clear owner? Did feedback arrive too late? Did priorities shift mid-work? Identify your top one or two rework triggers.
Track the pattern - This isn't a one-time audit. It's a diagnostic. Track your Rework Number for a month and you'll see exactly where your system is breaking down. Some weeks will spike—that's useful data. Find the pattern.
Installing the Sprinklers
If your team spends all day fighting fires, the solution isn't to hire more firefighters. It's to install sprinklers. Here's the prevention system that actually works:
Create a one-pager before you start- Problem, goal, owner, "done" checklist, and two dates: your D0 date (when you'll actually execute the work) and the real deadline (the latest it can be done). That's it. Two minutes of clarity upfront saves two hours of rework later.
Without this context, teams confuse deadlines with work schedules and end up redoing work when priorities shift or deadlines get misunderstood. Software engineering research has long shown that catching issues during requirements costs exponentially less than fixing them after implementation—the same principle applies to every type of work (Boehm & Basili, 2001). This isn't bureaucracy, it's insurance against redoing work because no one agreed on what "done" looked like.
Set a 24-hour feedback window - If nobody replies within 24 hours, work moves forward. Decisions don't wait in limbo. This prevents the rework that happens when work stalls, context gets lost, and teams have to start over when feedback finally arrives three weeks later.
Build a decision log with expiry dates - Create a simple shared document where you write down key decisions as they're made. Include four things: What was decided? Who decided? When? When does this need to be reviewed again? Research on team communication patterns shows that ambiguous decisions create repeated discussion cycles that drain productivity—clear documentation breaks this pattern (Pentland, 2012). This prevents the "I thought we decided X" conversations that force teams to re-discuss and redo work. The expiry date is crucial—it gives everyone permission to move forward confidently until that review point, stopping teams from constantly second-guessing settled decisions.
Track the Transformation
For the next four weeks, try tracking these two metrics:
First-pass rate: What percentage of work shipped with no rework? Push this up.
Decision time: How long does work wait for approval or feedback? Push this down.
You'll notice a shift. Teams stop asking "What should I work on?" and start asking "What are we finishing this week?" Meetings get shorter because decisions are documented. New people onboard faster because the system is visible. Most importantly: your team stops paying the rework tax.
The Reframe
Most teams don't need more people. They need systems that prevent rework from happening in the first place. Firefighting feels urgent. Building those systems feels like it can wait. But here's the truth: clarity isn't slow. Rework is slow. Before you write that job description, check your Rework Number. You might find that the capacity you need is already there, just hidden under layers of work being done twice.
🌪️ Want the tools to get started? I've built a Rework Kit with a one-pager template, decision log, and tracking sheet.
