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 isn’t a background condition. It’s a skill that either exists on your team or doesn’t, and if it doesn’t, somebody has to acquire it during a period when they’re 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 wasn’t 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’d 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 and not marginal. Security improved, because workloads sat inside a managed layer and not 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 don’t 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’d no time. They were running the middleware, the databases, the applications, and everything else, and those systems didn’t 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’s no cover, and the work would still be waiting afterward, with a few days added to it.
They wouldn’t do it outside normal hours either. That’s 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 don’t 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 don’t 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 couldn’t get to it. Waiting wasn’t 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’d wanted.
My team didn’t like it. They were right to feel that way and I’d 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 doesn’t.
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’s made by the absence of a decision, over several years, and by the time anyone notices, it’s 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’ve decided to outsource permanently, that’s 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 isn’t their area and won’t 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 aren’t 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’s 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 isn’t whether the vendor is good. It’s what happens in five years if they’re still doing it, because for a capability like this, they’ll be.