18 November 20257 min read
Most teams decide they are ready to outsource at the moment they are most overloaded, which is the moment they are least ready. Readiness is not a feeling of needing help. It is a set of capacities on your side, and the demand for help says nothing about whether you have them.
The uncomfortable version: outsourcing consumes management attention before it releases any. If you have none to spend, starting now makes the next two months worse, not better. That is worth knowing in advance, because it is entirely survivable if you plan for it and quite damaging if it surprises you.
The three prerequisites
Everything else is detail. These three are not.
- Someone owns it. A named person on your side whose job includes answering questions from the outside team within a day, not when they get to it.
- The work can be described. Not fully specified, but described well enough that a competent stranger could start on Monday without inventing the requirements themselves.
- You can tell whether it worked. Someone can look at what comes back and judge it, against criteria that existed before the work started.
Two out of three is not a pass. Missing the first gives you a team waiting for answers while you pay for their time. Missing the second gives you work that is competently built and wrong. Missing the third gives you an engagement nobody can end, because there is no basis on which to say it either succeeded or did not.
Signals you are ready
These are less about ambition than about a certain boring stability in how you already work.
- There is a backlog with items in it that a new joiner could pick up, and someone maintains it.
- Your own onboarding works: a new employee is doing useful work in their first week or two, because the setup is documented and someone owns getting them going.
- The same kind of request keeps arriving and you keep deferring it, which means the demand is stable enough to staff against.
- You know which work is differentiating and which is not, and you can point at examples of each in your own repository.
- There is a rough budget that survives contact with your finance function, so the engagement will not be cancelled at the first invoice.
- A decision can be made without three committees, because outsourced work generates decisions at a faster rate than internal work does.
The onboarding signal deserves emphasis. How long it takes a new employee to become useful is the best available proxy for how long an outside team will take, and it is a measurement you already have. If your own hires flounder for a month, budget an onboarding ramp at least that long for a provider and do not treat it as their failure when it happens.
Signals you are not ready yet
- The work exists only as a conversation. If the requirement lives in one founder's head and has never been written down, writing it down is the project, and it is yours.
- You are hoping the provider will tell you what to build. Some will, and it is a legitimate service, but it is a different and more expensive engagement than the one you think you are buying.
- Your last two internal hires have not worked out. That usually points at a management problem, and a management problem gets worse at distance.
- Nobody has an hour a day. Not a week: an hour a day, sustained, for the first month.
- The system nobody understands is the system you want to hand over. Map it internally first, then outsource the fix.
- The decision is being made because a deadline has already been missed. Adding people to recover a late project makes it later before it makes it earlier, and this is as true of an outside team as an internal one.
The management capacity question
This is the prerequisite most often assumed and least often true. Directing an outside team is a real job, roughly a day a week per workstream at the start, dropping as context accumulates. It is spent on written direction, answering questions, reviewing work, and the weekly conversation about what changed.
It cannot be spread thinly across four people who each spend an hour, because the value comes from one person holding the whole picture. If your only candidate for the role is already your busiest engineer, you have not found the capacity, you have moved a bottleneck.
The time-zone question sits underneath this. If the outside team shares most of your working day, an unanswered question costs an hour. If they do not, it costs a day, and the cost of your own slowness in answering rises accordingly. Buyers in Germany, France, the Netherlands and the UK often choose a small overlap gap specifically to buy themselves forgiveness for being busy, which is a more honest reason than it sounds.
Ready for what, exactly
Readiness is also relative to the shape you buy. Staff augmentation asks more of you: you direct the work daily, so it needs the owner, the backlog and the review habit. Managed delivery asks less day to day but more up front, because the provider owns the outcome and therefore needs a scope and a definition of done that will hold.
A team with strong management capacity and vague requirements should choose staff augmentation and steer. A team with clear requirements and no spare attention should choose managed delivery and accept that the specification is where their effort goes. Teams that get this backwards produce the two classic failures: an augmented team sitting idle waiting for direction, and a managed project delivered exactly as specified by people who were never told the specification was a guess.
If you are not ready, what to do about it
None of the gaps take long to close, and closing them is worth doing whether or not you outsource. Name the owner. Write two weeks of work down. Agree what done means for one item. Fix your own onboarding documentation, since a provider will hit the same wall your last hire did.
Then start deliberately small: one bounded piece of work, one workstream, long enough to see a real cycle of delivery and correction. You are testing two things at once, whether the provider is good and whether you can direct outside people well, and only one of those is about them.
