Nearly every marketing leader I know has, at some point, walked into a budget conversation asking for more headcount because the team feels underwater. I've done it myself. What I've learned, the hard way, is that a stretched team and an understaffed team are not the same problem, and they don't have the same fix.
The diagnostic question I ask first
Before I approve a new hire, I ask: is this team spending most of its time on work only a human can do, or is a meaningful chunk of it going to work that a better system, process, or piece of automation should be doing instead? Almost every time I've dug into a "we're understaffed" claim, I've found real capacity being lost to manual reporting, redundant approvals, or content production workflows nobody had streamlined in years.
Three systems problems that masquerade as headcount problems
Manual reporting
If someone on your team is spending hours each week pulling numbers into a spreadsheet by hand, that's not a people problem, it's a tooling and integration problem. I've reclaimed entire days of team capacity per week just by connecting systems that should have been talking to each other already.
Unclear approval chains
Content and campaigns that bounce through four rounds of unstructured feedback aren't slow because the team is too small. They're slow because nobody defined who has final say. Fixing the approval process has freed up more real output than most hires I've made.
Redundant tools with overlapping jobs
Teams accumulate software the way closets accumulate clothes. When three tools all technically do email, someone is spending time reconciling data between them instead of doing marketing. I audit the stack for exactly this before I ever sign off on more people.
When headcount actually is the answer
I'm not against hiring. When a genuine functional gap exists, a capability nobody on the team has and no system can substitute for, more headcount is the right call, and I make that case directly using the functional mapping approach I've written about before. The point isn't to avoid hiring. It's to make sure the hire solves an actual capacity problem instead of papering over a broken process that will just consume the new person's time too.
The test I use before approving any new role
If I added this person tomorrow, would the team's output meaningfully change in ninety days, or would the same bottlenecks just have one more person stuck behind them? If the honest answer is the bottleneck stays, I fix the system first. The headcount conversation, if it's still needed, gets a lot easier to win once the systems around it are actually working.