Last week, I published an article discussing why throwing bodies at a problem doesn't always help. How, oftentimes, staffing can cause more issues than anticipated and become a wholly different pain vector for a team, and how to deal with it.
So, I thought it'd be fun to go over just how this tends to operate and have some fun with the topic by both showing how the big companies experience this but also what it looks like from within a team being mismanaged through hope and faulty thinking.
Some Corporate Fun
A good real-world example of this showed up inside Apple during the early days of MobileMe. Anyone remember THAT monstrosity?!
MobileMe was "supposed" to unify email, contacts, and calendars across devices, but under the hood it was a mess of legacy systems, unclear ownership, and fragile integrations held together with hope and duct tape.
So, when things started failing, like sync issues, outages, data inconsistencies, the instinct wasn’t “the system is fighting us”. It was to push harder. Pull in more teams, and try to stabilize it through effort.
Which, of course, made things worse.
All throwing developers at the problem did was add coordination overhead to an already brittle platform.
It wasn’t until Apple scrapped the whole thing and rebuilt it as iCloud that things actually improved. Same company. Same level of talent.
The difference wasn’t headcount. It was removing the friction baked into the system itself.
A similar pattern showed up at Google with its messaging platforms.
So. Many. Messaging. Platforms...
Over the years, Google launched and maintained a rotating cast of products: Google Talk, Hangouts, Allo, Duo, each with overlapping functionality and shifting direction. They just couldn't get their shit together and reconcile a solid philosophy. From the outside (and, let's be honest, probably from the inside too), it looked like a resourcing problem.
“How does a company with that many engineers not get messaging right?”
But internally, the issue was fragmentation with multiple teams, competing priorities, unclear long-term ownership, and platforms that didn’t cleanly align.
Adding more engineers didn’t fix it; it just created more parallel efforts and more coordination overhead.
It wasn’t until Google began consolidating its approach (folding efforts into things like Chat and streamlining direction) that things started to feel more coherent.
The problem wasn’t a lack of talent: it was too many teams navigating a system that didn’t make sense as a whole.
You can see the same thing play out at Microsoft with web browsers before Microsoft Edge came along (which they decided to use Google's Chromium for, ironically enough).
Internet Explorer struggled. Hard.
The team wasn’t lacking engineers; it's fucking MICROSOFT, they had plenty of coders on payroll. But making meaningful changes was slow and risky because everything was tightly coupled and hard to reason about.
Microsoft has a LONG history of backwards compatibility, which is great for end users but an absolutely nightmare for developers.
So, adding more people didn’t untangle that complexity; it just meant more developers working around the same constraints.
Eventually, Microsoft made the call to rebuild on Chromium, effectively stepping out of the friction-heavy system they’d accumulated. Same company, same level of talent, but once the underlying platform made sense again, progress stopped feeling like a grind.
Let's Get Practical
So, aside from failed products, what's it actually look like when a company forgoes history and breaks their stability? Pretty grim actually...
Let's say you bring in two new developers, optimistically thinking you’ll double output, and you start clearing tickets.
What really happens is senior devs stop shipping and start onboarding to teach the newbies how to get things done. Which of course means nobodies getting things done. So you're already taking steps backward.
Which, yeah, is pretty unavoidable when hiring at any time, but when in a crunch, is the absolute WORST time to onboard. Deadlines are a thing, yet PRs sit longer because everybody's distracted gearing up the mentor muscles instead of slinging code.
Which creates even more problems...
Still, you ramp up, keep moving, and now things get... creative.
New developers on an existing team have no institutional knowledge (having just started), so they lean into their learned experience, which creates their own problems.
That's where you get multiple methods to do the exact same thing. It's where you get duplicate logic just because touching core code is intimidating and, God forbid, the new kid breaks something in production... but now, instead of having a complex system, you have an inconsistently complex system, which is WAY worse.
So now you have high-friction system where bugs are events instead of the humdrum basic low-friction system where bugs are annoying.
For the business though, these types of issues start to really mess up estimates.
Asking, "How long XX takes" now becomes a guessing game mixed with wishes and prayers.
This is where padding estimates comes into play. "We just don't know due to X, Y, and Z" and THAT starts fucking with the business. Not being able to accurately estimate timelines means someone is either being underpaid or someone is being overcharged and both just make things worse. If I underestimate, then the company loses money. If I overestimate, then the client is charged more with the added bonus of an eventual revolt.
Now you have an inconsistent and tough to navigate platform.
Congrats. Ya played yourselves.
So your experienced developers do what experienced developers do when they have shitty management; they actively avoid the multilayered field full of landmines. Just isn't worth the aggravation, so everything gets harder and takes longer. Instead of fixing problems they focus on the symptoms which just compounds the problem and introduces even MORE complexity.
Not because they're lazy; because they're experienced.
So, of course, the team now tries to compensate. We get more meetings. More approvals. More "just to be safe" steps.
Which feels like control, but it's really just friction wearing a polo shirt and kakis. Everything feels harder than it should. Nothing is technically broken but everything is also slightly slower, slightly riskier, and slightly more annoying. And, over time, that slightly becomes your entire development process and experience.
So, now we repeat. You hire even more. You reorganize teams. You introduce new tooling. All valid moves in the right context but, now, it's all aimed at the wrong target.
Which is the entire punchline; at no point does anyone say, "The system is the problem", instead it's "we need more people" and "we need better planning" and "we need better processes", which is how this cycle keeps going on way longer than it should.
And that’s really the uncomfortable truth of it all.
At some point, you have to stop pretending this is a staffing problem and admit it’s a system problem. Because if your platform is slow, inconsistent, and full of landmines, adding more developers doesn’t fix it, it just increases the number of people stepping on those landmines at the same time.
More code gets written. More meetings get scheduled. More “progress” gets reported.
And somehow… everything still feels just as hard.
That’s not a people problem. That’s friction. That’s architecture. That’s years of decisions quietly stacking on top of each other until forward motion starts to feel like pushing a boulder uphill in flip-flops.
So yeah, hire when it makes sense. Grow your team. Build something real.
But if things are slowing down and your first instinct is to throw more bodies at it, it might be worth pausing for a second and asking the question nobody wants to ask:
“What if the system is the problem?”
Because until you answer that honestly, all you’re really doing is scaling the pain.