Draft for Tamir's review. Not published.
Split the work before you choose
List the work and estimate the hours. Separate commodity tasks, such as infrastructure, helpdesk and patching, from knowledge only your people hold. Name the capability customers choose you for, and keep control of changes to it.
Test whether the knowledge transfers before handing over a function. Ask the people doing it today to document the exceptions, then have the bidder explain its decisions on those scenarios.
Judge the provider on evidence
Give the provider a paid trial deliverable from the real backlog and judge it before the contract commits volume. Define acceptance for each deliverable and who on your side checks it.
Check exit and knowledge transfer terms in case you bring the work back. If delivery is concentrated in one location, ask what stops when it's unavailable. Model the cost including your own management and review time.
Depending on your seat
If you're on the board and management wants to replace a provider with an in-house team, check both sides. Ask for the provider's record against the contract, the in-house roles, cost and hiring plan, and how the company keeps running meanwhile. Approve by stage, with a fallback.
If you lead a public body, build in-house the roles that hold knowledge: product owners, architecture, data and security. Buy delivery capacity under those roles, and start with one service team before expanding.
What to check before you decide
- Split current work into commodity tasks and knowledge only your people hold, with hours for each.
- List the people whose knowledge can't be replaced in a quarter, and keep them.
- Keep all code, environments, credentials, documentation and vendor relationships under company control, in writing.
- Give the provider a paid trial deliverable from your real backlog before committing volume.
- Define response times for business-critical incidents separately from routine ones.
- Check exit and knowledge transfer terms, including handback to a future in-house team.
- Check the in-house plan against roles the local market and your pay rules can actually fill.
Questions people ask
Management wants to replace our managed service provider with an in-house team, what should the board check before approving?
Check the case on both sides: what the provider's record is against the contract, what the in-house team would cost and whether it can be hired, and how the transition keeps the company running. Approve a transition plan with stages and a fallback. It depends on the local market for the roles and on what the provider contract allows at exit.
Our startup can't hire the ML engineers the plan assumes and the roadmap is slipping, what should the board decide?
Ask what the roadmap actually needs those engineers for, because much of it may be achievable with providers' models and strong product engineering. Change the plan to the team you can build, and hire the few specialists for the parts that need them. It depends on how much of the product requires custom models versus integration and evaluation.
Should directors accept outsourcing concentrated in one delivery location?
Evaluate continuity by transferable capability and operational dependencies. Location labels alone say little. Selection depends on knowledge distribution, access, substitution evidence, and the business's tolerance for interruption.
About to outsource most of our engineering offshore to cut burn before a funding round, what should I check before signing?
Keep the people who hold the product's architecture and the customer knowledge, outsource work you can specify and check, and keep the code, environments and documentation in your hands. Test the vendor on a real deliverable before the contract commits volume. It depends on how much of your product is well documented and on how long the round can wait.
Should our agency build an in-house development team or keep buying digital services through framework vendors?
Build in-house the roles that hold knowledge and judgement, such as product ownership, architecture and data, and buy delivery capacity from vendors under those roles. A full in-house team is rarely staffable; a full outsourcing leaves nobody who knows the systems. It depends on your hiring rules and pay bands, and on which services change often.
Should we outsource dispatch when service continuity depends on local knowledge?
Test transferability before handing over the function. The choice depends on documented exceptions, decision authority, and whether the proposed provider can handle actual disruption scenarios.
Should we buy our core customer capability from an outsourcing company?
Separate commodity support from the capability customers choose you for. The decision depends on differentiation, change control, portable knowledge, and whether a supplier can constrain your future offers.
Lost half my small IT team, should we outsource to a managed services provider or rebuild the team?
Outsource the commodity work such as infrastructure, helpdesk and patching, and keep the knowledge of plant systems and vendors in-house, even if that is one person. Judge the provider on how it handles production-critical systems and on exit terms. It depends on how much of your IT is plant-specific and on what the local market offers for hiring.
How I can help with this decision
- Ask or talk (Free)
- I give my view on which parts of the work suit a provider, which roles you must keep, and where such transitions usually fail.
- Review (Pay if it was worth it)
- I write an independent assessment of the provider's offer, your in-house needs, the transition and the exit terms. I recommend what to keep, what to hand over and on what terms.
- Retain (When it makes sense)
- I stay close through the transition to review the provider's deliveries and service reports, and readiness at each stage.