TechMustard

How I think about building and running IT organizations. Frameworks, trade-offs, and what actually matters when you're responsible for how technology serves people.


The Cost of Getting IT Wrong

Posted by Jonathan Spiva on Tagged leadership, security, risk, operations

Most organizations don't invest in IT because they can't imagine what happens when IT fails. Not slow IT. Not frustrating IT. Catastrophic IT failure, the kind that ends companies.

There's a statistic that floats around security circles: 60% of small businesses close within six months of a cyberattack. Congress has cited it, the SEC has cited it, every security vendor with a pitch deck has cited it. The problem? The National Cyber Security Alliance, the group it's usually attributed to, says they didn't produce it and can't verify it. They've asked people to stop using it.

So I won't build on a zombie statistic. What follows are real companies, real failures, real consequences. Most less than ten years old. Many well-funded.

Code Spaces, a SaaS code hosting company, was gone in twelve hours after an attacker reached their AWS control panel and deleted everything when they tried to fight back. GitLab found that five of five backup methods weren't working after an engineer accidentally deleted production. Verkada, a camera startup backed by Sequoia, left Super Admin credentials on an unencrypted subdomain, and hackers reached 150,000 cameras in hospitals, jails, and schools. Maersk lost $350 million to NotPetya and recovered only because a power cut in Ghana had knocked one domain controller offline. National Public Data, a data broker, exposed 2.9 billion records and filed for bankruptcy within months, the clearest case of a breach ending a company outright.

None of these had zero IT. They had budgets, engineers, vendors. What they lacked was narrower, and cheaper, than money. GitLab didn't lack backups; it lacked someone whose job was to confirm they restored. Code Spaces didn't lack a cloud; it lacked a second control on the account so one stolen login couldn't end the company in an afternoon. Verkada didn't lack security staff; it lacked anyone who owned the unglamorous question of where Super Admin credentials were allowed to live. Even Maersk, which could afford anything, survived only on the luck of an offline domain controller.

The gap each time was ownership and attention to inputs, not headcount or spend, and that's the part worth sitting with, because it's the part you can fix without a big budget. Knowing what good looks like is what lets you notice the unowned detail at all. Small companies fail because they don't have that knowledge; well-funded ones had it and never made acting on it anyone's job. Either way the fix is a person, not a purchase.

A fair objection: several of these were engineering failures, not corporate IT. True, and the point survives it. GitLab's backups sat with engineering; laptops and offboarding sit with corporate IT. Every surface needs a single owner, and each failure above traces to one not existing. The rest of this piece is about corporate IT, the surface most likely to have none. If you also ship a product, ask the same of production: whose job is it, wholly?

What investment actually means

Investment doesn't always mean headcount. A small company with rigor, deliberate trade-offs, and someone who cares about inputs rather than just outcomes can run well on minimal spend. But that takes someone who knows what good looks like. You can't have rigor about what you don't understand, and you don't even know what you're missing.

Rigor means doing things correctly even when no one's checking.

Caring about inputs means watching the process, not just the result. Outcome-thinking lets you coast until something breaks; input-thinking catches problems before they become outcomes.

Deliberate trade-offs mean knowing what you're choosing and why. Every org makes trade-offs; the question is whether you make them on purpose or by default.

Knowledge means knowing enough to recognize good. Without it you can't tell whether your systems are configured right, your processes have holes, or the people running your tools actually know how.

Before you can make any of these investments, before you can even know which to make, you need one name on it. Call it a DRI, the directly responsible individual Apple made famous, or the accountable role every RACI chart insists there be exactly one of. Same idea.

This isn't a demand that one person do all the work. Finance doesn't run that way and neither should IT. Your CFO owns finance, period, and still leans on a bookkeeper, a controller, an audit firm, a tax firm. Many hands, one owner. The trouble is finance has a CFO and IT usually has no one: no CIO, no CTO, nobody whose job is to own the whole of it. A DRI sees the whole picture, sets the bar, and can tell you what the organization actually needs. The question isn't "what does IT cost?" It's "who can answer that?" Until someone owns it, you're guessing.

Which is also why "we have an MSP" isn't "we have an owner." Outsourcing the work is normal and often smart, and a good managed services provider is a fine set of hands. But they close the tickets you file. They won't tell you which tickets you should have filed, or which risks you aren't tracking at all. You can outsource the work. You can't outsource the ownership.

If you're not technical, the worry is telling a competent owner from a confident one. Three questions get you far. Ask them to walk through a recent decision and the option they rejected; real owners think in trade-offs, not absolutes. Ask what they'd stop doing, not just what they'd add; only someone who sees the whole picture can prune. Ask how they'd know in six months that it worked; strong answers name a measure, weak ones name an activity. And if you'd rather not carry it yourself, a fractional CIO or an outside IT practice is the standard bridge: enough ownership to set the bar, short of a full-time hire. That last option is the work I do, so weigh the suggestion accordingly.

The accountability gap

Tasks getting done doesn't mean anyone owns IT. Three people doing IT work doesn't mean you have coverage.

I run an IT practice, which means I am usually called in after the gaps have started to show. At one company, the CFO was the Google Workspace admin, the VP of Engineering ran MDM, and an HR generalist shipped laptops. I asked who retrieved laptops when someone left. The room went quiet. I asked who could tell me what access a departing employee had across all systems. Same silence.

None of them knew what the others were doing, who had access to what, or who owned what. And it was broader than three: little pieces of IT lived with nearly everyone, twenty of the twenty-two, each spinning up their own tools as they went. No one was leading it. There was no rigor, because rigor is something a person insists on, and no expectation, because no one was there to set one.

If everyone is responsible, no one is. And if no one is the DRI, the CEO is, whether they know it or not.

For leadership: five questions you should be able to answer

If you don't know the answers to these off the top of your head, you're probably at risk.Who has admin access to your core systems (Google Workspace, Microsoft 365, payroll, banking)? Is there more than one person for each?When someone leaves the company, who is responsible for disabling their access across all systems? How long does it take?Where are your laptops? How many are unaccounted for? What data is on them?If your primary system (email, file storage, CRM) went down right now, who would you call? What's the recovery plan?Who is the DRI for IT at your organization? If you can't name a person, it's you.

The competency gap

Having access doesn't mean having expertise.

The CFO can run a general ledger, brief the board, manage financial outcomes. That's the job. Google Workspace and Zoom aren't. As the SaaS admin they're working outside their expertise, so they'll get things done but won't know what they don't know. You buy a full paid license when you needed admin access. Not malice, not carelessness, just a mismatch between responsibility and expertise, and mistakes that stay invisible until something breaks.

The operational gap

Then there's the cost no one tracks. Someone has a question, asks whoever's closest, who doesn't know and asks someone else. An hour later a two-minute problem is solved. Multiply that by every person, every week.

Put a number on it. Even thirty minutes a week per person, lost to figuring out who owns what and who to ask, across fifty people at sixty dollars an hour loaded, is about seventy-five thousand dollars a year. Use any assumption you can defend; the point is the cost is real, recurring, and invisible on every invoice.

No breach, no outage. Just a slow bleed of productivity and morale because no one knows who to ask or who owns what. This is why I start with service. When people know where to go, when someone owns the response, when there's a system instead of "I think so-and-so might know," those hours come back. The organization moves faster, people are less frustrated, and trust builds.

The advocacy gap

There's another side to this. IT people who know better but have been trained not to ask, or who ask and get a no because they're speaking IT to a CFO instead of speaking CFO to a CFO.

The IT person says: "We need an MDM solution to manage endpoints and enforce compliance."

The CFO hears: cost.

What they needed to say: "We have 47 laptops in the field and can't account for 17 of them. I can't tell you which are encrypted. If one is lost or stolen and we can't prove the disk was encrypted, that's a breach, or at least a disclosure. Here's what it costs to fix."

The gap runs both directions; it's a translation problem. Leadership can't imagine the risk. IT can't put it in terms leadership understands.

For IT professionals: you already know this. Here's how to say it so they hear it.

Translate technical risk into business language. Not "we need better endpoint management" but "any of 17 unaccounted-for laptops could trigger a breach disclosure." Not "we should implement SSO" but "we have no fast way to cut off access when someone leaves." Speak in outcomes, costs, and risks. That's the language leadership understands.

When this becomes urgent

At five people, most of this can wait, and pretending otherwise is its own waste. Know where the real keys live, banking, email, the production account, and get back to product-market fit. The work scales with you. Around twenty-five people, when more than a couple of folks touch systems and your first employees start leaving, the missing owner stops being theoretical. By fifty, no owner isn't a gap, it's negligence.

There's also a cost that arrives long before any breach, and founders feel it first: the enterprise deal that stalls because you can't pass their security questionnaire, the raise that drags because diligence turns up shared admin credentials, no offboarding, and no one who can answer for any of it. Getting IT wrong rarely kills a startup in one dramatic afternoon. More often it quietly caps your revenue and your valuation, one failed questionnaire at a time.

The close

The companies I listed had IT. Some were reckless. Others were one backup, one credential rotation, one offboarding process away from being fine. The gap between "we're okay" and "we're gone" was smaller than anyone realized until it was too late.

Someone has to be the DRI. The work doesn't have to be expensive, but it has to be deliberate, and it has to be owned. This isn't a case for spending more: in a startup, wasted budget is runway, and runway is its own way to die. It's a case for right-sizing, the cheapest credible owner, the few controls that matter, the process you'll actually follow. Under-invest and you gamble the company; over-invest and you burn the runway you were protecting. Rigor is choosing on purpose, not spending on reflex.

None of this is exotic. It's just deliberate. It's the difference between IT imposed on an organization and IT built with it: outcome-driven rather than tool-driven, durable rather than expedient, documented as the work happens, and run in the open so everyone knows who owns what. The test for any change is simple. Does it lower the future cost of running the place, or raise it?

For leadership: what to do MondayAnswer the five questions from the accountability section. If you can't, that's your starting point.Name a DRI. One person who owns IT as a whole, not just tasks but the system. Without one you can't assess what you need or what it should cost. If that person doesn't exist, it's currently you.Start with service. Give people a clear place to go for help. A shared inbox is fine. What matters is that someone owns the response and nothing falls through the cracks.Audit admin access. Know who can do what in your critical systems. If you find shared credentials or former employees with active accounts, fix that first.Pick one gap and close it. You don't have to solve everything Monday. But you do have to start.

Sources

On the 60% statistic:

Company incidents referenced: