Engineering & Craft · 7 Aug 2026 · 9 min read

More Programmers, More Mess.

The project is late, so you put five more developers on it. Three months later it's later than before. The bottleneck was never typing speed. It was everything the team had to agree on first, and the shortcuts they took when they couldn't.

Heartbyte Team

Engineering & Strategy

A project is running behind. So you do the obvious thing and add people. Five more developers, starting Monday. Everyone in the room nods, because it's the same move you'd make in a factory or on a construction site. More hands, more output.

Three months later the project is further behind than it was before the five people joined. Nobody was lazy. Nobody sabotaged anything. The team just got slower as it got bigger, and most business owners never get told why.

"You didn't buy more capacity. You bought more people who now have to agree with each other before anything can ship."

You're paying for decisions, not typing

From the outside, software looks like a typing job. Pay for more fingers, get more code. But most of what a good engineer does all day is decide things.

What happens when the payment goes through but the order fails? Which of your three customer lists is the real one? Does this report show today's numbers or last night's? When a manager approves a claim and then leaves the company, who owns it now? None of that is in the spec. Somebody has to work it out, check it with someone who knows the business, and only then write the code. The typing is the last ten minutes.

So when you add a developer, you're not adding a pair of hands to a production line. You're adding another person who needs to know all those answers, and another person whose answers everyone else now needs to know.

The maths nobody shows you

Work doesn't grow with headcount. Talking does, and it grows fast. Three people have three relationships to keep in sync. Add one more and it's six. The count climbs a lot quicker than the team does.

Team size vs. lines of communication

▸ 3 people → 3 connections. Everyone knows what everyone is doing without trying.
▸ 5 people → 10 connections. Still fine, but now you need a standup.
▸ 10 people → 45 connections. Nobody can hold all of it, so people start working from memory of a meeting two weeks ago.
▸ 20 people → 190 connections. Now you hire coordinators to manage the coordination.

Add one person to a team of ten and you didn't get ten percent more capacity. You got ten new relationships that all have to stay in sync, plus a few weeks where your best engineer is explaining the system instead of building it. That cost is real and it lands immediately. The extra output shows up much later, if it shows up at all.

We've written about the delivery side of this before in why more programmers won't speed up your project. This post is about what happens next, once the talking breaks down.

When people can't talk, they guess

The meetings are not the expensive part. Guessing is.

A developer hits a question at 4pm. The person who knows the answer is in a workshop until Thursday. The ticket is due Friday. So the developer makes a sensible call and keeps moving, because that's what you'd want them to do. Multiply that by eight developers and twenty small unanswered questions a week, and you end up with a system built on a few hundred private assumptions that nobody wrote down.

You see it later as weird behaviour. One screen treats email as unique and another doesn't, so duplicate customers appear. Two teams build the same export in two different places and only one gets the tax fix. A refund reverses stock in one flow and not the other. From the outside it looks like carelessness. It's people filling in blanks on their own because asking would have cost three days.

"Every question that doesn't get answered gets guessed. And a guess doesn't stay a guess. It gets built, shipped, and paid for."

Communication is the actual job

People treat communication like a soft skill, the thing you mention in a performance review when someone is nice in meetings. On a software project it's the main constraint. The team's speed is set by how quickly a question can find its answer.

And the most expensive gaps are not between developers. They're between the developers and you. We've had projects where the code was excellent and the feature was still wrong, because nobody asked how your business actually handles a partial delivery. An engineer who understands your system perfectly and your business not at all will build you something beautiful and useless. That's the same point we made in you can't automate what you can't describe.

What good communication looks like in practice:

✓ One owner per area. Someone can answer "how does billing work" without booking a meeting with four people.
✓ Decisions written down where the work is. Not in a chat thread that scrolls away by Wednesday.
✓ A fast path to the business. Your team should be able to get a real answer from your side in hours, not next sprint.
✓ The why travels with the ticket. A developer who knows why you need the field will build the right field.

Guesses harden into technical debt

This is where the two problems meet. A guess made under deadline pressure doesn't get revisited. It gets built into the foundation, and the next thing gets built on top of it.

That's what technical debt actually is. Not messy code that offends a purist. It's the pile of decisions your team had to make without enough information, wrapped in code that now runs your business. Every duplicate customer table, every copy-pasted export, every "we'll clean this up after go-live" is a small loan somebody took out on your behalf.

And the interest is charged in a currency you can't see on an invoice. It shows up as time. The change you asked for last year took two days. The same change today takes two weeks, because it touches four places instead of one and nobody is sure what breaks.

Debt is more dangerous than slow

Most people think technical debt just means things take longer. The worse damage is what it does to how your team behaves.

Once a system gets bad enough, people start avoiding parts of it. Ask for a change in the invoicing module and watch the room go quiet. Estimates get padded, not because the work is hard, but because nobody knows what else will fall over. Sensible improvements stop being proposed, because everyone already knows the answer will be "too risky". Your team quietly stops trying, and it never gets escalated to you as a problem, because avoidance doesn't show up on any report.

Signs the debt is already running your project

▸ Small changes get big estimates. "Just move that button" comes back as three weeks.
▸ One module everyone avoids. There's a part of the system only one person will touch, and they're not thrilled about it.
▸ Every release breaks something old. You fix billing, reporting stops working.
▸ New developers take months to be useful. Nothing is where a normal person would expect it.
▸ Your strongest engineers leave first. They have options, and they can see where this ends.

Then one day a vendor tells you the cheapest option is to rebuild the whole thing. That's not a technical opinion. That's the moment the debt got bigger than the asset, and you've been paying the interest for years without seeing a line item for it. We went deeper on the money side of this in technical debt: the silent tax.

The loop that keeps companies stuck

Now put the three pieces together, because they feed each other.

How the spiral runs

▸ The project is late, so you add people to fix it.
▸ More people means more questions chasing the same few brains that hold the context.
▸ Questions go unanswered, so people guess and ship the guess.
▸ Guesses become debt, and the system gets slower and riskier to change.
▸ Now everything is late, and the obvious fix is to add more people. Round and round.

Every step in that loop is a reasonable decision made by someone doing their job properly. That's what makes it hard to spot from the top. There's no villain, no single bad call. Just a machine that turns budget into mess a bit faster every quarter.

"Adding people to a struggling project is like pouring water into a bucket with a hole. The problem was never how much you poured in."

What to do instead

None of this means you should never grow a team. It means growth has a cost, and the cost gets paid in the code whether or not you plan for it. A few things we've found actually work:

Practical moves for a business owner:

✓ Ask what's actually blocking before you add anyone. Nine times out of ten it's unclear requirements or a slow decision on your side, and no amount of hiring fixes that.
✓ Keep the team small and keep it together. A stable team of four that knows your business beats twelve strangers who rotate every quarter.
✓ Give them someone who can answer questions fast. One person on your side who knows the business and picks up the phone is worth two extra developers.
✓ Ask "what did we skip?" after every release. Make the shortcuts visible while they're still cheap to undo.
✓ Budget for maintenance on purpose. Set aside part of every year's spend to pay debt down, the same way you'd service a vehicle you rely on.

The uncomfortable version of this: if a project is in trouble, the fastest fix is usually to make the team smaller and the answers faster. That's a hard thing to say to a board that just approved five more headcount. It's still true.

The honest version

Software gets built at the speed people can agree on what to build. Everything else follows from that. Add people faster than you can keep them aligned and you don't get more software, you get more guessing, and guessing is what turns into the debt that quietly eats your next three years of budget.

So the next time a project slips and someone says "we need more developers", ask a different question first. Ask what your team is unsure about, and how long it takes them to find out. Fix that, and you'll often find the five extra people weren't needed at all.

"A small team that understands your business will out-deliver a big team that doesn't. Every time, and it isn't close."

Project getting slower the more people you throw at it?

We build with small, senior teams that talk to your business directly, and we write down what we skipped so it never turns into a surprise rebuild. If that sounds like what your project is missing, let's talk.

Talk to Us About Your Project