Why “Just Add People” Usually Makes It Worse
I saw a founder post on Reddit a few days ago that made my eye twitch. Their question was basically: “Everything’s falling apart. Should I just hire two more people to stop the bleeding?”
The founder was doing triage all day and building nothing at night. Smh you hate to see it. Support was piling up, deadlines were slipping and customers were getting just a tad bit louder.
They wanted an answer, so I gave it to them: Hiring can help. Hiring into chaos is how you turn a messy quarter into a permanently expensive company.
When your product is slipping, support is backed up, customers are getting impatient, and your team is fried, hiring feels like the cleanest move available. More hands = more output and less stress, right? Not always.
What Happens When You Hire Into A Mess
1) Ramp Time Is Slower Than You Think
A new hire isn't capacity on day one. They're a short-term drag on the people who already know how things work.
Onboarding and time-to-productivity aren’t just HR concepts. They’re throughput concepts. SHRM has written about how strong onboarding improves productivity and retention, which implies the inverse is also true: weak onboarding keeps people unproductive longer.
Founders routinely underestimate this then wonder why they hired “a great person” and nothing changed. The usual reason is simple: the company never clarified the work.
2) Coordination Tax Rises Faster Than Output
Every hire adds communication paths, handoffs, approvals, clarifications, meetings, and Slack. Headcount adds output, then it adds overhead. Harvard Business Review has documented “collaborative work” growing dramatically over time and consuming huge portions of the workweek, especially as work becomes more cross-functional. Rob Cross has also published research noting many workers spend 85% or more of their time on email, meetings, and calls in high-collaboration environments.
More people often means more coordination. More coordination often means less real output. When a project is already behind, adding people often slows it down at first because the team pays a ramp, training, and alignment bill.
3) Poor Handoffs Turn Into Real Dollars
Most “we need to hire” moments are really “we keep dropping the ball between teams” moments. SHRM has cited research showing poor communication can cost smaller companies significant amounts annually, including an example figure of $420,000 per year for a 100-employee company.
Your startup may not match that exact benchmark, but the direction is right: misalignment and rework are expensive long before you hit enterprise scale. Hiring more people into that environment just increases the number of handoffs.
The Core Mistake: Treating A Design Problem As A Staffing Problem
Most teams don’t have a headcount issue. They have one or more of these:
Unclear priorities, so work thrashes
Unclear ownership, so decisions stall
Unclear definitions, so data can’t drive action
Broken handoffs, so rework balloons
Too many tools, so execution fractures
Hiring can’t fix any of that. It can only add labor to it.
When Hiring Actually Is The Right Move
Hiring becomes the right answer when three things are true:
The work is defined and repeatable. The steps are clear enough that a new person can learn them without you narrating every decision.
Ownership exists. Someone can manage the person, review outputs, and make calls fast.
Demand still exceeds capacity after you remove obvious waste. The backlog remains after you fix the workflow and cut the rework.
Hiring before that is paying premium prices for confusion.
The Scale Test: Run This Before You Open A Req
I shared this with another founder a few months ago. I’d honestly forgotten about it after I sent it, until a few weeks later when they messaged me out of the blue to thank me. They said it was the first thing that helped them slow down, see what was actually broken, and stop defaulting to headcount. I told them to check out my other hiring article when they're ready to actually hire.......or just hire me since I've been there, done that :)
Step 1: Name The Failure In One Sentence
This step forces precision. “We’re overwhelmed” is a feeling, not a diagnosis. A one-sentence failure statement pins the problem to a specific outcome that is breaking, which makes it possible to fix without accidentally “fixing everything.” It also prevents the classic founder trap where you hire to reduce pain, then realize later you hired for the wrong problem.
Examples:
“We ship late because scope and dependencies are unclear.”
“Support is drowning because tickets aren’t triaged and routed consistently.”
“Onboarding takes too long because customer context is missing and setup is manual.”
Step 2: Map The Workflow From Trigger To Done
THIS IS THE MOST IMPORTANT STEP! I can't stress that enough. This part only works if you’re brutally literal. You’re not “sketching the process.” You’re accounting for every single step the work actually takes, from the moment it starts to the moment it’s truly finished.
That means you capture the steps people love to skip when they describe how work “should” happen:
Every handoff (Sales → CS, Support → Engineering, etc.)
Every approval
Every “quick question” in Slack
Every copy/paste between tools
Every waiting period (in someone’s inbox, in a queue, blocked on a customer)
Every rework loop (send back, fix, resend)
If a step consumes time, introduces risk, or creates delay, it belongs on the map. If it’s not on the map, it won’t get fixed, and you’ll end up hiring to babysit the gaps. Clean maps are how founders fool themselves. Real maps are how you find the bottleneck.
Practical rule: if you can’t point to where something happens in the workflow, the workflow isn’t defined.
Step 3: Measure Two Numbers
Mapping shows you where the work goes. Measuring tells you what it’s costing you and what’s actually broken. Without numbers, you can’t tell if you have a capacity problem, a priority problem, or a rework problem. You also can’t prove that your solution worked, which means the team ends up running into the same issue every two weeks.
Pick two metrics that describe the pain and track them for a week. That’s enough to see patterns.
Cycle time (start to finish): How long does it take to complete one unit of work end-to-end? This tells you if your system is slow even when people are working hard.
Rework rate (how often work gets redone): How much effort is being wasted because something was missing, wrong, or unclear? High rework usually means broken handoffs, unclear definitions, or bad intake.
Handoff count (how many times it changes owners): Every handoff is a chance for delay, misunderstanding, and dropped context. Lots of handoffs usually means fuzzy ownership or too much fragmentation across teams and tools.
Time in queue (how long it sits waiting): Work often isn’t slow because execution is slow. It’s slow because it sits in someone’s backlog waiting for a decision, an approval, or missing info.
Step 4: Assign an owner per step.
This is where most workflows fall apart. Teams love to say “we own it,” which usually means nobody owns it. When ownership is shared, decisions slow down, handoffs get sloppy, and work sits in limbo while everyone assumes someone else is driving.
Put a single name next to every step in the workflow. One person owns each step. Not a team. Not a committee. That person is responsible for making sure the step moves forward, the inputs are complete, and the output meets whatever “done” means for that step. They can delegate tasks, pull in help, and collaborate all day long, but they’re the one accountable for the outcome.
Step 5: Remove the biggest source of rework
Once you’ve mapped the workflow and measured it, the goal is not to “optimize everything.” The goal is to remove the one or two failure points creating the most repeat work, delays, and confusion. Rework is where your capacity disappears, and it’s usually caused by missing context, unclear expectations, or tools that don’t match how the work actually flows.
Common fixes that beat hiring include:
A standard intake form that forces complete context
Templates for handoffs (what must be included, always)
Explicit acceptance criteria (what “done” means)
Killing low-value work that keeps sneaking back in
Consolidating tools or integrating the ones you already pay for
Step 6: Decide on hiring with clarity
Only after you’ve stabilized the workflow do you answer the hiring question. At that point, you’ll know whether the problem was waste or true capacity. If the workflow is now stable and the bottleneck is still real, hiring becomes obvious and the job description writes itself because you can describe the lane, the inputs, the outputs, and the success metrics.
Takeaway
Hiring isn’t a strategy for fixing operational chaos. It’s usually a signal that your operating system has hit its limit and the work is leaking time through unclear ownership, broken handoffs, and nonstop rework. Adding headcount on top of that doesn’t create relief, it creates overhead. You get more conversations, more coordination, more training load, and more places for work to stall, while the original bottleneck stays alive.
The founder move is resisting the reflex to “add bodies” long enough to redesign the workflow. That’s where leverage comes from. When the system is clear, hiring becomes an accelerant instead of a Band-Aid. When the system is messy, hiring is how you lock in permanent cost and keep living in the same fire.
If you’re in that moment right now and you’re not sure whether the answer is hire, fix, or cut, reach out. I’ll help you diagnose the bottleneck and map the fastest path to stability, without defaulting to headcount. (I LOVE mapping processes)