Before you hand a capability to a vendor, decide whether you intend to ever run it yourself, because the default answer becomes no.
What happens after a successful infrastructure project?
Somebody has to operate the thing, and that question rarely appears in the business case.
The proposal covers the purchase, the migration, and the benefit. It assumes operation as a background condition, the way it assumes the building will have electricity.
Operating a new platform is not a background condition. It is a skill that either exists on your team or does not, and if it does not, somebody has to acquire it during a period when they are already fully committed.
How big does a virtualization project get?
Bigger than the first system, quickly.
After the first rescue worked, I made it a directive to virtualize everything. I left the first host running only that one system, because virtualization was new to us and I was not confident that adding workloads would leave it fast.
So I bought a second host and put around thirty systems on it. Then another. Then another. By the end we had eight hosts.
Those eight replaced roughly three hundred old machines, which we sold off as used equipment.
Every system got faster, and the gains were large rather than marginal. Security improved, because workloads sat inside a managed layer rather than on individual boxes scattered around a building. Availability improved.
By any technical measure the project was a success, and that success created the problem.
Why do teams fail to learn a new technology?
Not because they do not want to.
My team wanted to learn it. Nobody objected, nobody dragged their feet on principle, and nobody argued the technology was a bad idea.
They had no time. They were running the middleware, the databases, the applications, and everything else, and those systems did not pause while a new platform arrived.
The classes existed. Training was available and I was willing to pay for it. Taking a class means days away from work that has no cover, and the work would still be waiting afterward, with a few days added to it.
They would not do it outside normal hours either, which is a fair position and I have never held it against anyone.
Training requires slack. My team had none, and no amount of willingness substitutes for hours that do not exist.
When should you hire outside help instead of training your team?
When the work has to happen now and the hours to learn it do not exist.
I felt like I was in a no-win situation. The private cloud was running production systems and needed competent operation immediately. My people wanted the skill and could not get to it. Waiting was not available.
So I hired an outside firm to run it, US Technical Services, the same people who had already proven themselves several times over.
It worked exceptionally well. The platform ran properly, the systems stayed up, and the technical outcome was everything I had wanted.
My team did not like it. They were right to feel that way and I would make the same call again, and both of those are true.
What does outsourcing a capability cost long term?
The ability to ever do it yourself.
My team never got the skill back. The vendor ran that platform from then on, permanently, and nobody ever decided that. It arrived as a consequence.
The mechanism is simple once you see it. The reason to learn a technology is that you need to operate it. Once somebody else operates it, the reason disappears, and the hours that were unavailable when the reason existed are certainly not going to appear now that it does not.
Each year the gap widens. The platform advances, your people fall further behind, and bringing it back in house becomes a bigger project than the original migration.
Nobody makes that decision. It is made by the absence of a decision, over several years, and by the time anyone notices, it is settled.
How do you outsource without losing the capability?
Decide the answer at the start and build it into the contract.
If you intend to bring the capability in house eventually, say so before signing. Name who on your team will learn it, put shadowing in the agreement, and set a date for reviewing whether it happened. Vendors accept this, because a vendor who has done good work usually keeps the account anyway.
If you have decided to outsource permanently, that is a legitimate choice and it deserves the same clarity. Know what your exit would involve, keep the documentation on your side, and be honest with your team that this is not their area and will not become theirs.
The failure is neither of those. The failure is the third path, where nobody chooses, everyone assumes the skill will come back later, and it never does.
What should a small company outsource?
Things that are not how you make money, and things where a small company will never build depth.
Payroll, most infrastructure operations, specialist security work, and anything requiring on-call coverage a team of eight cannot provide. Those are reasonable and they buy back time that has somewhere better to go.
Be more careful with anything close to how the business works. Once that knowledge sits outside the building, the vendor understands your operation better than you do, and switching costs stop being about software.
The question to ask before signing is not whether the vendor is good. It is what happens in five years if they are still doing it, because for a capability like this, they will be.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.