The Hiring Dip: Why Adding People to Your Constraint Makes You Slower First

You did the hard part. You worked out which resource actually sets your delivery speed, you resisted the temptation to spend the improvement budget on the team that shouted loudest, and you arrived at the conclusion the arithmetic demands: the constraint needs to be bigger. So you raised a requisition, argued it through a headcount panel, spent four months finding someone good, and started them on a Monday.

And for the next two quarters, your portfolio delivered less than it did before they arrived.

This is not a bad hire, a weak onboarding process, or a failure of anyone's management. It is a structural feature of elevating a constrained resource, and it has a cause so simple that it is almost never designed around: the only people qualified to train the new person are the people who are already the bottleneck. Every hour spent teaching, checking and answering comes out of the scarcest hours in the organisation. So the act of adding capacity to the constraint first subtracts it. I want to give that period a name, because a cost without a name gets absorbed rather than managed: the hiring dip, the stretch of time during which a hire made to relieve your constraint is actively reducing its output.

The dip is not an argument against hiring. It is one of the best investments most portfolios can make, and I will show the numbers below. The dip is an argument against hiring the way it is normally done: late, into a crisis, priced in salary, planned as though a person becomes capacity on their start date, and abandoned at exactly the moment it starts to work.

Where the capacity actually goes

Three separate drains run during a ramp, and only the first one is ever discussed.

Teaching. Someone has to sit with the new person and transfer judgement. Not systems access or process, judgement: which of these three approaches will survive contact with the auditor, why this integration pattern is the one that does not fall over at quarter end, what the unwritten reason is that nobody touches that module. That knowledge exists only inside the heads of the constrained resource, which is precisely why they are the constraint. Every hour of it is an hour not spent on portfolio work, and it is front-loaded into the weeks when the new person can least reciprocate.

Checking. Everything the new person produces has to be reviewed by someone who could have produced it themselves. This drain is more insidious than teaching because it scales with the new person's productivity: the faster they get, the more output arrives needing review, and the review is constraint work by definition. In the early months, a competent hire can easily consume half an hour of senior time for every hour of their own output, and the organisation reads this as the new person being productive.

Interrupting. Questions do not arrive in tidy blocks. They arrive in fragments, one every forty minutes, each of them individually trivial and each of them landing on someone doing work that requires an hour of loaded context to hold in their head. This is the cost of multitasking applied to the scarcest resource you own, and it is the reason a ramp that looks like six hours a week of teaching on a calendar behaves like ten hours a week in reality. The clock time is not the cost. The shattered afternoons are the cost.

Set against those three drains is the new person's own contribution, which starts near zero and climbs. The dip is simply the period during which the drains exceed the contribution. Its depth and duration are not mysterious. They are calculable, and calculating them changes what you decide.

The shape of the dip

Three numbers describe any elevation attempt, and a portfolio that knows all three can make this decision properly.

Depth is the largest cumulative shortfall, measured in constraint-hours, between what the constraint produced and what it would have produced if you had hired nobody. It is the size of the hole.

Duration is how long until the cumulative shortfall is repaid, which is a different and much later date than the month in which the hire stops being a net drain. Most organisations, if they track anything, track the second date and congratulate themselves several months too early.

Hold time is how long you will actually have the person doing constraint work after break-even, and it is the number nobody asks for. If the specialist you ramped for five months is reassigned to a strategic programme in month six, promoted out of the work in month eight, or leaves in month ten, you paid the entire dip and collected a fraction of the return. A hire onto a constraint is an investment with a payback period, and like any such investment it can be terminated before it pays. The difference is that this one is usually terminated by a decision nobody connects to the hire at all.

Notice what this means for the scarcest skills. The rarer the expertise, the longer the ramp, the deeper the dip, and the smaller the pool of people who can teach it, which is to say the more concentrated the drain on exactly the people you are trying to relieve. The hires that matter most are the ones that hurt most on the way in. That is not a paradox to be resented, it is a schedule to be planned for.

A worked example

Numbers make the shape concrete. These are illustrative rather than precise, and rounded to four-week months; the pattern is what matters.

A delivery organisation funnels all of its work through four senior integration engineers. They are the constraint: nothing ships without passing through them. Each contributes about 30 productive hours a week once meetings, incidents and administration are removed, so the constraint runs at 480 constraint-hours a month. Across the portfolio, an hour of their time returns roughly £900 of value, the value per constrained resource hour that the whole portfolio is really being paid on.

You hire a fifth engineer. Fully loaded cost, £95,000 a year. The resource plan does what every resource plan does and adds them as 1.0 FTE from their start date: +120 constraint-hours a month, worth £108,000 a month in throughput. Over the first six months, that plan promises 720 additional constraint-hours, or £648,000 of extra delivered value.

Here is what actually happens, month by month, in net constraint-hours added to the system after the teaching, checking and interruption are subtracted:

• Month 1: the new engineer contributes about 18 hours of usable output. Teaching, review and interruption take roughly 71 hours off the existing four. Net: minus 53 hours.
• Month 2: contribution up to 36 hours, drains down to 58. Net: minus 22 hours.
• Month 3: contribution 60, drains 48. Net: plus 12 hours. This is the month the hire stops making things worse.
• Month 4: net plus 43 hours.
• Month 5: net plus 71 hours.
• Month 6: net plus 92 hours.
• Month 7 onwards: net plus 115 hours a month, and it stays there.

The dip bottoms out at the end of month 2 at a cumulative 75 constraint-hours never produced. At £900 an hour, that is £67,500 of throughput the portfolio did not deliver because it was hiring. Note that this is already more than six months of the engineer's salary. The cheapest thing about this hire was the salary.

Cumulative break-even, the point at which the hire has repaid the hole it dug, arrives about four and a quarter months in, part way through month five. And over those first six months, the constraint delivered a net 143 extra hours, worth about £128,700, against a plan that promised 720 hours and £648,000. The gap of about £519,300 is not a forecasting error anyone will name as such. It will be distributed across a dozen projects as small unexplained slips, and each one will be attributed to a supplier, a specification change, or a delivery manager who needs to grip things harder.

Now the other half of the ledger, because this is the part that makes the dip worth paying. From month seven onward the hire adds 115 constraint-hours a month, or about £103,500 a month, which is roughly £1.24 million a year of additional portfolio throughput against a £95,000 salary and a one-off £67,500 hole. Judged over any horizon longer than a year, this is one of the highest-return decisions available to the organisation. Judged over one quarter, it looks like a mistake. Most organisations judge it over one quarter.

The cancellation trap

Put the dip together with the way hiring decisions are actually triggered, and you get a failure mode that is close to universal.

Nobody hires onto a constraint when the constraint is comfortable. They hire when it is visibly drowning: deadlines missed, escalations weekly, the specialists working evenings, a board asking why everything is amber. The requisition is a response to pain. Which means the ramp begins at the precise moment the organisation has the least slack in the system to absorb it, and the teaching hours must be taken from people who were already over-committed. The dip is therefore deepest exactly when it is least affordable, and it lands on a portfolio that is already late.

So month two arrives, throughput is down, the escalations have got worse rather than better, and somebody senior asks the obvious question: we added a person, why are we slower? At which point one of three things happens, and all three are expensive.

The organisation concludes that hiring does not help, and stops. It has now paid the full £67,500 and will collect nothing, and it has acquired a durable institutional belief, supported by real evidence, that adding people to this team makes things worse. That belief will block the correct decision for years.

Or it protects the delivery by pulling the seniors off teaching and back onto the work. The new engineer is left to ramp by osmosis, which stretches a five-month ramp into an eighteen-month one, and converts a sharp dip into a shallow permanent tax. The hole gets dug more slowly and never quite fills in.

Or it does the thing that feels most sensible and is in fact the worst: it hands the new hire to a non-constraint team to be trained, because they have the availability. Six months later the organisation has a competent engineer who is excellent at work that was never the bottleneck. It has spent a full salary converting a constraint hire into a non-constraint hire, which by the logic of The Non-Constraint Trap is worth precisely nothing in throughput.

Each of these is a rational local response to an unforecast dip. None of them would have happened if the dip had been on the plan.

Why single-project management is blind to this

If the dip is this predictable, why does essentially no portfolio plan for it? Because every instrument the organisation uses to manage capacity is incapable of representing it.

A resource plan models a person as an integer that switches on. There is no field in any mainstream planning tool for "contributes 15 percent of an FTE this month, and consumes 60 percent of a different FTE while doing so." The new joiner appears as 1.0 from their start date, and the plan built on that number is wrong by hundreds of hours before anyone opens it.

The teaching hours are charged to nobody. They are not on a project code. They appear, if they appear at all, as team development, line management, or the unbilled residue that gets rounded away when someone calculates a utilisation figure. So the single largest cost of the hire is structurally invisible to the finance function that approved it, which approved it on salary because salary was the only number on the form.

And the throughput loss does not land in one place. It is spread thinly across every project that shares the constraint, so no individual project ever sees a signal large enough to investigate. Twelve projects each slip a fortnight, twelve project managers each write a plausible local explanation, and nobody sums the column. This is the same blindness that makes the price of a new project invisible: a cost that lands on shared capacity is a cost that no single-project view is built to see.

Underneath all of it sits the Project Illusion in its capacity-planning form: the belief that the organisation's ability to deliver is the sum of the people it employs. It is not. It is the throughput of one shared resource, and a headcount decision that is made annually, by a different function, on cost, and never expressed in constraint-hours, is a decision about the most important number in the business taken in a currency that cannot measure it.

What to do instead

1. Price the hire in constraint-hours before you approve it. Salary is the smallest cost in this decision. Before the requisition goes up, produce three numbers: the depth of the dip in constraint-hours, the month of cumulative break-even, and the steady-state gain per month. Multiply all three by your value per constrained resource hour. In the worked example those numbers are minus £67,500, month four and a quarter, and plus £103,500 a month, and any board shown all three will make a better decision than a board shown £95,000.

2. Buy the zero-dip capacity first. Hiring is not the only way to elevate a constraint, and it is the one with the deepest dip. Before it, exhaust the moves that add constraint-hours without consuming any: take the work off the constraint that does not need to be there, which for most specialists is a startling proportion of their week in scheduling, chasing, documentation and meetings they attend out of habit. Reduce the demand arriving at the constraint by stopping the lowest-return work, which is capacity created instantly and for free. Automate a checking step. Each of these buys hours next week rather than next year, and, critically, the hours they buy are the slack that makes the subsequent ramp cheaper. Do them first and the dip you eventually pay is shallower.

3. Rank elevation options by depth and payback, not by eventual size. A hire that eventually adds 115 hours a month but costs 75 hours and five months to get there is not automatically better than an offload that adds 30 hours a month starting next Monday for nothing. Compare them properly: constraint-hours consumed, months to repayment, hours gained per month thereafter, and the honest hold time. In a portfolio that is currently on fire, the shallow, immediate option is usually correct first, and the deep one is correct as well, started at the same time, funded by the relief the shallow one bought.

4. Only let the constraint teach what only the constraint can teach. This is the single highest-leverage change available, and it is free. Split the ramp explicitly. Tooling, environments, access, domain background, process, the org chart, how the change board works: none of this requires a constrained specialist, and all of it is routinely delivered by one because they are the natural owner. Assign every element of the onboarding to the cheapest resource that can deliver it, and reserve constraint time exclusively for judgement transfer. Most organisations can cut the constraint hours in a ramp by half without touching the outcome.

5. Sequence the handover by teaching cost per hour freed, and batch the teaching. The instinct is to throw a new hire at the most urgent or most interesting work. The arithmetic says the opposite: transfer first whatever is cheapest to teach per constraint-hour it permanently frees, which is almost always the routine, high-volume, low-judgement work that the specialists have been doing because it was quicker than explaining. That is where the fastest relief lives. Then protect the teaching itself from fragmentation. Two scheduled ninety-minute blocks a week, with questions held and batched between them, cost the system far less than the same three hours arriving as twenty interruptions, because the interruptions destroy the constraint's ability to do deep work in the gaps. A question that waits four hours costs almost nothing. A question that lands mid-task costs the rest of the afternoon.

6. Hire ahead of the pain, and forecast the dip before it arrives. Recruitment plus ramp is a nine to twelve month fuse on the most important capacity decision you make, which means the decision has to be taken while the constraint still has room to teach. That is uncomfortable, because it means arguing for headcount at the moment the evidence is weakest, and it is the only version of this decision that works. Then put the dip on the plan. Forecast throughput down for the ramp months, tell the board it is coming, and give them the break-even date in advance. A predicted dip is a plan being executed. An unpredicted dip is a crisis, and crises get the correct decision reversed at the trough. This is the same principle as buffer management: the value of a signal lies entirely in whether it arrives before people are forced to react.

The objection you are already forming

"So the answer to a constraint that is drowning is to not add people to it, or to add them at some theoretical future moment when it stops drowning, which it never will. My specialists are working weekends now. Are you seriously telling me to run permanently short-staffed and just accept it?"

No. Hire. The arithmetic in this piece is an argument for the hire, not against it: £1.24 million a year of recovered throughput against a £67,500 hole is one of the best returns in the organisation, and you should be doing it more aggressively than you currently are, not less. Nothing here says the constraint should stay as scarce as it is today. The alternative to paying a dip once is paying the scarcity forever, and the scarcity compounds, because an overloaded constraint is also the one that cannot document, cannot delegate, and cannot train, which is what makes the next ramp even more expensive than this one.

What changes is everything around the hire. You price it in the right currency, so the decision is made on throughput rather than salary. You do the free elevations first, so the ramp begins with some slack instead of none. You take the teaching load off the constraint wherever a cheaper resource can carry it. You publish the dip before it happens, so that month two reads as the plan working rather than the plan failing. And you start the clock nine months before the pain, because that is the actual lead time on the decision.

Organisations that say hiring specialists never helps are almost always describing the same experiment: hired late, into a fire, with no ramp design, no forecast, and a cancellation at the trough. That experiment does fail, reliably, and it fails for reasons that have nothing to do with whether more capacity would help.

The deepest version of this is uncomfortable and worth sitting with. The best moment to hire onto your constraint is the moment it is least obviously necessary, because that is the only moment you can afford the teaching. By the time the hire is obviously necessary, you have lost the ability to make it cheaply, and you will be asked to dig the deepest hole of your delivery year in the quarter you can least afford it. Whatever your constraint is now, the useful question is not whether it needs more capacity. It is what you would have to start this month for it to have more capacity next spring.

This piece follows on from How to Find the One Resource That Sets Your Delivery Speed and The Non-Constraint Trap, which together tell you where to spend your improvement budget. This one is about what happens in the months after you decide to spend it. If you want the number that tells you whether the capacity you are buying is worth what it costs, start with Value per Constrained Resource Hour, and if you want to create constraint capacity this week rather than next spring, the cheapest source of it is starting less work.