Why Busy Teams Still Fall Behind
The Wrong Diagnosis
One of the easiest mistakes an operator can make is hearing "We’re slammed" and treating that sentence like a diagnosis. In practice, that phrase bundles together several different problems: real demand, work that sits and waits, work that comes back for fixes, and work that keeps bouncing between people because the flow was never clearly designed. These problems all produce stress and backlogs, but only one of them is actually solved by adding more people.
I learned this lesson in a law office where the support team appeared critically overloaded. From the outside, the office looked like it was underwater. People were busy, requests kept piling up, and the natural conclusion was that the team needed more staff to keep pace. However, once I looked at the numbers behind how the work was actually moving, the diagnosis changed completely.
About 50 attorneys were generating roughly 25-30 requests per day
Around 30-35% of those requests involved formatting or reformatting legal documents
Roughly 60% of those documents were being sent back for fixes
The office was losing about 10 hours of billable time per week
The office was also losing about 60 hours of assistant capacity per week
The system was effectively burning the equivalent of 1.5 full-time EAs on preventable rework
Those numbers exposed a workflow that was paying for the same work multiple times. The office wasn't simply dealing with volume. A meaningful share of the workload was self-created. Attorneys were losing time correcting work, assistants were losing time redoing it, and another part of the office was being forced to absorb the fallout. That's a very different problem from “we need more people.”
Busy Isn't the Same as Being at Capacity
When people say a team is at capacity, they usually mean the team looks stressed, work is taking too long, and everything feels heavier than it should. That description tells you something is wrong, but it doesn't tell you what kind of problem you're looking at. A team can be working at 100% effort while only producing 60% of its potential value because the rest of that energy is being sucked away by what I call the do-over tax.
The do-over tax is the time and effort a team loses when work comes back for fixes, waits in someone’s inbox, has to be re-explained in meetings, or gets pushed into another team to clean up. It is the hidden cost of a broken workflow. When this tax is high, adding more people doesn't necessarily result in more output; it often just gives a broken system more labor to consume.
Common forms of the do-over tax include:
Work that comes back for corrections.
Work that sits and waits instead of moving.
Work that has to be explained again because the handoff was weak.
Work that spills into another team’s time.
Work that gets touched more times than it should.
If the problem is genuine demand overwhelming a stable workflow, the answer may be headcount. If the problem is waste inside the workflow, the answer is different. In that case, hiring more people may relieve the pressure temporarily, but it won't fix the reason the pressure showed up in the first place.
The Patterns That Make Teams Feel Overloaded Early
Most teams don't become overloaded all at once. The feeling of being "maxed out" usually builds around a handful of repeatable patterns that occur before leadership has enough visibility to see the structural cause.
Work Enters Incomplete
A lot of workflow problems begin before the real work even starts. Requests arrive without proper files, missing context, unclear instructions, or unclear priority. Teams often start the work anyway because they don't want to be the reason things slow things down. While this feels helpful in the moment, it pushes the cost downstream. The work eventually pauses for clarification or, worse, moves forward incorrectly and comes back for repair.
When a team accepts work that isn't actually ready, it turns a preventable upstream problem into downstream waste. Time gets spent chasing missing details, reworking output, and cleaning up mistakes that never needed to happen in the first place.
Ownership Is Fuzzy
Some teams don't lack effort; they lack clear end-to-end accountability. When it's unclear who owns a task from start to finish, items tend to sit. Work stalls because no one has the authority to move it cleanly, or because every minor decision requires a conversation or a committee. This lack of ownership shows up as:
Items sit with the wrong person
Nobody clearly owns the overall flow
Decisions wait for meetings or permission
Escalation happens too late or too often
This ambiguity creates a persistent delay that leadership often mistakes for a lack of labor. The team feels buried because nothing moves cleanly, not because the people inside it are necessarily at their real limit.
Handoffs Require Meetings to Decode
A broken handoff occurs when the receiving person can't act on a task without immediate follow-up. If the next person in the chain has to ask questions just to get started, the handoff has failed. Common handoff issues look like:
Context lives in inboxes or side chats
The next person can't start without asking questions
Meetings exist mainly to explain what should've been obvious in the handoff
The workflow runs on memory rather than standardization
In this kind of environment, you see constant motion—messages flying and meetings happening—but the work itself isn't moving cleanly.
What the Law Office Numbers Were Really Revealing
I brought up the law office example because it makes the difference between symptoms and structure easy to see. Our support team was under pressure, but the pressure wasn't coming from pure demand alone. The workflow itself was generating a large share of the burden.
Rigid Ownership Trapped Capacity
Each EA supported assigned attorneys, which meant one assistant could be overwhelmed while another still had room. The system trapped capacity inside fixed relationships instead of allowing work to move where capacity actually existed. That kind of design creates backlog that looks like a staffing problem even when part of the issue is simply that capacity can't move.
Skill Gaps Drove Rework
Document formatting was technical work, not generic admin work, and output quality varied too much by person. Some assistants could handle it well. Others struggled badly enough that the same document might go through several cycles before it was acceptable. That made the system unstable because the quality of the output depended too heavily on who happened to receive the task rather than on a repeatable standard.
The Queue Was Invisible
Quick favors, side chats, and inbox work had become part of the real process, which meant leadership couldn't see what was open, what was stuck, or where the backlog truly lived. Hidden work is dangerous because it distorts diagnosis. A team can look overloaded when part of the problem is that no one has a clean, shared view of the queue. Invisible work also makes it harder to intervene early because the delay is often discovered only after the miss becomes expensive.
One Broken Workflow Started Stealing Time From Another Team
Late-shift admins were spending much of their time finishing EA work, which meant the damage was no longer contained inside one workflow. It had started consuming another team’s capacity too. That's one of the clearest signs that a system problem is in play. When one broken process starts draining time from another team, the issue is no longer local. The office is now paying twice for the same design failure.
Taken together, those patterns changed the diagnosis. The office wasn't just short on labor. It was paying for the same work multiple times and spreading the fallout across teams.
DMAIC: A Structured Way to Diagnose Before You Hire
Once you see the office is paying for the same work multiple times, the real question becomes how to diagnose the problem without falling back on guesswork. That's where Lean Six Sigma becomes useful, specifically DMAIC, which stands for Define, Measure, Analyze, Improve, and Control. It's useful here because it gives operators a structured way to separate a real capacity constraint from self-created drag. Instead of guessing, the team defines the problem clearly, measures what the work is actually doing, identifies the main sources of delay and rework, tests a targeted fix, and then builds a way to keep the improvement from fading.
Define
Define is where you stop describing the pain vaguely and name the actual problem you are trying to solve. “The team is slammed” isn't a useful problem statement because it tells you how people feel, not what's failing. A better problem statement names the output that is too slow, too messy, or too unreliable. In the law office, the real issue was that attorneys were waiting one to two hours for supposedly quick documents and that time-sensitive work was getting delayed. Once the problem is stated that way, the team has something specific to investigate and improve.
Measure
Measure is where you stop relying on impressions and look at what the work is actually doing. Instead of arguing over whether the team feels overwhelmed, you look at the last 10 items that moved through the workflow and separate active work time from wait time. Questions worth asking include:
How long did each item spend being actively worked on?
How long did it sit waiting?
How many items came back for fixes?
How many times did each item get touched?
Did failures in one workflow spill into another team?
In the law office, this measurement proved that 60% of formatting work was rework and the weekly cost of that rework was swallowing both billable time and assistant capacity.
Analyze
Analyze is where you move from symptoms to causes. The point isn't to list everything that feels broken. The point is to identify the few issues doing the most damage so the team does not waste time fixing noise instead of the real constraint. For the law office, the main drivers were:
Rigid ownership (trapped capacity)
Skill variation (bad first-pass quality)
Invisible work (hard to manage backlogs)
Narrowing the diagnosis allows you to apply specific solutions rather than a general call for people to "work harder."
Improve
Improve is where you change the workflow itself instead of asking people to compensate for a bad system. Once the main causes are clear, the next move is to redesign the parts of the process creating the most drag. In the law office, the intervention focused on routing, standards, and technical support:
Pooled intake: Requests went to a queue rather than an individual
Technical routing: Formatting tasks went to the people best at them
Definition of Done checklist: A shared standard for what "finished" means
Technical training videos: Short guides to address the most common errors
These changes targeted the system directly, reducing the need for individual heroics to get work through the door.
Control
Control is where you make sure the improvement holds instead of fading after a few weeks. A fix isn't much use if the workflow drifts back into the same habits the moment attention moves elsewhere. For the attorney EAs, the controls included:
Weekly review of rejected work
Real-time updates to checklists based on new errors
Targeted training updates
Visible tracking of error rates
This ensured that improvement became part of the daily operating system rather than a one-time project.
Run a Quick Test Before You Approve Another Hire
Before approving another hire, pick one workflow and review the last 10 items that moved through it. You do not need a giant transformation project to do this. You need a fast way to tell whether the team is short on labor or whether the system is burning too much effort on repeat work.
Ask these questions:
How many times did each item get touched before it was actually done?
How much of total turnaround time was work versus waiting?
What percentage came back for fixes?
Where did one team’s failure spill into another team’s time?
Which tasks vary too much by person?
Where is work sitting in inboxes, side chats, or memory instead of a visible queue?
The answers usually tell you a lot very quickly. If the same work keeps getting reopened, rerouted, corrected, or re-explained, the team is dealing with a do-over tax. If the workflow is clean, visible, and stable and the queue still exceeds what the team can absorb, then a staffing conversation starts to make more sense.
Separate the Constraint From the Leak: What to Fix First
If this pattern feels familiar, the next move isn't assuming you need more people. It's figuring out where the workflow is leaking capacity first. In most cases, the problem shows up in 3 places: how work enters the system, how clearly it is owned, and how cleanly it moves between people or teams.
Before you approve another hire, make sure you aren't just trying to fill a bucket with a hole in the bottom. Use the guides below to see exactly how to install these controls and distinguish a true labor shortage from a system that is simply taxing the people you already have.
Download the Capacity Recovery Guides:
If your workflow is chaotic, invisible, and unowned: Start with the Execution Control Blueprint to install the basics of ownership and visibility.
If your workflow is stable but bleeding time through rework: Use The Capacity Recovery Playbook to identify delay drivers and recover trapped capacity.
If you want help diagnosing the problem directly: Reach out. I work with growth-stage teams to pinpoint where work is stalling, quantify the operational drag, and redesign the workflow so capacity stops leaking into rework, delays, and cleanup.