The disconnect between IT and leadership (and what it actually costs)

We recently did a technical assessment for an industrial equipment company. The owner is smart, runs a good business, and knows his industry inside and out. From where he sits, the technology works. The e-commerce site takes orders. The quoting system sends quotes. The sales dashboard shows numbers. Everything functions.

When we opened the hood, we found six critical security vulnerabilities. Live API tokens exposed in the codebase. Authentication that could be bypassed with a forged cookie. Checkout endpoints sitting wide open. Customer data committed to version history where anyone with repository access could read it. SQL injection holes in the quoting pipeline. And a broken integration with their accounting software that meant the sales numbers the owner was using to make business decisions were wrong.

The owner didn't know about any of it. Not because he's careless, but because none of it was visible from his chair. The systems appeared to work. The problems were all underneath.

This is the disconnect we're talking about. It's not that leadership doesn't care about technology. It's that the most dangerous problems in a technology stack are invisible to anyone who isn't looking at the code.

Why leadership can't see it

If you run a business and your software works, you have no reason to think it's broken. The login page loads. Customers place orders. Reports generate. From a business perspective, the system is doing its job.

But "it works" and "it's healthy" are completely different statements. A building can have termites for years before anything visibly changes. The floors feel solid. The doors open and close. Everything looks fine right up until the day a support beam gives out. Software works the same way. The decay happens in places you can't see from the outside: in exposed credentials, in authentication gaps, in integrations that are quietly returning bad data, in code that only one person on earth understands.

The owner of that equipment company used his sales dashboard every day to make decisions about inventory, pricing, and strategy. He didn't know the QuickBooks integration feeding that dashboard was broken. The numbers looked reasonable enough that there was no obvious sign anything was wrong. He was making real business decisions based on data that wasn't accurate.

The bus factor problem

Here's a question that makes a lot of business owners uncomfortable: if your most technical employee quit tomorrow, how long would it take before something broke that nobody could fix?

In that equipment company's case, the answer was "immediately." One developer had built and maintained the entire technology stack. The e-commerce platform, the quoting system, the inventory tools, the sales dashboard, the integrations with accounting and marketplace platforms. All of it lived in that one person's head. No documentation. No second person who understood the architecture. No runbook for what to do when something went wrong.

This is called the bus factor, and it's one of the most common risks in small and mid-size businesses. If the number of people who understand a critical system is one, you don't have a technology asset. You have a liability disguised as one. The system works today because that person is here today. The moment they're not, whether they quit, get sick, go on vacation, or just decide to stop answering their phone, the business is stuck with software nobody else can maintain, debug, or safely change.

The uncomfortable truth is that the owner usually knows this, at least in the back of their mind. They just haven't had time to deal with it. Running a business takes all the bandwidth you have, and "document the systems in case someone leaves" never feels as urgent as the next sale, the next hire, or the next fire that needs putting out.

What's actually hiding in the code

When we do assessments like this, the same categories of problems show up over and over. Here's what leadership typically doesn't know about:

Security vulnerabilities that are already live. Exposed API tokens, hardcoded credentials, authentication that can be bypassed, endpoints that accept requests from anyone. These aren't theoretical risks. They're open doors that exist right now, today, in production systems that real customers are using. The IBM 2025 Cost of a Data Breach Report puts the global average breach cost at $4.44 million. For a small business, even a fraction of that is devastating.

Broken integrations returning bad data. Your systems talk to each other: your e-commerce platform talks to your accounting software, your CRM talks to your email system, your inventory tool talks to your marketplace listings. When one of those connections breaks or drifts, the data flowing through it goes wrong. But because the interface still loads and numbers still appear on the screen, nobody notices. The owner keeps making decisions based on reports that look fine but aren't.

Tribal knowledge with no backup. Critical business logic lives in one person's head. Configuration details that aren't documented anywhere. Workarounds that were never written down. Deployment procedures that only one person knows how to run. If that person disappears, the business doesn't just lose an employee. It loses the ability to operate its own technology.

Technical debt that compounds silently. Every shortcut, every "we'll fix it later," every quick patch that bypasses the proper solution adds to a pile of work that gets more expensive over time. New features take longer to build. Changes break things they shouldn't. Simple updates become risky because nobody's sure what else they'll affect. The business feels this as slowness and frustration, but leadership often attributes it to the team rather than the codebase.

Why the gap exists

This isn't a problem of bad leadership or bad IT. It's a communication problem, and it runs in both directions.

Technical people tend to describe problems in technical terms. "The OAuth token refresh flow is broken" doesn't mean anything to a business owner. What it means in business terms is "your accounting data is wrong and you're making decisions based on bad numbers." But that translation often doesn't happen, so the owner hears jargon, files it under "IT stuff," and moves on to the next thing that needs their attention.

Leadership, on the other hand, tends to evaluate technology the way they evaluate everything else: by results. Does it work? Are customers complaining? Is revenue being affected? If the answers are yes, no, and no, then the technology must be fine. The problem is that security vulnerabilities, data integrity issues, and bus factor risks don't show up in those metrics until something goes catastrophically wrong.

The result is a gap where both sides think things are okay for different reasons, and neither has the information they need to see the full picture. The technical person knows the problems exist but can't communicate their business impact. The business leader doesn't know the problems exist because they're not visible in the metrics they watch.

Five signs your company has this disconnect

Only one person understands a critical system. If you catch yourself thinking "we'd be in trouble if [name] left," that's not a staffing concern. It's a systems risk. And it's almost certainly worse than you think, because the person who understands the system is also the person least likely to tell you how bad the situation is.

Integrations break regularly and get manually patched. Someone on your team spends time each week re-syncing data between systems, manually fixing records that didn't transfer correctly, or working around connection failures. This feels normal after a while, but it's a sign that the underlying integrations are failing and nobody has fixed the root cause.

You avoid updating or changing systems because you're afraid something will break. If the response to "can we add this feature" or "can we update this software" is hesitation and risk assessment, the codebase is fragile. Healthy software can be changed without fear. Unhealthy software makes everyone nervous.

Your team works around software problems instead of fixing them. Spreadsheets that exist because the reporting tool doesn't show the right data. Manual steps that exist because an automation broke months ago and never got repaired. Copy-paste workflows that exist because two systems that should talk to each other don't. These workarounds become invisible over time, but they're all symptoms of underlying technical problems that are getting worse.

Nobody has done a security audit in over a year. Or ever. If you don't know the last time someone looked at your systems specifically for security vulnerabilities, the answer is probably "never." And given how fast threats evolve and how frequently credentials get accidentally exposed, that's a gamble.

What to do about it

The fix isn't to learn to code or to start attending standup meetings. The fix is to get an independent technical assessment from someone who can translate what they find into business terms.

With the equipment company, that's exactly what we did. We spent a week going through every repository, every integration, every deployment. We cataloged every vulnerability, every broken connection, every piece of tribal knowledge that wasn't documented. And then we translated all of it into a report the owner could actually use: here's what's critical and needs to be fixed this week, here's what's important and needs to be fixed this month, and here's what can wait.

The result was a four-week engagement focused on the highest-impact problems. Security vulnerabilities remediated. Broken integrations reconnected with proper authentication. Documentation written so that the bus factor went from one to something sustainable. At the end of it, the owner could see his own technology clearly for the first time, and he had a system that didn't depend on any single person to keep running.

The total cost was a fraction of what a single security incident would have cost. And more importantly, the owner stopped making business decisions based on data he didn't know was wrong.

The conversation to have

If any of the five signs above rang true for you, here's the conversation worth having with whoever manages your technology:

"If you left tomorrow, what would break? What would nobody else know how to fix? Where are the biggest risks I don't know about? And what would it take to get an independent set of eyes on this?"

That last part matters. The person inside your organization who built the systems is often the worst person to assess them objectively. Not because they're dishonest, but because they're too close. They know the workarounds so well they've stopped seeing them as problems. They've been living with the risks so long they've normalized them. An outside assessment sees the full picture.

Frequently asked questions

Why do business leaders miss IT problems?

Because the problems are invisible until something breaks. A system with exposed credentials, failing integrations, and a bus factor of one still looks like it works from leadership's perspective. The sales dashboard loads, orders process, reports generate. The decay is happening underneath in ways that only surface during a security incident, a key departure, or a failed compliance audit.

What is the bus factor in software?

The bus factor is the number of people who would need to leave before a critical system becomes unmaintainable. A bus factor of one means a single person holds all the knowledge about how a system works. If they leave, the company is stuck with software nobody else can maintain, debug, or safely modify.

How do I know if my company has hidden technical debt?

Five warning signs: only one person understands a critical system, integrations between tools break regularly and get manually patched, you avoid updating or changing systems because you're afraid something will break, your team works around software problems instead of fixing them, and nobody has done a security audit in over a year.

What does a technical assessment cost?

An independent technical assessment for a small to mid-size business typically takes one to two weeks and surfaces critical vulnerabilities, integration failures, and knowledge concentration risks before they become emergencies. Reach out and we'll scope one based on your specific systems.