The backlog isn't the problem

A scale-up we audited last quarter had a backlog of just over four hundred tickets and a plan to hire six engineers against it. Before they opened the roles, we went through the queue ticket by ticket. Fewer than half were actually waiting on engineering.

The rest were waiting on something else: a priority call nobody had made, a design contradicting a newer decision, an assumption never validated, an owner who'd left the company. The backlog looked like a capacity problem. It was a decision problem wearing a capacity costume, and the six hires would have made it worse.

Why backlogs get misdiagnosed

Work enters the system faster than decisions do, and the gap accumulates as a queue. The queue is visible in Jira; the missing decisions are visible nowhere. So the organisation diagnoses the visible thing and hires against it. Then the arithmetic turns hostile:

• Every new engineer needs context that lives in the heads of already-overloaded seniors
• The seniors who should be deciding spend their weeks onboarding instead
• Coordination cost grows roughly with the square of team size while decision capacity stays flat

Brooks observed this about late software projects fifty years ago. It survives every new methodology because it describes queues, not technology.

The four-bucket diagnostic

In our PDLC audits we classify every blocked backlog item by what it's actually waiting for:

1. Waiting on a decision
2. Waiting on information
3. Waiting on another team
4. Genuinely waiting on engineering capacity

Across a year of running this exercise, bucket four has never been the largest. Decisions and information dominate, which means the constraint sits upstream of the people everyone wants to hire.

What fixes decision debt

None of this requires new tooling, which is precisely why it gets skipped in favour of hiring:

• Decisions get owners and deadlines, the way tickets already have them
• Discovery runs continuously, so assumptions get validated before entering the build queue, not three sprints after
• Work nobody can justify gets killed instead of groomed; an item that survives six months unscheduled is a decision someone is avoiding
• Work in progress gets a hard limit, because a team at full utilisation has no slack to absorb a blocked ticket

Hiring is a familiar motion with a budget line and a recruiter. Restructuring how decisions flow has no procurement process, so organisations default to the motion they know, and six engineers later the backlog is larger.

When capacity is the real answer

Real capacity problems exist, and embedded teams are exactly what we build for them. The test is simple: the work in the queue is decided, specified, and genuinely waiting on hands. When that's true, added engineering capacity moves the needle within weeks, and team extension beats a six-month hiring cycle. When it's not true, capacity is the most expensive way to discover your bottleneck was never engineering.

A twenty-ticket test for your own backlog

Pull twenty tickets and ask of each: if a senior engineer picked this up tomorrow morning, could they finish it without waiting on anyone? The percentage that fails is your decision debt, and no hiring plan pays it down.

If you want the full diagnostic run on your delivery system, that's what a three-week Framed engagement does, with the four-bucket audit as the starting point. And if the audit says you genuinely need hands, Embedded puts senior specialists inside your team in fourteen days. Either way, you'll be solving the problem you actually have.