The Hidden Runway Leak of Rework
When you’re running a service-heavy startup, "we’re slammed" is the most dangerous phrase in your building. It sounds like high demand, but often, it’s just the sound of your runway leaking.
I saw this firsthand while working at a law firm. On the surface, everything looked normal: people were busy, phones were ringing, and the team was constantly "helping" each other. We had 50 attorneys supported by 7 assistants, handling about 25 to 30 requests every day.
A third of those requests were for document formatting. When things got busy, attorneys would wait 1 to 2 hours for "quick" documents, and time-sensitive filings would get stuck in the queue. The immediate reaction from leadership? "We need to hire more people".
But the bottleneck wasn't a lack of effort. It was redo work.
"Busy" Can Still Mean Wasting Capacity
In a startup, we tend to treat "busy" as a proxy for "productive." But you can have a team working 12-hour days while your actual output slows to a crawl. The trap is simple: Rework. When work is done twice, you aren't just losing time; you’re manufacturing your own chaos. If your team is constantly cleaning up after itself, you don't have a capacity problem—you have a process problem.
The "Done" State That Wasn't
In my law firm experience, formatting complex legal documents should’ve been a simple, one-pass task. In reality, 60% of those documents were sent back by attorneys for formatting fixes.
This meant the "done" state was a myth; the first pass almost never counted, and the second (or third) pass became the operational norm. To put this in perspective, our team of 50 attorneys generated about 150 total requests per week. Because so many tasks required multiple rounds of corrections—what I call "Triple-Touching"—we were actually paying for 210 individual actions just to finalize those 150 tasks.
The "Do-Over Tax": Measuring the Leak
To get leadership to see the urgency, I stopped looking at how "busy" people felt and started looking at the math:
The Demand: 50 attorneys generated about 25–30 requests per day.
The Formatting Hit: About 10 of those (~35%) were formatting requests.
The Rework: With a 60% mistake rate, 6 requests were sent back every single day.
The Time Wasted: Every day, we lost 2 hours of billable attorney time and 12+ hours of EA capacity just on rework.
By the end of the week, 60 hours of EA capacity had vanished into preventable mistakes and the firm was losing over a full day of billable revenue every single week just to handle the workload created by our own errors.
How Rework Kills Your Momentum
This isn't just a nuisance; it's a systemic failure that hits your two most important assets: Time and Margin.
The Delay: When an assistant was stuck in a 5-hour job due to rework, other requests sat in a backlog.
The Spillover: Redo work "stole" time from other team members, who had to delay their own responsibilities to clean up unfinished tasks.
The takeaway for founders: You pay people to do work that shouldn't exist, then you pay again when deadlines slip and other work piles up.
The Reflex Hiring Trap
When a queue grows, the standard response is to hire. But hiring without measuring rework is hiring to subsidize preventable failure. Adding more people to a broken system just creates a larger, more expensive broken system.
The One-Week Rework Audit
Before you sign off on a new hire, run a one-week audit to identify your wild card tasks—those inconsistent workflows where the lack of a standard causes productivity to swing wildly from person to person.
Step 1: Pick one workflow
Choose a workflow that happens often and causes pain. In the law firm it was document formatting. In your startup it might be:
Client onboarding
Proposals and revisions
Support tickets
Scheduling and delivery
Billing and invoicing
Content production and approval
Customer implementation
Pick one. Not five. One.
Step 2: Track every item for 5 days
Track:
What the request was (short label)
Who handled it first
Whether it was sent back or needed clarification (yes/no)
How many times it changed hands
Why it was sent back (use a short list)
How long it took from start to final
You’re not trying to build a data warehouse. You’re trying to see the pattern.
Step 3: Use a short “why” list
Keep the reasons simple and consistent. Here’s a good starter list:
Missing instructions at the start
Wrong template or format used
Different expectations depending on who requested it
No clear definition of “done”
Approval delays
Tool doesn’t match the process
Quality mistake
Last-minute changes after work started
Other (use this sparingly)
The point isn’t to blame people. The point is to see what the system is causing.
Step 4: At the end of the 5 days, calculate 2 numbers
You only need two numbers to make a better decision.
How often rework happens: Out of all items, what percentage came back?
How much rework you’re carrying: How many extra touches happened because items came back?
What To Do Next
After your audit, you’ll likely see one or two reasons dominating the list.
Start there. Do not try to fix everything at once.
Here are fixes that actually reduce rework in the real world:
Standard templates for common deliverables so the starting point is already correct
A one-page standard so “good” means the same thing for everyone
An intake checklist so work arrives complete the first time
A definition of done so people stop guessing what will get rejected
Fewer handoffs so the work doesn’t bounce between people
A clear owner so someone is accountable for first-pass quality
The goal is simple: increase first-pass yield.
When first-pass yield goes up, the queue clears without adding headcount.
The Decision Rule for Hiring
Hiring is a valid decision when the system is clean and the demand still exceeds capacity. Use the decision rule below to determine if you actually need to hire an additional person:
If rework is high, fix the biggest cause first.
Measure again for a week.
If the work still outpaces capacity after rework drops, hire.
This keeps hiring tied to a clear signal instead of using headcount to absorb preventable rework.
You’re Slammed. I Can Help.
I know you are already operating at 110% capacity. You likely don’t have the "finite" time required to sit down and run a manual rework audit or map out these technical checklists yourself.
If you know your team is drowning but you’re too busy to build the life raft, let's talk. I specialize in mapping these operating systems and identifying the "rework tax" so you can recover your capacity without having to be in every thread.