Before you hand a capability to a vendor, decide whether you intend to ever run it yourself, because the default answer becomes no.
This is one of the decisions from my IT years that still stings. I made a call that was right for the systems and hard on my people, and I’m still not sure a better one existed. What bothers me most is that nobody ever chose the final outcome; it crept in while everyone was busy doing their jobs well.
What happens after a successful infrastructure project?
Somebody has to work 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.
What bothers me most is that nobody ever chose the final outcome; it crept in while everyone was busy doing their jobs well.
Operating a new platform is 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. I think leaving operation out of the business case is one of the laziest habits in corporate IT, and the people who pay for it are the staff who inherit a new system on top of a full workload.
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 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. Security improved, because workloads sat inside a managed layer instead of on individual boxes scattered around a building. Availability improved. I was proud of that project, and I still am. 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 had 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 has 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’ve never held it against anyone.
Training requires slack. My team had none, and no amount of willingness substitutes for hours that don’t exist. I blame the way IT departments get staffed, lean enough that any new skill has to come out of somebody’s evenings, and I was part of that system.
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.
Nobody on my team liked 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.
The skill never came back to my team. 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 work it. Once somebody else works 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. That drift makes me angrier than any bad vendor ever did, because a bad vendor at least gives you something to fire.
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. It’s the third path, where nobody chooses, everyone assumes the skill will come back later, and it never does.
| Path | What to do | Result |
|---|---|---|
| Bring it in house eventually | Say so before signing; name learners, put shadowing in the agreement, set a review date | The skill has a planned way back |
| Outsource permanently | Know your exit, keep documentation on your side, be honest with your team | A legitimate choice made with clarity |
| Nobody chooses | Everyone assumes the skill will come back later | It never does, and the gap widens each year |
My take
Outsource a skill once and you’ve outsourced it for good. My team never got the private cloud back, and nobody decided that. It happened because the reason to learn disappeared the day someone else ran it. I’d make the same call again under the same pressure. But if you outsource, write knowledge transfer into the contract and give your people paid hours to learn while the vendor works. Otherwise plan on renting that skill forever.
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 can’t provide. Those are reasonable, and they buy back time your people can spend somewhere better.
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 what happens in five years if they’re still doing it, because for a capability like this, they will be. I’d make the same hire again, and this time I’d write the handback plan into the contract on the first day. Letting a skill walk out the door by accident is a management failure, and it falls on the people who wanted to learn.
Three managers guide you through Street-Smart Management Wisdom, a book that makes you the hero facing the decisions instead of a student reading about them.
