You Don’t Need More Developers. You Need Less… Whatever This Is.

It’s one of those timeless software tropes. So timeless in fact, I've been holding off writing about this purely because of how tired a topic this is. But, recently, I found myself telling a potential client they didn't have a staffing issue. Hiring me wouldn't help solve their problems. They had something else entirely.

It's never an easy conversation but it is one that I've had more than a few times. Look, I get it. From the outside, it feels obvious:

More work -> more developers -> faster output.

Clean. Logical. Spreadsheet friendly.

Also… sometimes, super duper wrong.

At some point, every team hits this moment. Things slow down. Not catastrophically, just enough to be annoying. Features that used to take a day now take three days. Bugs hang around your neck longer than they should. “Quick changes” suddenly involve Slack and Teams threads, context switching, environment toggling, and a little bit of quiet dread.

And eventually someone says it:

“We just need more developers.”

Which sounds reasonable. Except most of the time, the problem isn’t a lack of people. It’s friction.

Friction is sneaky. There’s no dashboard for it. No alert. No ticket titled “platform is quietly fighting us again.” It shows up in behavior. A developer opens a file… and pauses. A bug fix turns into a mini archaeology expedition. Someone asks, “who owns this?” and nobody’s quite sure. A simple feature gets over-scoped because nobody trusts the unknowns.

Individually? Whatever. Normal day. Collectively? Everything slows down just enough to matter.

So naturally, the response is to scale the team. And this is where things go pear shaped. Because adding developers to a high-friction system doesn’t remove the friction. It distributes it.

New developers show up and do exactly what you’d expect smart developers to do:

They learn the system, how it actually behaves, not how it was documented three years ago. They may read the docs (hard may) but more than likely they follow patterns, some good, some… inherited. They avoid the parts of the codebase that feel like stepping on a rake. They build abstractions to survive the ones they can’t avoid.

All completely reasonable decisions. And, none of which, reduce complexity.

Now you just have more people navigating the same maze for the moldy cheese.

Instead of progress, you get dramatically more conversations. More coordination. More opportunities for things to drift just slightly out of alignment.

The system doesn’t get simpler.

It gets louder.

And this is the part where teams start to feel a little gaslit. You hired smart people. You grew the team. Output should go up. But instead, everything feels… heavier. Slower to start. Harder to finish. Weirder to reason about.

That’s not a people problem. That’s friction scaling with headcount.

If you zoom out, the pattern becomes pretty obvious. The issue isn’t effort. It’s how hard it is to make a change safely and with some damn sanity. And that usually comes from the usual suspects (timeless trope, remember?):

1. Architecture that made sense once and then slowly… didn’t.
2. Components that are just coupled enough to be annoying.
3. Data models that no longer reflect reality (but we keep pretending they do).
4. Workflows that require touching five different areas just to change one thing.

None of this blocks development outright.

It just adds resistance. And resistance compounds like interest, except instead of money you get existential dread.

You can spot it in the little moments.

That half-second pause before touching a file. That “let’s double-check this before we ship it.” That feature estimate that quietly inflates because nobody wants to be the optimist who gets burned.

And of course:

“Let’s not touch that right now.”

Every codebase has that part.

If your system has a name for it, congratulations, you’re already deep in it.

What makes this tricky is that friction doesn’t feel like a system problem at first.

It disguises itself as:

1. a communication problem
2. a planning problem
3. a staffing problem

So teams respond the way teams do.

1. They add process.
2. They add meetings.
3. They add people.

And sure, sometimes that helps. For a bit. But you can’t out-process a system that’s fundamentally hard to work with. At some point, the system wins.

This is where the conversation needs to shift.

Not:

“How do we get more output from the team?”

But:

“Why is it so hard to make changes in this system?”

That question is way less comfortable. And way more useful by orders of magnitude. Because now you start getting real answers instead of hiding from them.

1. The architecture is blurry.
2. The boundaries don’t mean what they used to.
3. Data is doing gymnastics to support use cases it was never designed for.
4. Years of “reasonable decisions” have stacked into something nobody fully understands anymore.

This is normal, by the way. This is what growth looks like when nobody has time to stop and clean up.

And this is the part nobody loves hearing: Adding more developers at this stage is like adding more cars to a traffic jam. Sure, technically more people are moving. But the traffic isn’t going anywhere.

Reducing friction looks very different. It’s not about doing more. It’s about making what you already do… easier.

Clearer boundaries so people know where things belong. Simpler workflows so changes don’t require touching half the system. Refactoring parts of the platform so the code reflects reality again, not some version of it from 2019.

Basically: making the system sensible and logical again. Intuitive, even.

And when that happens, something kind of magical (and also very predictable) occurs.

1. Developers move faster without trying to.
2. Estimates stop feeling like educated guesses.
3. Changes feel safer, which means they actually ship.

And suddenly…

The urgency to hire more developers starts to fade. Not because the team is working harder. Because the system stopped fighting them.

And to be clear, sometimes you do need more developers.

1. New product lines.
2. Real growth.
3. Actual increased demand.

That’s legit.

But if your platform is the thing slowing you down, adding more people just gives the problem more surface area.

So the next time someone says:

“We need more developers.”

Don’t disagree.

Just pause for a second and ask:

“What’s actually making this hard right now?”

Because more often than not, the answer isn’t headcount.

It’s friction.

And once you see that clearly, the path forward gets a lot more obvious. Not easier. But definitely less noisy. Less... distracting...

Which, honestly, is half the battle.