This is the 259th article in the Spotlight on IT series. If you'd be interested in writing an article on the subject of backup, security, storage, virtualization, mobile, networking, wireless, cloud and SaaS, or MSPs for the series PM Eric to get started.
I just had the good fortune of going to Spiceworld and spending a few days drinking with IT pros from across the U.S. Did I say drinking? Heh – I meant talking. Over drinks. OK, fine — I really did mean drinking. A lot. And it was good.
It was during these conversations, and a peculiar tradeshow situation, that I was reminded of a key IT reality. IT “owns” everything, but it’s easy to mistake ownership for control.
Photo credit:Adam Baker
At the show I got to talk shop with a bunch of good folks, and I was brought back to the good (and the not-so-good) times I had when the helpdesk was also my desk. As I listened to IT folks from steel and PVC manufacturing companies, universities, and even a ring of car dealerships, I noticed each story had a common theme that ran true with my own past: When you’re in IT, your @$$ is on the line every day. You’re expected to own it all.
Proving this point, I had a couple of discussions with attendees that got interrupted by critical systems issues that cropped up “back home”… and I sat with them as they logged in, found the tickets, called the affected customer or end user, and resolved the situation from the show floor. In IT, even when you’re three states away from the office, at a tradeshow for work, the regular gig doesn’t stop.
I was seeing “the old life” all around me, but it wasn’t until it was time to prep for my breakout session demonstration that I went from just seeing the old life, to feeling like I was right back in the IT hot seat.
See, I had built a little demo for our CTO, CEO, and myself to deliver to 150 eager Spiceheads. It was super simple. 99% of the stuff was in the cloud, and just worked. The only complicated part was that I needed to make sure that the three computers used in the demo were each on separate routed networks, as though one device was in a house, one was in an office, and one was in a coffee shop. I only had to do that because I was trying to prove a point in the demo—and it was really easy to do with a couple of cheap home routers and a switch.
I guess the other complicated part was that if anything went wrong, my bosses and I were going to look like clowns in front of 150 smart people. Which, is, as they say, “career limiting.” Not that I’d be fired on the spot if it went wrong, but maybe… the next morning. Or over dinner that night.
“Enjoying your steak Chris? How do you like Austin? Dinner’s on us, tonight—you know, in celebration of your last day. Goodbye!”
So, I made sure to be thorough. I built the demo, pushed the config, and ran a bunch of successful tests in California. I then packed up the gear, shipped it to Texas, and got on a plane. I owned the system from end to end. It did what I made it do, and it did it regularly, reliably, and repeatedly. No worries, right?
Famous last words…
Despite my confidence, our CEO wanted to see everything work before we did the show on stage. Not an unreasonable request, really. I remained confident. After all, I built the demo, and I saw the demo working the night before we delivered it on stage. But the CEO hadn’t seen me set it up. He hadn’t seen the successful tests. He didn’t know, or probably care, what infrastructure I had in place—he just knew that it had to work and that I was the guy who owned it all.
We started our run-through in the hotel. The presentation was great, our banter was good, the topic was strong. But let me tell you—that hotel network was capital B-usted. Broke as a joke. The bandwidth was fine, but DHCP was happy to give out IP addresses already in use, and even when you did get a unique IP, the network sent every device to a captive portal (splash screen) randomly and frequently. It was a big mess.
Now, I knew that the hotel network was the problem. I knew that my network, and my cloud, were totally fine. But that didn’t matter to the CEO. The whole system didn’t work because the weakest link had failed. I owned it, and I had to fix it, even though the only part that was broken was the hotel, and I had zero control over that part.
I’m not bagging on the hotel here. My sheets were clean, I had fresh towels, I had some kind of fancy shampoo that smelled like apples and vanilla and made me want to eat it. This hotel was good—at being a hotel. They weren’t so good at being a network service provider. IT was clearly not their strength, nor was it their interest. But at that time, IT had to be my interest, and my strength. Because even though their network was busted, I needed my demo to work.
Here’s the short version: two 4G wireless hotspots and a little network reconfiguration saved the day. I had already planned for the single point of failure, either at the hotel practice or at the show, and brought a separate backup system. Good times.
Now, when I started this story, I said that it’s easy to mistake ownership for control. In this example, I “owned” the whole demo network, even though I didn’t control the hotel’s piece, the 4G backup, or the cloud piece.
I was comfortable “owning” the 4G and the cloud component, even though I knew I had little to no control over them. Unlike the hotel, these services are run by experts that I researched, investigated, and trust. That’s why I pay them.
On the flipside, the hotel is better at making beds and cleaning showers than I am. (Way better. My wife will affirm that I am no good at making beds or cleaning showers.) But frankly, I am, like everyone reading this on Spiceworks, a billion times better at networking than the hotel staff. They likely contract out to someone, and that someone happened to be a clown. But the hotel never claimed any different. I don’t pay them for killer Wi-Fi, and they don’t market it to me, and I knew I better have a backup plan that I do control.
I do, however, pay for killer 4G and cloud services. I do my research to make sure that the services I pay for are as good or better than what I have the time to build, manage, and “be expert at” myself. There’s just no way I could personally set up a wireless cellular network, with multiple redundant towers, and reliable throughput and connectivity, and there’s also no way that I could never set up multiple redundant servers with geographical and local redundancy and speed. That’s why I “own” that responsibility, but trust and pay the experts to “control” those services.
Heck – I guess I also own but don’t control the electricity that made my demo work. Without that, I’d be dead in the water—but I know the power company has the infrastructure that I lack to make that happen.
I guess, like all IT folks, I put my trust in other experts, so that I am free to be an expert at my own domain. I provide backup when and where it’s needed, and that way I can sleep at night knowing I have done all I can, and that there are literally “experts on call, standing by to help.”
Where do you draw your line of expertise? Where’s your demarc between ownership and control?
