The backlog was too long, the hiring freeze was real, and the supplier was good. So you did the sensible thing that every constrained organization eventually does: you bought capacity. 12 engineers, competent and available, at a rate your finance director could live with, onboarded in 6 weeks. The plan said the delivery rate would rise by something like a third.
A year later it has fallen.
What you bought has a name: staff augmentation, bringing in outside people to add capacity without adding headcount. It is a reasonable answer to a real shortage, and the supplier usually delivers exactly what was promised. Where it stops is the assumption that the capacity arrives at no cost to anyone else. Every hour of bought-in work has to be specified, reviewed and accepted by somebody, and that somebody is almost always one of the few constrained people you were short of in the first place.
Nothing failed in a way that shows up in a review. The supplier did the work. Your people worked hard. The projects that slipped each slipped for their own particular reason, and each reason was true. What nobody wrote down is that the 12 engineers you bought arrived with a bill attached, payable in a currency you cannot purchase, and that the bill was larger than the capacity you thought you were adding.
The effect has a shape and it deserves a name, because unnamed costs get absorbed rather than managed. Call it the supervision coefficient: the number of hours of your constrained resource consumed by each hour of capacity you buy from outside it. It is never zero, it is almost never estimated, and in most portfolios it is large enough to decide whether buying capacity speeds you up or slows you down.
Staff augmentation: the capacity you can buy is not the capacity you are short of
Start with the thing everybody knows and almost nobody applies. A portfolio delivers at the rate of its constrained resource, the one whose capacity sets the pace for everything else. In most engineering organizations that resource is not the bulk of the workforce. It is a small population of people who hold design authority, own the system architecture, understand the integration, sign the safety case, or are the only ones a regulator will accept. 15 people, maybe 8, inside an organization of 600.
Now ask what the market will sell you. It will sell you build capacity, test capacity, documentation capacity, analysis capacity, project administration. It will not sell you a person who already holds the design authority for your product, because that knowledge is specific to you and took 9 years to grow. This is the first and most under-appreciated fact about buying delivery capacity: the capacity that is easy to purchase is, with near-perfect reliability, the capacity you are not short of.
That alone is the non-constraint trap, and if it stopped there the purchase would merely be a waste of money rather than a loss of throughput. It does not stop there, because bought capacity does not sit. It generates demand on the constraint. Every hour of work done by someone outside the constrained group arrives, sooner or later, at the constrained group: as a question only they can answer, an interface only they can arbitrate, a design decision only they can approve, a piece of integration only they can perform, an output only they can accept. That flow of demand is the coefficient, and it means the purchase does not merely fail to add throughput. It subtracts it.
One rule, and it fits on a line
Here is the whole of the economics, and it is worth being able to state it in a sentence.
For any capacity you buy, two numbers matter. Call c the constraint-hours consumed per hour of purchased capacity, and r the constraint-hours removed per hour of purchased capacity. Then:
Buying capacity increases throughput only when r is greater than c.
Everything else is detail. Notice what the rule does not contain. It does not contain the day rate, the headcount, the size of the backlog, or the supplier's reputation, which are the things that actually get discussed in the room where the decision is taken. A cheap supplier with r below c makes you slower. An expensive one with r well above c makes you faster and is worth paying almost anything for. Price tells you what a purchase costs. It tells you nothing whatever about what the purchase does.
The rule has a second use, which is to size a purchase rather than merely judge it. If you are willing to spend some fraction of your constrained resource's year on supervising bought capacity, call that your supervision budget, then the maximum volume of external capacity you can absorb is your supervision budget divided by c. Not your backlog divided by anything. The amount of capacity you can usefully buy is set by the hours you have available to supervise it, and by nothing else at all. Most organizations size the purchase against the work they want done, which is precisely the number that has no bearing on the question.
A worked example
Numbers make the shape concrete. These are illustrative rather than precise, but the structure is one most portfolios will recognize immediately.
A change portfolio runs everything through a design authority and systems integration group of eight people. They are the constraint: nothing is committed, integrated or accepted without them. Each contributes about 28 productive hours a week once meetings, interruptions and administration are stripped out, across roughly 46 working weeks, so the organization holds 10,304 constraint-hours a year. That figure, not headcount and not budget, is its capacity to deliver change.
An hour of that group returns about $1,100 of value. That is the value per constrained resource hour the organization is actually being paid on, and it puts annual throughput at roughly $11.3 million. A typical delivery consumes about 700 constraint-hours, alongside a couple of thousand hours of other engineering, so the organization completes about 14.7 deliveries a year, each worth around $770,000.
The backlog is about twice that. So the portfolio does what portfolios do.
Deal A: buy 12 engineers. A supplier provides 12 capable engineers at $95 an hour, 1,600 hours each, for $1,824,000 a year. They build. The design authority specifies, answers, reviews, integrates and accepts.
Measure what that costs the constraint and the figure looks unremarkable in isolation: about 3.5 hours a week, per supplier engineer, of a constrained person's time. Anyone who has run an outsourced team will recognize that as conservative rather than alarmist. Over 46 weeks and 12 engineers it is 1,932 constraint-hours a year. Expressed as a coefficient, c is 1,932 divided by 19,200, or roughly 0.10: 6 minutes of your scarcest people, per supplier hour, for as long as the contract runs.
6 minutes an hour sounds like nothing. It is 18.7% of the entire capacity of the organization to deliver change, and at $1,100 an hour it is $2,125,200 of foregone throughput a year.
And r, in this deal, is zero. Not small: zero. The supplier does no work that was previously done by the constrained group, because the supplier cannot do that work. That is why it was the constraint. So the constraint-hours left for delivery fall from 10,304 to 8,372, the delivery rate falls from 14.7 to about 12.0, and the portfolio completes 2.8 fewer things a year. It paid $1.82 million for the privilege of losing $2.1 million of throughput.
Deal B: buy the same kind of help, aimed differently. Now spend a third as much. A supplier of four people, $620,000 a year, takes a defined and bounded body of work off the constrained group: test evidence packs, regression rigs, interface documentation, the assembly of assurance material. It is work the design authority currently does itself because it is the only group that knows the system well enough, and it is about 140 constraint-hours per delivery.
The supervision cost is real but far smaller, because the scope has a hard boundary, the team is stable, and one named person owns the interface: about 300 constraint-hours a year, a coefficient of 0.047. Against that, r is about 0.39. Every constraint-minute spent on this supplier buys back eight.
Run the same arithmetic. Constraint-hours available: 10,004. Constraint-hours per delivery: 560 rather than 700. Deliveries: 17.9 a year, up from 14.7, an extra $2.4 million of throughput for $620,000.
Set the two side by side. Same organization, same market, same rates, both decisions defensible in the room in which they were taken. One of them costs 3 times as much as the other and delivers six fewer projects a year, a swing of roughly $4.5 million. The difference is not effort, competence or price. It is which side of a single inequality the purchase sat on, which nobody calculated, because the instrument the decision was made with has a column for cost and no column for constraint-hours.
What moves the coefficient
c is not a constant of nature. It is a property of how you buy, and it varies by a factor of five or more between two organizations purchasing the same service. Six things move it, and each one is a lever.
Fragments versus boundaries. Buying pieces of work from inside a design your own people own is the expensive shape, because every fragment comes back for judgment. Buying a whole bounded thing, with an interface, an acceptance test and a specification your people wrote once, is the cheap shape, because it comes back once. The same 12 engineers can carry a coefficient of 0.15 or of 0.03 depending entirely on where you drew the line around their work.
Tenure. c is at its highest in the first 6 months and falls steadily as the supplier accumulates the context that makes questions unnecessary. This is the same ramp that makes adding people to your constraint reduce output before it raises it, and it carries an unwelcome corollary: re-tendering resets the coefficient to its starting value. A procurement cycle that moves the contract every 3 years for a 15% rate saving, paying a year of elevated supervision each time, is very often selling throughput to buy cash. That trade can be correct. It is almost never priced.
Contract shape. Fixed price does not remove the supervision load, it moves it earlier and concentrates it. Somebody has to specify precisely enough to contract against, and that somebody is the constrained group, before any work exists. Every subsequent ambiguity then becomes a commercial conversation that the same people have to adjudicate. Time and materials moves the cost onto a meter and does not touch the questions at all.
Suppliers, not people. Two suppliers working on one delivery do not carry twice the coefficient of one. They carry more, because the seam between them is a dependency that only your constrained people can arbitrate, and seams multiply faster than parties. This is the coordination ceiling arriving through the procurement department.
Supplier speed. Counter-intuitively, a faster supplier can raise your coefficient. Output arriving at your constraint more quickly is not absorbed more quickly. It queues, and a queue of finished-looking work generates status, chasing, rebasing and rework while it waits. You can buy production. You cannot buy the ability to absorb it.
Quality, in the narrow sense of decision quality. Defects are cheap to fix and expensive to adjudicate. What loads the constraint is not a supplier's error rate but how often their work requires a judgment only your senior people can make.
Why nobody ever sees the bill
If the supervision coefficient is this consequential, the obvious question is why it appears in no business case anywhere.
Because of how the hours arrive. Supervision is not delivered in blocks. It arrives in six-minute units: a question in a corridor, a review that was going to take 20 minutes, a call to unpick an interface, a decision somebody needed before Thursday. No unit is large enough to book against a code, and no unit is large enough for anyone to refuse. Each one is genuinely the fastest way to unblock the thing in front of you. This is the granularity problem that makes sub-threshold work the most expensive thing in most portfolios: the load is enormous in aggregate and invisible in every instance.
It also sits on the wrong side of an asymmetric ledger. The supplier invoice is transacted, dated and auditable. The 1,932 constraint-hours are counterfactual, spread across 8 people and 14 projects, and they surface as a slightly slower year that everybody explains with something else. The organization ends up with a precise number for what the purchase cost and no number at all for what it did, then repeats the purchase next year on the strength of the precise one.
There is a third reason, and it is the least comfortable. The supervision load falls on exactly the people who will never complain about it, because answering the question is their job, they are good at it, and being needed is not an unpleasant experience. Your constraint will absorb the coefficient silently right up until the day it stops absorbing anything.
Why single-project management is blind to this
Ask whose budget the 1,932 hours came out of, and the answer is nobody's. That is the problem in one line.
Each project priced the supplier the way a project is built to price things: against its own cost baseline, in cash, comparing a bought engineer at $95 an hour with an internal one at a notional $140. On that comparison the supplier is obviously cheaper, and each project was right on its own terms. The constraint-hours the purchase consumed came from a shared pool that no business case owns, spent on behalf of a portfolio no project manager is accountable for. A cost that lands on shared capacity is a cost the single-project frame cannot represent. The decision was not taken badly. It was taken with an instrument that has no way of displaying the larger of the two numbers involved.
This is the Project Illusion wearing a purchase order. The illusion is that a portfolio is a collection of independent projects, each free to optimize its own cost without affecting the others. Under that assumption, buying cheaper hours is unambiguously good and buying more of them is better still. In a constrained system it is false, because the projects are not independent: they share one scarce resource, and it is that resource, not the sum of the project budgets, that determines what the organization delivers. 12 cheap engineers and 4 well-aimed ones are entered identically on the ledger, and they have opposite effects on the result.
What to do instead
None of this is an argument against buying capacity. It is an argument for buying it in a shape that survives contact with your own arithmetic.
1. Measure your coefficient before you buy any more. You can do this in a fortnight, and it needs no system. Take the four or five people who genuinely constrain your delivery and have them log, in rough half-hour buckets, time spent on supplier-facing work: answering, specifying, reviewing, integrating, accepting, arbitrating. Divide by the supplier hours consumed over the same fortnight. You now have c for your own organization, probably for the first time. Almost everyone who runs this exercise is surprised, and the surprise is never in the direction of the number being smaller than they assumed.
2. Ask what a purchase removes from the constraint, and refuse to accept zero. The gate question is not "what does this cost", nor even "what capacity does this add". It is: how many constraint-hours does this remove, and how many does it consume? If the honest answer to the first is zero, you are not buying delivery capacity, you are buying work in progress, and you should expect throughput to fall. Say so before the contract is signed rather than 18 months afterwards.
3. Size the purchase to your supervision budget, not to your backlog. Decide explicitly what share of your constrained resource's year you are prepared to spend on supervision. 5% is a defensible starting point. Divide it by your measured c, and that is the volume of external capacity you can absorb. In the worked example, a 5% budget of 515 hours at a coefficient of 0.10 funds about 5,150 supplier hours, or 3 engineers. The organization bought 12, because the backlog said 12. The backlog was never the relevant number.
4. Buy across a boundary, not inside one. Wherever you can, purchase a whole bounded deliverable with a specification, an interface and an acceptance test, rather than a quantity of people who will work inside a design your constrained group owns. This is the single largest lever on c, it is entirely within your control, and it demands one piece of unglamorous preparation: defining the boundary properly, which costs constraint-hours once instead of every week thereafter. Treat that definition as the full kit for the purchase, and do not start the supplier until it exists.
5. Prefer fewer, longer, steadier relationships. Since c falls with tenure and rises with the number of parties, continuity is not sentimentality, it is capacity. Before any re-tender, put a number on the supervision ramp you are about to re-incur and set it against the rate saving. Before adding a second supplier to an existing delivery, price the seam. Both are ordinary arithmetic, and both are routinely omitted.
6. Give the supervision load an owner and a place in the plan. If the coefficient is real, then supervision is real work, and real work belongs in the plan rather than in the gaps between it. Name who carries it, allocate the hours in the resource model so they are not double-counted as delivery capacity, and stop planning your constrained people at 100% of a figure that was never available in the first place. This is phantom capacity in its purest and most avoidable form.
7. Put a constraint-hour line on the purchase decision, permanently. For any capacity purchase above a threshold, require two numbers rather than one: the cash cost, and the net effect on constraint-hours, priced at your value per constrained resource hour. In the worked example, a single line reading "minus 1,932 constraint-hours, minus $2.1 million" would have changed the decision in the meeting where it was taken. The discipline costs an afternoon a year. It is among the highest-return governance changes available to most portfolios.
The objection you are already forming
"This is all very clean, but I cannot hire. The headcount is frozen, the specialists do not exist in the market, and the board wants more delivered next year. Buying capacity is not one option among several. It is the only lever I have."
That objection is right about the situation and wrong about the conclusion, and the gap between the two is where the money is. Nothing here says do not buy. It says the purchase carries a second price, denominated in the one resource you are actually short of, and that you can choose a shape which pays a little of it or a shape which pays a great deal. Deal B in the worked example was a purchase, made under the same hiring freeze, in the same market, from the same kind of supplier. It bought three more deliveries a year for a third of the money. The lever was not hiring. It was aiming.
There is a harder version of the objection, and it deserves a straight answer. Sometimes the work genuinely cannot be bounded, the constraint genuinely cannot be relieved by anyone external, and you still have more demand than capacity. In that case the honest conclusion is not to buy anyway and hope. It is that you have a throughput problem money cannot solve this year, and the levers that remain are internal: reduce the number of things open at once, rank what you do start by what it returns on the constraint, and take the lowest-return work out of the portfolio altogether. That is a worse conversation to have with a board than announcing a supplier. It has the advantage of being true, and of not costing $1.8 million to discover.
One caution on the good outcome, so that Deal B is not oversold. Lifting delivery from 14.7 to 17.9 raises the load on everything downstream of the constraint by about a fifth, and somewhere in that chain sits the next limit. Expect to find it, plan for it, and read The Ceiling Behind the Ceiling before you bank the whole gain in a business case.
The uncomfortable summary is this. Most organizations that feel short of capacity have already bought a great deal of it, and are slower than they were before they did. Those two facts are not a coincidence and they are not a failure of execution. They are what happens when an organization buys the capacity that is for sale, repeatedly and in good faith, without ever calculating what each purchase costs the capacity that is not.
If you have not yet established which resource sets your delivery speed, start with How to Find the One Resource That Sets Your Delivery Speed, because none of the arithmetic here works without it. For the number that prices a constraint-hour, see Value per Constrained Resource Hour. And for the reason cheaper hours keep winning arguments they should lose, read The Asymmetric Ledger.
Leave a Reply