An organization has a cross-functional process that isn't working. Vendor onboarding, campaign intake, contract review. The domain changes. The symptoms don't.
Nobody can name who owns it end to end. You ask, and you get a pause, then three department names, then "well, it depends on the stage." Exceptions are running at fifteen a week, handled in a group chat by whoever is paying attention. Four functions have four sets of requirements, all of them reasonable, none of them reconciled with each other. And there's a legacy system nobody will touch, because the person who built it is gone or because the last time somebody tried, something downstream broke for two weeks.
The request that comes out of this is always the same. We need two builders.
That request is not stupid. It's a completely rational response to feeling stuck. Something needs to happen, building things is visible progress, and capacity is the one input an executive can actually authorize this quarter.
But look at what just happened. Every symptom on that list is a definition problem. And the response was a capacity purchase.
The chain
Put the whole thing on one line.
Business outcome. Operating decisions. Process. Architecture. Requirements. Implementation. Adoption. Measurable outcome.
That's the Implementation Continuum. And implementation, the part everyone thinks of as the project, is the sixth link of eight.
Everything upstream of the sixth link determines whether the build is the right build. Everything downstream determines whether it survives contact with the people who have to use it. Link one is what makes the whole thing measurable; skip it and you cannot evaluate anything you built. Link seven, adoption, is where technically correct systems go to die.
And the resourcing conversation, almost every time, starts at link six.
Why it starts there
Here's the part that matters, and it isn't a failure of judgment.
Link six is where the budget line exists. It's where the vendors are. It's where the role descriptions live. There is a market, a rate card, and a requisition process for builders.
You can hire for link six on a Tuesday. There's no job title for link two.
Nobody in your organization has "operating decisions" on their business card. There is no agency that staffs decision rights. You cannot raise a req for somebody to go settle what "approved" means between two departments that have never noticed they disagree.
So the organization doesn't choose link six. It defaults to link six, because link six is the only link that can be requisitioned. The resourcing decision gets made by what's available to buy rather than by what's actually missing.
That's a structural problem wearing the costume of a judgment problem, which is why smart leadership teams make it repeatedly.
What the default costs
The work of defining doesn't disappear when you add capacity. It gets transferred.
It moves off the leadership team's plate, where it was uncomfortable and visible, and onto the builders' plate, where it is uncomfortable and invisible.
That transfer is the whole problem, and it's almost undetectable for the first six weeks, because everyone is busy and busy looks like progress.
A builder's function is to convert a defined intent into a working thing. If the intent isn't defined, they can't do the job they were hired for. They have to do a different job first. So they run discovery, reconcile stakeholder disagreements, design the process, make architecture decisions, define requirements, and build. Simultaneously. In an organization they've known for eleven days.
Every one of those is a real job somebody trains for. You are now paying build rates for discovery work, and getting discovery quality from people hired to build. Both halves of that are bad, and they compound: discovery done by a builder under delivery pressure is fast, undocumented, and optimized for unblocking the build rather than for being right.
Nobody misled anybody. The leadership team genuinely thought it was buying construction. The builders genuinely thought they were being handed a spec. The scope was never written down, so both were reasoning from an assumption, and the assumptions didn't match.
Each link is a handoff
There's a second reason the chain is worth drawing rather than just asserting.
Every link is a handoff, and every handoff is a place where meaning gets lost. The outcome gets translated into decisions, the decisions into a process, the process into an architecture, and by the time you reach requirements you are four translations away from what you were originally trying to achieve.
That's survivable if somebody is carrying the intent across the handoffs. It is not survivable if each link is owned by a different party who only sees their own input and output.
Which is exactly what a staff augmentation model produces when nobody is holding the whole.
Five links of unfinished thinking do not get resolved by hiring harder at the sixth.
The order
None of this is an argument against augmentation. Augmentation is genuinely valuable, and at the right stage a specialist is worth three generalists.
It's an argument about order. Four stages, and notice what's true of the first three.
Orchestrate. Outcome, decisions, process, ownership. Nobody is building yet. This is the stage everyone wants to compress, and it's the cheapest one to do properly, because the only thing you're spending is attention.
Architect. Boundaries, data, integration design. Architecture help, not builders. Different skill, different rate, much smaller team. This is also where you find out whether the process you designed is actually buildable, which is why it comes before requirements rather than after.
Specify. Requirements, governance, implementation approach. Now a small build team earns its place: two or three people validating that the specification survives contact with the platform. A real build stage, but its job is to de-risk, not to deliver volume.
Augment. Build, integrate, migrate, adopt. Full capacity against something defined. This is where the money goes and where more people genuinely means faster.
Augmentation is fourth. That's not a criticism of augmentation. It's fourth.
The question to ask instead
When you're about to add people, the question isn't whether you need more capacity. You probably do.
The question is which link you're adding it to, and whether the five links before it are finished.
And if you want the smallest possible version of this: before you sign the next statement of work for build capacity, write one sentence describing what that capacity is being asked to deliver, and show it to two people in different functions.
If they read it the same way, go ahead. If they don't, you just saved yourself a quarter.
The Systems Implementation Readiness Assessment walks the operating decisions behind your next implementation. Ten minutes: ruddconsulting.io/readiness