IT Is Not a Necessary Evil
“Time is Brain.”
That’s what I told my team. Every time a 3am alert fired. Every time a pager went off during dinner. Every time we debated whether the situation was serious enough to wake someone up.
Time is Brain — because the robots we maintained ran on our network. And those robots were in hospitals. And those hospitals were treating stroke patients. And stroke patients, if you didn’t know, are in a race against minutes. Brain cells die. Windows close. Outcomes change permanently based on response time.
I was running IT for a company that built stroke care robots. Which meant I was, in the most indirect and invisible way imaginable, in the business of keeping people alive.
My leadership team thought IT was a necessary evil.
The Belief That Costs More Than Any Budget Line
I’ve spent the better part of my career walking into companies that are struggling. Downtime they can’t explain. Security incidents they didn’t see coming. Infrastructure held together with the IT equivalent of duct tape and good intentions. I come in, assess what’s broken, fix it, and show the results in graphs and charts — because people have short memories, and numbers don’t lie.
In almost every one of those engagements, the root cause wasn’t technical. It was a belief.
The belief that IT is a necessary evil — a cost center to be managed down, a department to be tolerated, a line item to be cut when margins get tight. Not a strategic function. Not a risk management discipline. Certainly not something that deserves a seat at the table when the real decisions get made.
Finance doesn’t get called a necessary evil, even though nobody enjoys a budget review. HR doesn’t get called a necessary evil, even though mandatory compliance training has never once been described as anyone’s favorite afternoon. But IT? IT gets the label constantly, casually, without anyone stopping to consider what they’re actually saying.
What they’re saying is: we don’t understand what this does, so we’ve decided it isn’t important.
And that belief has consequences.
“Figure It Out”
At the robot company, I had been asking for additional resources for the better part of a year. More hardware. More people. The infrastructure was aging, the load was growing, and the warning signs were there for anyone paying attention.
I was paying attention.
I set up meetings. First with my direct boss. Then the CFO. Then the CEO. In every conversation I explained what I was seeing, what I believed would happen if we didn’t act, and what it would take to prevent it. In every conversation I was told some version of the same thing.
Figure it out.
I want to be precise about what that phrase means in practice. It doesn’t mean “we trust you to solve this.” It means “we have decided this is not a real problem, and we’d like you to stop bringing it up.” It is the corporate equivalent of putting your fingers in your ears.
I kept bringing it up anyway. Because Time is Brain, and the stakes were not abstract to me even if they were to everyone else in those rooms.
The inevitable happened. It started with databases getting corrupted. Small anomalies at first — the kind of thing you could almost explain away. Then it escalated. Then it cascaded. Then our entire system, end to end, was down.
For the better part of two weeks.
The Switch
When we finally found the culprit, it was almost insultingly simple.
A switch. One network switch, sitting in the middle of the infrastructure, that was not enterprise grade. It couldn’t handle the data load. So it did what overwhelmed non-enterprise switches do — it dumped its cache and started over. Which caused packets to be resent. Which created more traffic. Which overwhelmed the switch further. Which caused more cache dumps. A loop, tightening slowly over time, until the whole thing came apart.
The cost of an enterprise grade switch that would have prevented all of this: a few thousand dollars. Well within the budget requests I had been making for a year. Well within the category of resources I had been told we didn’t need.
The cost of two weeks of downtime for a company selling life-critical medical technology: I’ll leave that to your imagination.
I think about the patients during those two weeks sometimes. The hospitals that had our robots. The clinicians who showed up expecting a tool and found it unavailable. I don’t know what happened in those situations. I don’t want to know. What I know is that “Time is Brain” wasn’t just a motivational phrase for my team — it was a real and present fact for people who had no idea our infrastructure existed.
Email. It’s Like Fax, But Slower.
Once the systems were back online, the company held a sales meeting. Awards were given. Performances were celebrated. The mood was good.
And someone — I won’t say who — stood up and said, to appreciative laughter and knowing looks in my direction:
“Email. It’s like fax, but slower.”
I sat there and took it. Because that’s what you do. Because the alternative is less professional. Because I had just spent two weeks sleeping in server rooms and I didn’t have the energy left to explain, again, why that comment was not only unfair but factually backwards.
What I wanted to say was: the people in this room who deserve to answer for the last two weeks are the ones who looked me in the eye and said “figure it out.” Not the person who figured it out.
What happened next was equally predictable. The company decided, in the wake of the crisis, that they should invest in IT. They hired a CTO. The CTO brought in someone he knew. I stayed long enough to hand things over properly, to make sure whoever came next had everything they needed to succeed.
Then I left. Because it was clear — from the looks, from the conversations, from the way the narrative was quietly being rewritten — that I was being positioned as the cause of the outage rather than the person who had spent a year trying to prevent it and two weeks fixing it.
I’ve made peace with that. It’s a pattern I’ve seen more than once. The person closest to the problem is also the most convenient person to blame when the problem becomes undeniable.
What I Actually Believe
I believe IT is not a necessary evil. I believe IT is risk management with a keyboard.
Every decision not to invest in infrastructure is a decision to accept a certain level of risk. Every “figure it out” is a transfer of accountability without a transfer of resources. Every shrinking IT budget is a bet that nothing will go wrong — and like all bets, sometimes it pays off and sometimes it doesn’t. The problem is that when it doesn’t, the consequences rarely land on the people who placed the bet.
I believe in proactive IT over reactive IT. Not because it’s philosophically satisfying, but because the evidence is overwhelming. The companies I’ve walked into that were suffering — the ones with the downtime and the security incidents and the infrastructure held together with optimism — almost universally had the same story. There were warnings. Someone saw it coming. Nobody listened until it was expensive.
I believe that “we’re in the cloud” and “we use SaaS” are not substitutes for IT competence. They are different delivery mechanisms for the same underlying complexity. AWS configured incorrectly is not safer than an on-premise server configured incorrectly — it’s often more dangerous, because the blast radius is larger and the misconfiguration is harder to see.
And I believe that IT deserves a seat at the table. Not because IT people need validation, but because the decisions that get made without IT input — budget decisions, vendor decisions, infrastructure decisions — have a way of showing up later as crises. And crises are expensive. And expensive crises have a way of making people look for someone to blame.
I’d rather help you avoid the crisis. That’s the whole point.
A Note to Anyone Who Has Said “Figure It Out”
I don’t hold it against you. I’ve worked with enough leaders to know that most of them weren’t being dismissive — they were overwhelmed, they were operating on incomplete information, and they were doing their best with a function they didn’t fully understand.
That’s exactly why I write this blog. Not to relitigate old arguments, and not to make anyone feel bad about decisions they made with the knowledge they had at the time.
But if you’ve ever thought of IT as a necessary evil, I’d gently invite you to sit with that belief for a moment. Ask yourself what would happen to your business if your systems went down for two weeks. Ask yourself whether the robots — metaphorical or otherwise — that your customers depend on would keep running. Ask yourself whether the people on your IT team have been trying to tell you something that you’ve been too busy to hear.
Time is Brain.
It applies to more than stroke care.
