You're about to open a job req. Here's a two-number test that tells you whether more hands will actually help.

A req gets approved in March. Sourcing runs through April. Interviews take most of May. The offer goes out in June, to someone who owes their current employer two weeks' notice. They start in July, spend six weeks learning your product and your codebase, and write their first pull request anyone actually depends on sometime in September. By then, the roadmap you hired them for has already been rewritten twice.

Most leaders already know that timeline. Nobody expects a new hire to save this quarter. The part that catches people off guard comes later. Once that engineer is fully ramped up, delivery is still moving at roughly the same pace it was in March.

The two numbers that show you where the time really goes

Pick something that shipped later than you wanted last quarter. Then count two numbers.

First: the calendar days between the ticket being written and the feature going live.

Second: the days anyone actually spent building it.

On most teams, the second number is a small fraction of the first. The gap between those two numbers is where your roadmap actually lives. The work sat waiting on a scope question only the head of product could settle. It sat waiting for a senior engineer to sign off on the approach. It sat in a review queue behind four other pull requests. It sat waiting for a test environment, or for the next release window.

Every one of those waits represents a queue or dependency. Adding another engineer doesn't necessarily address the underlying constraint and can increase work in progress if that constraint remains unchanged. What you can get is more work in progress, more half-finished tickets on the last day of the sprint, and little improvement in throughput if the underlying constraint remains unchanged.

The gap between those two numbers is where your roadmap actually lives.

More people doesn't mean more speed

DORA, the software delivery research program at Google Cloud, has studied software delivery performance for more than a decade. Its research consistently shows that how teams work matters: practices like continuous integration, loosely coupled architecture, small batch sizes, and fast code review are associated with stronger delivery performance. More engineering capacity doesn't automatically improve any of those things. And adding people to a late project can temporarily slow the people who already know the system, since they're the ones bringing new team members up to speed.

Every person you add also creates new relationships to manage. Three people have three pairs to keep in sync. Six people have fifteen. Software rarely splits into neat, independent pieces, so the parts you can hand off cleanly are rarely the parts that were slow to begin with.

AI work can make this constraint more visible, because many AI systems still depend heavily on judgment calls. How to chunk documents for retrieval. Whether a slower model is worth a better answer. What "good enough" means for an output nobody has a scorecard for. Those calls come from a small number of people. Put more builders on the roadmap, and you just send more questions to those same people, every week.

The eval problem nobody counts as a delivery problem

Ask how anyone on your team knows a change to retrieval actually made the product better.

If the honest answer is that one person opens the app, runs fifteen queries they remember being bad, and forms an impression, then you don't have a systematic eval layer. You have a person acting as the eval. Every change has to run through whoever has the best feel for the output.

That person now sets the pace for the whole roadmap. You can't hire around them, either. Judging output against what your users expect takes months of context a new engineer doesn't have yet. Most teams file this under quality, or under "we should build evals at some point," and never move it into the delivery conversation. It belongs there. It's already deciding what ships and when.

More capacity just piles up in front of your constraint

This idea is familiar from Eliyahu Goldratt's Theory of Constraints: increasing capacity somewhere that isn't limiting the system doesn't necessarily increase the throughput of the system as a whole. Gene Kim and Steven Spear make a related argument in Wiring the Winning Organization: performance depends heavily on how an organization is wired, how work is divided, dependencies are managed, decisions get made, and problems get surfaced and solved.

If review is your bottleneck, more people writing code just makes the review queue longer. If one architect signs off on every design, more builders just makes that queue longer too. Either way, the cost is real: recruiting fees, salary, benefits, and management hours that never show up in a budget line but still come out of somebody's week.

This is also why AI coding tools help some teams a lot and barely help others at all. The tools can increase the rate at which code is produced. If your review and testing can absorb that, it's a gift. If review was already the slow part, more code just backs up the queue faster.

What actually moves a ship date

If coding isn't the constraint, shorter waits are what move the ship date. And that's less obvious than it sounds.

It means one person with the authority to answer scope and architecture questions the day they come up, instead of a week later. It means review that runs continuously, not in batches every Friday. It means automated tests that run consistently as part of the engineering workflow, without relying on someone to remember to trigger them. It means a definition of "done" that everyone agreed to before the work started, so nothing bounces back two weeks later over something the spec should have caught.

That list doesn't look as impressive as a hiring plan. It moves your ship date faster anyway.

When hiring is still the right call

Hiring earns its place on work that will exist for years, led by someone already in the building. If your roadmap will still look roughly the same in two years, go hire, and hire well.

If your roadmap changes shape every few weeks, and leadership is asking what shipped this month, the same budget goes further shortening the waits first. Decide how many people the work needs after that, not before.

Where a pod fits

This is the gap White Rabbit Group built Delivery Pods to close. A pod is a small, senior, fully in-house team that shows up with the process questions already answered. One person, the Outcome Owner, is accountable for what ships and runs the backlog, so there's a single name to ask when you want to know where something stands. Another person owns the retrieval, integration, and eval calls specifically, which keeps that decision queue from forming in the first place.

A pod can move faster than a newly formed team because the team has already established how it works together, because they've already run this loop together, many times.

A pod still needs you. It can't decide what to build, and it can't fix a roadmap nobody has prioritized.

Point a pod at a backlog with no priorities, and you'll get prioritization meetings faster. That's about it.

Find your constraint before you write the job description

Take the last five things that shipped later than planned. For each one, write down the longest stretch it sat untouched, and what it was waiting on. The same word usually shows up three or four times.

Then ask what a new engineer would have actually done about that word. Sometimes the honest answer is that they'd have helped, and if that's yours, go hire. More often, the word is a decision, a review, a test, or an environment. None of those move faster because someone new started on Monday.

Write the job description if you still need it. Just know what you're actually hiring to fix.