Why new cyber tech is not enough -TEISS® : Cracking Cyber Security
The cost of purchasing new technology rarely factors the cost of sustaining that new technology in the field. Security Awareness blogger Keil Hubert argues that successful procurement factors in the IT and Security departments’ ability to stretch to accommodate the shiny new thing.
If you’re not factoring in support and security impact when you purchase and deploy new technologies, you’re doing procurement wrong. Technical support considerations and security measures must be considered before a shiny new bit of kit gets dropped off on the loading dock.
Moreover, proof of that consideration needs to happen before any company money gets spent. That last thing that you want to introduce into production is a resource-intensive new tech solution that your support team isn’t prepared or equipped to maintain. Don’t do it.
Unless, that is, you’re a ‘Bob.’ I use the pseudonym ‘Bob’ for all of the real characters that I profile or reference in my regular weekly column over at Business Reporter. All of the silly, villainous, or otherwise shocking characters that I’ve dealt with have all been re-named ‘Bob’ in order to protect their anonymity. In this case, the ‘Bob’ in question was the Chief Information Officer of a very large healthcare organisation.
For context, I’d applied for a director-level billet at a hospital where several of my (then) co-workers in a part-time military medical unit happened to work. My fellow squaddies loved their employer, their jobs, and getting to help their patients. All-round, it sounded like a great place to work. Get to do something meaningful that improves lots of patients’ quality of life? That sounded brilliant.
While I was interviewing with the outfit’s IT department leadership group, I asked what problems IT was trying to solve by hiring another director. My interviewer explained that their department had three branches. They’d recently hired on efficiency expert to consult on how best to mitigate their crushing tech support burden.
The boffin had determined that the current tech support branch (his) ought to be split up: one group would continue to operate the Tier 1 support desk functions, while an all-new group would run all of the Tier 2 field support experts. I was interviewing to head up the new Tier 2 branch.
It’s rare to be allowed to interrogate your predecessor about all of the initiatives that they felt they’d failed to accomplish. Even rarer for the person you’d be replacing to be highly enthusiastic about you coming on board to fix what they couldn’t.
The new organisational structure made sense, but I couldn’t see how the split would actually change anything in how support was delivered. I asked the director why their current tech support arm was ‘overwhelmed.’ He admitted that there were (his words) ‘… just too darned many one-off technologies for anyone to keep up with.’ That seemed … weird. Also a bit ominous.
We ran out of time before I could press for details, so I brought the subject up in my end-of-day interview with Bob, the CIO. ‘Why,’ I asked, ‘does your tech support lead feel that you have “too many” different technologies deployed?’
Bob sighed (never a good sign), and admitted that they had an inviolable unwritten rule in the company that anything requested by a doctor was required to be purchased and deployed. No exceptions. The IT department had no right of refusal. As a result, the organisation had official standards, but they also a horde of competing products performing identical functions that were only used by one or two obstinate physicians.
This meant that when an angry customer called the service desk, the poor Tier 1 tech had to work out which of a dozen variations on any given technical solution might be involved before she could route it to whichever Tier 2 tech might know something about the obscure one-off product. No wonder they felt overwhelmed …
I asked Bob why he tolerated the situation. It was, after all, his primary job to find the balance between operational requirements and the capacity of the IT organisation to deliver services to fulfil those requirements. Some new technology requests, no matter how innocuous they might seem in the abstract, were simply too ‘expensive’ to support.
Therefore, it was Bob’s duty to the organisation to either respectfully decline the request, or else find a solution that added new support resources proportional to the new support burden placed on IT in order to implement the new technology.
The analogy of the CIO serving as a traffic warden works here, in the sense that she can only keep the business safe so long as everyone else heeds her warnings.
Bob hemmed and hawed but never gave me a coherent answer. He described an environment where all of the non-clinical executives were utterly powerless; where the youngest, least experienced physician with no business management experience could overrule an executive with decades of experience in her technical discipline on a whim. I politely warned Bob that his culture wasn’t viable. He brushed off my concerns. Note that you can’t find that organisation’s name anywhere on my CV or LinkedIn profile.
I’ve used this story to explain ‘self-destructive cultures’ to new IT leaders. I’ve found that most new managers are so focused on running their functional area that they don’t grasp the big picture and why organisations standards matter. What’s one more thing to support?
I use a food truck analogy to explain it to those young managers because it seems to resonate the best. I tell them to replace the term ‘CIO’ with ‘food truck owner’ and ‘IT department’ with (obviously) ‘food truck.’ I’ll use So-Cal Tacos food truck as my example today since they’re parked outside the building. 
As a new food truck owner, you have a range of menu items that you offer that are based on the ingredients you carry and the food preparation technologies built into your truck. You can support a wide range of tastes based on a common platform (e.g., tacos, available with chicken, beef, pork, fish, and vegetarian). You could probably accommodate a customer’s request to add a new taco type (like barbacoa) without too much difficulty (assuming you had storage space in the truck’s fridge) because it’s a minor change to the core components. Students usually ‘get’ this part without difficulty.
On the other hand, what happens when a pushy customer wants beef stew instead of tacos? Sure, you have the beef, onions, and potatoes (left over from the morning’s breakfast tacos). You don’t, however, have beef stock, carrots, a giant stew pot, a gas ring, or six hours to devote to whipping up a decent stew. The customer’s request isn’t possible given existing resources.
“It’s not that I lack the skill to roast an entire elk, sir; I simply lack the cooler space to keep an entire elk on hand in case it’s requested.”
However the pushy customer insists: he’s important, and he demands stew! The customer is always right! So, what do you do, mister or miss Taco Truck Owner? Realistically, you have three choices:
- Politely tell the customer that it’s simply not an option and work with him to find an acceptable alternative lunch solution based on what you have available.
- Find another Taco Truck that offers beef stew and recommend it to the customer.
- Re-design your food truck to include a stew-making station. Add new staff and new provisions storage. Work out new recipes and workflows to deliver an acceptable product.
All three of those choices seem reasonable. At first. In both the Decline and Outsource options, you run the risk of alienating the one pushy customer. Gruff Guy gets mad, takes his money elsewhere, and maybe bad mouths you to his friends. That’s a small but realistic risk. You might lose some future business.
The Deliver option, however, satisfies the pushy customer by accepting potentially huge initiation and sustainment costs that might end up sinking your entire business. In order to make up the dosh that you’ll have to sink in new equipment, new staff, new supplies, new permits, new signage, and spin-up time, you’ll need to sell those first few bowls at several hundred quid each.
If the pushy customer is so committed to the idea of food truck stew that he’s willing to fund the expansion up-front, great! Have at it! If he’s not … are you prepared to take on all the hassle, all the expense, and all the risk of over-extending your workforce and budget just to satisfy one special request?
Going the extra mile to serve your customers is admirable in the abstract; that said, it’s often crippling in practice.
Now (I say) repeat that ‘one special request’ process a dozen more times. Or a hundred more. Every time you roll the metaphorical dice, you’re running the risk of ‘breaking’ your entire operation. Not just ruining the ‘one little thing,’ but the whole allegorical food truck.
I don’t teach my students to be harsh authoritarians; rather, I want them to get into the habit early on of thoroughly evaluating new technology requests before agreeing to implement. Get all the experts involved. Run tests that stress the existing tech support team. Make sure that you have all of the licenses and tools needed to sustain the new thing. Once you know what it will likely cost, present the requester with the invoice (for start-up and sustainment costs across the solution’s probably lifecycle) and find out if they’re committed to seeing their requested solution through.
A significant element of every IT leader’s job is to politely explain just how expensive and burdensome a user’s ‘one little thing’ request really is. True, everything is theoretically do-able … with enough money, time, and people. Do-able isn’t the issue; affording it is. Let your pushier users and occasional Bobs stew on that.
 Perhaps also because the queue to order today was so long that I had to go find something else for lunch. Grrrrrr …