Latest
AI’s Black Box Is Getting a Window. Somebody Still Has to Look Through It“It Stars C. Thomas Howell. No.” Why AI Gets Stuck in a LoopShould You Query or Self-Publish Your Memoir If You’re Not Famous?Judge the Writing, Not the Tool: What the AI Pile-Ons Get WrongThiago Ferreira: Thinkers, Not DoersYana Semova: Let AI Do the AdminLisa Hamilton-Smith: Unstoppable, AI AssistedSuperman Day: The $130 Contract Behind the CapeRaymond Chandler Day: The Novelist Who Started at FiftyJohn Steinbeck Day: The Reporter Who Wrote the NovelInternational Translation Day: The Invisible AuthorsMaya Angelou Day: The Dare That Became a MemoirNational Podcast Day: The Interview Is the Raw MaterialKurt Vonnegut Day: The Book That Took Twenty YearsTell a Fairy Tale Day: The Stories Everybody EditedHarry Potter’s Birthday: The Book Twelve Publishers MissedHarper Lee Day: The Draft Her Editor Saw ThroughGene Roddenberry Day: The Pilot Who Pitched the StarsRoald Dahl Day: Six Pencils and a Grudge Against Grown-UpsInternational Literacy Day: The Readers Books LoseJack Kerouac Day: The Scroll and the Last AddressElmore Leonard Day: Leave Out the Part Readers SkipEncourage a Young Writer Day: The Adult Who Read the PagesBack to the Future Day: The Script Where Everything Pays OffNational Library Lovers Month: The Building a Town Pays ForAlice’s Day: The Story Told on a Rowing BoatRobert E. Howard Day: The Texan Who Built ConanStephen King Day: The Daily Two ThousandEmily Dickinson Day: The Poems in the DrawerIan Fleming Day: Two Thousand Words a MorningFyodor Dostoevsky Day: The Novels Written Against the ClockZora Neale Hurston Day: The Ear She TrainedF. Scott Fitzgerald Day: The Masterpiece That FloppedElmore Leonard’s 10 Rules of Writing, and Which Ones I BreakShould Your Novel Have a Prologue? When a Cold Open Earns Its Place“People Who Use AI Deserve to Be Castrated”: When the Sentence Outruns the CrimeHow Famous Memoirs Were Really Written: What the Collaborators DidThe Bell JarOpen: An AutobiographyBeneath a Scarlet SkyFlorida RoadkillCampus BattlefieldLifeThe Phone Book: The Curious History of the Book That Everyone Uses But No One ReadsThe Sage of SagittariusDid I Ever Tell You This?: A MemoirPa’anAmerican SoldierIt Doesn’t Take a HeroMake Your Bed: Little Things That Can Change Your Life…And Maybe the World

My Team Never Got the Skill Back

TL;DR: The first time you outsource a capability is usually the last decision you get to make about it. I built a private cloud, my team had no hours to learn the technology, so I hired a firm to run it. That worked well and it worked permanently, because a skill your people never acquire doesn’t arrive later on its own.

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.

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.

From the author
Street-Smart Management Wisdom by Richard Lowe

Street-Smart Management Wisdom
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.

Frequently Asked Questions

How do you find time for training when nobody has any?
Reduce the work before adding the training, since willingness doesn’t create hours. Take something off the person’s plate for the duration, or accept that the training won’t happen and plan accordingly instead of scheduling it and watching it slip.
Should employees train outside working hours?
Some will and many reasonably won’t, and a plan that depends on it is a plan that fails. If the skill matters to the company, the time comes out of company hours or it doesn’t come out at all.
How do you write knowledge transfer into a vendor contract?
Name the people on your side who will be trained, specify shadowing or joint operation for a set period, require documentation you own, and set a review date. Vague commitments to knowledge transfer produce nothing.
What are the signs a vendor relationship has become a dependency?
Nobody internal can describe how the system is configured, the vendor is consulted before decisions and not after, and estimating what a replacement would cost is impossible. Any one of those means switching has stopped being a software question.
Can you bring an outsourced capability back in house?
Yes, and treat it as a project with a budget and not as a decision. It usually costs more than the original migration, because the platform has advanced and the internal knowledge has decayed at the same time.
How do you tell a team the new platform will not be theirs?
Directly, with the reason, before they find out from the vendor. The decision is defensible when the hours don’t exist. What damages trust is letting people believe they’ll get the skill later when nobody intends to make that possible.

About the Author
Richard Lowe, professional ghostwriter

Richard Lowe is a professional ghostwriter and author with 113+ books authored and 54+ ghostwritten. Before writing full time he spent 33 years in enterprise technology, including 20 years as Director of Computer Operations and Technical Services at Trader Joe's. He writes nonfiction, fiction and memoir, and works with executives and experts on books that build authority.

More about Richard Lowe →

Disclaimer

The views and opinions expressed in this blog post are solely those of Richard Lowe and are based on personal experience and research. This content is for informational purposes only and should not be construed as professional legal, financial, accounting, or business advice. Always consult with qualified professionals before making important business or legal decisions. Richard Lowe is not a lawyer, accountant, or licensed professional advisor, and this content does not establish any professional relationship.

0 comments

No comments yet. Yours can be the first.

Was this useful?

Leave a comment