Keil Hubert: Outsourcing, Risk, and Giant Robot Dinosaurs

Outsourcing a critical tech function involves a lot of potential risk. Business Technology’s resident U.S. blogger Keil Hubert points out that everyone on the IT team needs to understand that, and offers a tool for teaching the idea to your people.


During my military retirement ceremony [1], one of my senior managers gave a brilliant extemporaneous speech about how much he’d learned about IT and leadership from me over the ten years we’d worked together, even though he was more often than not convinced that I must be crazy. It was a tremendous speech, and the ‘must be crazy’ line made the entire audience laugh.

What the audience didn’t know is that this particular senior manager had more reasons to think me insane than most; he’d graduated from my ‘underground’ senior leadership development course back in the late aughts. Not long after taking over the department, I decided that there weren’t any acceptable leadership training options for my people, so I created and taught my own. This fellow had to endure two years of monthly seminars and discussions about organizational behaviour, social psychology, ethics, business theory, and justice. It darned near drove him round the bend, but it led (directly, I think) to his astounding rise up the corporate ladder to the junior executive position that he now holds. I am proud of him for his success, but I’m most proud of him for getting his head wrapped around some really difficult content.

I started the senior team members off with some short articles and white papers. I led with content from the New Yorker, the Wall Street Journal, WIRED, Fortune, and other print content that I collected specifically for the course. We’d all read the content before class day, then would spend about ten minutes summarizing what the content was about, and would spend an hour or so deconstructing how it actually applied to our department. Many times, an article would not appear to be relevant to our operation or culture. There was always a link, though; the fact that people couldn’t initially perceive the link was often the whole point of the discussion. The overarching theme of our discussions was ‘how can you responsibly manage an operation when you don’t understand the subconscious factors that are in play?’

Managing a production work centre that you don't understand is like reviewing a foreign film while blindfolded.

Managing a production work centre that you don’t understand is like reviewing a foreign film while blindfolded.

Over time, I started bringing in more complex material. We spent a long time discussing business techniques and principles (mostly with the help of James Hoopes’ False Prophets as a primary textbook) and organizational dynamics (mostly using Edgar Schein’s Organizational Culture and Leadership). Towards the end of the course, once the senior managers had grown accustomed to the idea that you have to deal with people and organizations as they actually are (instead of how you think they ought to be), I brought in some select passages from Niccolò Machiavelli’s The Prince … and then replaced some key words to drive the day’s point home. I very much enjoyed presenting this little gem:

‘The mercenary captains are either capable men or they are not; if they are, you cannot trust them, because they always aspire to their own greatness, either by oppressing you, who are their master, or others contrary to your intentions; but if the captain is not skillful, you are ruined in the usual way.’ [2]

After I had the managers read that chapter on their own, we put that sentence up for discussion, but replaced the words ‘mercenary captains’ with ‘senior consultants’ and modernized the language a bit. The effect was electric: once reframed into a contemporary business problem, the discussion took off. What is a consultant, really, but a mercenary? He or she is a person with a skill or ability that you require to run your organization that doesn’t exist within your own ranks. You hire an outsider to perform a critical business function that you need done, but for whatever reason can’t or won’t handle in-house. It’s mercenary work no matter how you package it. [3]

There’s nothing inherently wrong with using consultants (and, by extension) partner firms to get things done. Many times, it’s the most cost-effective way to secure a necessary business objective. An experienced prince executive can prudently employ mercenary forces (e.g., technologists, systems integrators, auditors, et al) to gain a tactical business advantage over his or her competitors. This happens quite often with niche tech; if you can get the hot new tech thing deployed before your competitor(s), you can exploit it to gain an early-mover advantage.

That lead horse represents the creation of a Twitter account for a new off-license in Whitby

That lead horse represents the creation of a Twitter account for a new off-license in Whitby

We certainly used outsiders to mitigate our inherent weaknesses. Often times, it was faster and more cost-effective to bring in a highly-effective specialist to solve a thorny problem than it would have been to train up the existing staff members to attain the required level of proficiency. All of the senior managers understood the necessity of out-sourcing. What wasn’t immediately obvious was the inherent risk associated with turning over control of a critical function to an independent agent.

Relying on an outsider to make something happen often leaves the contracting organization extremely vulnerable: you’re counting on someone that you cannot possibly control to do something difficult for you that, if they fail, you likely can’t finish on your own. More importantly, if the outside expert demonstrates their proficiency (and, thereby, shows why you’re dependent on them for the thing that they did for you), you find yourself beholden to keep paying them for their services.

If you contract with a top-notch outfit (one that plays the long game, and lives by the principles of unshakable self-discipline and integrity) then your potential dependency on said outsider is mitigated by the outside party that you’re dependent on. To be clear: it’s the outsider’s honour that protects you from future exploitation. That’s why a darned good consulting group or service provider is treasured; every executive needs partners that they can depend on. When you find a company or contact that’s had the opportunity to screw you over and refused to do so, you come back to do business with them first before dealing with a new potential partner.

A darned good partner understands the value of a symbiotic relationship; a poor partner only sees an opportunity to feed. That is an unscrupulous service provider will use your vulnerability to worm their way into your organization like a parasite, making you dependent upon their services. Their ultimate objective isn’t to maintain your trust, but to bleed you by making it impossible to take the function(s) that they provide in-house. The smarter amoral mercenaries will provide you with a legitimate service, but they’ll deliver in such a way that they never actually harm their host; the bloody stupid mercenaries will try to swiftly drain your company like a vampire and then jump to a new, healthy victim. This shouldn’t come as a surprise if you’ve spent any time in business.

My senior managers grasped these concepts very quickly. We’d depended on outside contractors in the recent past and had experienced mixed results. Some suppliers, Value Added Resellers, integrators, and tech support agents had been brilliant; they delivered exactly what they were contracted to provide, and went out of their way to be transparent, useful, and supportive. Other outsiders had violated our trust, delivering as little as possible – and had demanded all sorts of ‘supplemental’ fees to finish the work they’d been contracted to do. The really bad partners had obfuscated their work, doing everything possible to make it impossible for us to take over whatever they’d promised to deliver. Their documentation was vague and misleading when it existed at all.

'The contract just says that I have to give you your system passwords "in writing." A bloke at the museum said that this legally counts as writing.

‘The contract just says that I have to give you your system passwords “in writing.” A bloke at the museum said that this legally counts as writing.

After we had the Machiavelli lesson, my senior managers suddenly understood why I’d been so insistent on never outsourcing any of our core capabilities. Yes, you can save a bunch of money by turning over an application or an entire data centre to a third party. You can often deliver better results, and you can usually deliver them faster, when you leverage a stronger outfit’s infrastructure and skills investment. For a small or medium business, it can make perfect economic and operational sense to migrate your non-core capabilities to an external service provider. [4]

The key message to remember, I taught, was that you have to always remember that turning a critical function over to an outside agency means that you’re surrendering your control over the process and over the data. Yes, you have a contract with the partner organization … but so what? If your integrator (or hosting provider or whomever) randomly decides to violate the terms of the contract, you have very few options. You can cut off the contract, and you can probably sue them in civil court and maybe win some restitution. Those options take time, however, and don’t actually mitigate the damage done to your processes.

The tongue-in-cheek example that I shared with my senior managers involved the classic ‘mad scientist’ TV trope. [5] If you learn that your data centre manager has been secretly redirecting all of your storage equipment to build a giant robot dinosaur outfitted with a lethal arsenal, you have a great deal of potential risk to deal with. [6] That being said … this crazed inventor works for you. Therefore, you have some immediate containment options available that you can immediately leverage to contain the problem before the Tyrano-Toaster™ goes on a rampage downtown. You can shut off the mad scientist’s network credentials. You can cut the power to the robot construction area. You can lock the bloody thing up. Because it’s all happening inside your facilities and with your equipment, you have some inherent legal and physical ability to influence what might happen next. When things are going very wrong, some control is a great deal better than no control at all.

Conversely, if you find out that your commercial cloud-computing provider has been using all of the data storage kit that you bought to instead construct the aforementioned multi-story death machine, there’s effectively nothing that you can do to contain the problem before the mad scientist takes his or her creation out on a rampage with your logo painted on its spikey tail. You can try to get legal and finance to stop paying the baddies, but that won’t mitigate the damage that’s already been done. You certainly can’t dash over to the partner company and padlock their garage doors or cut their power because you have no legal right to interfere with the conduct of their business. You can try to sue them  … assuming their giant robot doesn’t flatten the courthouse on its way to stomp on something gratuitously flammable.

Every block of flats should include one of these because they're so festive. What could possibly go wrong?

Every block of flats should include one of these because they’re so festive. What could possibly go wrong?

This is a very silly example! I wouldn’t dare claim otherwise, but it worked; it got my point across to my captive audience. In the real world, we rarely have to worry about our IT service providers building giant robot dinosaurs. We do, however, have to consider the ramifications of turning over critical business functions to an outsider that may act contrary to our interests with our equipment or our data.

The savvy manager has to ask: can we trust OutsiderCo™ to protect our critical processes from inadvertent exposure? If they’re breached or compromised, will they respond quickly enough, or thoroughly enough, to meet out standards? Will they even let us know? Moreover, what right do we have to get into the thick of the response effort when a problem occurs? The strongest outsourcing companies and integration companies understand this, and have very thorough contract terms that pre-emptively address these issues. What about a small mom-and-pop outfit? Or a subcontractor? Or an embedded partner company? Or a new corporate overlord that swallows your partner?

I taught my team leads that they can’t escape ownership of a process failure by contracting the process out to a third party. Just because their techs weren’t the ones driving the giant robot dinosaur servers, the systems managers are still held responsible by upper management for whatever goes wrong. Ultimately, the buck stops with the process owner, not with the process operator. Therefore, the pragmatic manager or director needs to take a very sober look at the relative value of the information that’s being put at risk, the potential disruption that an outage or compromise might cause, and the potential for damage to one’s brand.

This all makes perfect sense, doesn’t it? Should come as no surprise. So, let me ask you … how do you know these things?

If you were Odin, you probably learned everything you needed to know from a pair of mystic ravens. Most everyone else was taught by other human beings.

If you were Odin, you probably learned everything you needed to know from a pair of mystic ravens. Most everyone else was taught by other human beings.

It’s not as easy a question as you might expect. You might have learned some of these principles from hard-fought-and-won business experience. You might have had classes in outsourcing from a business school curriculum. A senior leader might have mentored you on the subject. You might have read about other companies’ epic failures. The odds are very strong, though, that you weren’t born knowing these principles, which means that you possess critical information about IT operations and business survival – information that gives you a competitive edge.

That’s probably knowledge that some or all of your team members don’t have. I submit that there are hundreds of these ideas that our junior techs and line managers don’t know yet. That’s not a knock on them at all; we didn’t necessarily know these things when we were first starting out. Someone had to teach us. Therefore, we should (in turn) teach those that come after us.

I strongly encourage you to set some time aside in your monthly schedule to introduce new ideas to your team members as part of a professional development regimen. You don’t need a graduate degree or a professorship; you just need to know something useful that one or more of your people don’t (yet) know. Then find a good story that gets the point across. Start the discussion, and teach your people something interesting. They may or may not make practical use of it in their career, but it will subtly improve them. Odds are good that your people will teach you a thing or two that you didn’t know in the process.

It’s a very inexpensive way to significantly improve team esprit de corps and morale. It’s also something that your people will look back on years afterwards and recognize as something meaningful that you did to help them succeed. There are very few things in life more fulfilling.

[1] We held the ceremony back on 25th January, even though I’d actually retired quite a bit earlier.

[2] From chapter XII, ‘How Many Kinds of Soldiery There Are, And Concerning Mercenaries.

[3] I made a living as an IT consultant for many years. Been there, billed for that.

[4] One of the graduates of my senior leadership program retired and went on to work in an international cloud-computing outfit. I know the lad, and I know the company. They’re brilliant, and do a killer job providing highly-efficient hosting for some really big-name customers.

[5] We were all nerds. For best results, always speak to people in their native language – even if that language is Klingon.

[6] Albeit, an awesome one.

POC is Keil Hubert,

Keil Hubert is a business, security and technology operations consultant in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo! Broadcast, and helped launch four small businesses (including his own).


His experience creating and leading IT teams in the defence, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employees. He currently commands a small IT support organization for a military agency, where his current focus is mentoring technical specialists into becoming credible, corporate team leaders.

Tags: , , , , , , , , ,