Fractional CIO interview: why most technology failures are decisions nobody owned
Most enterprise technology failures are not technical. They are decisions nobody owned — and in small and mid-size companies the stack was never designed, it accumulated. In this fractional CIO interview, Kevin M. Coles explains why better tools will not fix that, and sets out the decision discipline that does.
Coles Technical Group
Coles Technical Group is Kevin Coles’s advisory practice, working as a fractional CIO for small and mid-size companies. Its focus is the layer above tooling: which systems a company runs, who owns each decision, and whether the architecture was designed or simply accumulated.
That positioning is the argument. A fractional CIO sees many companies from the inside and notices the same pattern — stacks that grew one renewal, one free trial and one “just turn it on” at a time, with nobody accountable for the shape of the whole. This fractional CIO interview treats that as an engineering problem with an ownership solution rather than a procurement problem with a tooling solution.
Kevin M. Coles
Kevin M. Coles is the Founder and Principal of Coles Technical Group, working as a fractional CIO.
His argument is deliberately untechnical: most enterprise technology failures are not technical failures, they are decisions nobody owned. In small and mid-size companies the stack was never designed; it accumulated. And AI is about to make that worse, because vendors are switching on AI features inside tools companies already pay for — so the architecture decision gets made by a product update rather than by anyone in the building. This fractional CIO interview tests that claim against mechanism rather than opinion.
He also challenges the obvious remedy: better tools do not fix this. What fixes it is a decision discipline — one named owner per system, a reversibility test before anything is signed, and treating identity and data as the things you must always be able to move. Readers will come away with a clearer view of the shared dependency trap, of how to test whether a system can actually be left, and of six non-technical questions that reveal in ten minutes whether a company’s technology is being run on purpose or by accident.
Unowned decisions
Q1. In one line, why are most enterprise technology failures decisions nobody owned rather than technical failures?
KMC: Because the tech almost always did what it was set up to do. Nobody owned the decision about what it should be doing.
Q2. What is the mechanism by which a stack accumulates rather than gets designed — and what makes it so hard to see from inside?
KMC: It builds up one reasonable call at a time. Somebody needs something, buys it on a card, and it works. A vendor throws a feature into a renewal. Someone makes a spreadsheet to cover a gap, and three years later the business runs on it. Every one of those made sense when it happened. Nobody was ever responsible for how they all fit together.
It’s hard to see from inside because nothing’s broken. There’s no outage that makes anybody stop and look. And everybody only sees their piece. Finance sees the charges, IT sees tickets, ops sees the workflow. Nobody can draw the whole thing, and if you can’t draw it, you’re not really running it.
Accumulation and AI
Q3. Vendors are switching on AI features inside tools companies already pay for. What does that change architecturally, and who is actually making that decision?
KMC: It changes a lot without anybody noticing. Your data is going somewhere new, the software can now do things on its own it couldn’t before, and whoever turned it on just gave it their access. An email summary feature reads every inbox it can reach. Nobody bought anything, so it never went past anyone.
Who’s deciding? Mostly the vendor, through the default settings. Then an admin clicks through a release note. The owner usually finds out later, if at all. The way I look at it, if a system starts doing something different with your data, that’s a new decision even if you didn’t pay a dime for it, and somebody needs to own it.
Q4. Why is “should we use AI?” the wrong question — and what should a company ask instead?
KMC: Because you’re already using it. Your people are using it, and your vendors are turning it on whether you said yes or not. That question is done.
What I’d ask instead is where you’re okay with AI touching your business. Which data, which decisions, which customer conversations. Who signed off on that, and how would you even know if it went sideways. Pick the uses, put a name on each one, decide what data stays out, and look at it again in a few months. That’s more than most companies have, including plenty that are paying for enterprise licenses.
Decision discipline
Q5. What does “one named owner per system” mean in practice, and what measurably changes once it is assigned?
KMC: One person’s name next to each system. Not a department, not “IT.” One person who answers for it: who has access, what it’s hooked into, what it costs, when it renews, and whether it should still be there.
The biggest change is that questions stop bouncing around. Before, a question goes from IT to finance to ops and nobody really answers it. After, you ask one person. Renewals stop sneaking up on you because somebody is actually watching the date. When people leave, their access actually gets pulled. And when something breaks, you’re not burning the first hour figuring out whose problem it is. It’s not less work. It just stops falling through the cracks.
Reversibility Test
Q6. Walk us through the reversibility test — how long it would take to leave, what a day without it costs, whether the backup is truly independent. How do you actually run that test before signing?
KMC: It’s three questions before you sign anything that would hurt to undo. How long would it take to get out? What does a day without it cost? Is the backup really separate from the thing it’s backing up?
I want those answers in writing, not from the sales rep. How does the data come out, in what format, what does it cost, and how long did it actually take the last customer who left. Then figure out what stops if it’s down for a day, put a number on it, and see what the contract really promises. Then trace the backup and make sure it isn’t sitting on the same account, the same login or the same vendor.
A bad answer doesn’t mean you walk. Maybe you negotiate the exit, shorten the term, or take the risk knowing you’re taking it. The point is you don’t sign blind.
The shared dependency trap
Q7. Explain the shared dependency trap: redundancy that is not redundancy, because both sides sign in through the same identity layer. What is the failure mode, concretely?
KMC: It’s when you think you have a backup and you really don’t. On paper you have two systems, but they both log in through the same place, or one admin account runs both, or it’s the same vendor underneath. So it’s really one thing that can fail.
And it fails the way you’d expect. The login provider goes down, somebody gets into that admin account, or the vendor locks the account over a billing problem. Both sides go down together, or both are wide open to the same person. Your backup is behind the same locked door as the thing that broke, and you usually find that out in the middle of the exact incident the backup was supposed to save you from.
Q8. How do you detect a shared dependency you did not know you had?
KMC: Take everything you rely on and figure out three things: how people sign into it, who has the top admin account, and where it actually runs. Draw it out. A napkin is fine. Anywhere two things you thought were separate share one of those, you found one.
Then take whatever is at the bottom of that drawing and ask what happens if it’s gone tomorrow. A lot of companies find out their email, files, backups and remote access all hang off one login, sometimes one admin account that one person or one outside company holds. The quickest test is just asking who controls the top account for your domain and email. If nobody knows, that’s your answer. Whoever has that has everything.
Identity and data
Q9. You say identity and data are the things you must always be able to move. What does “able to move” require technically — and what usually blocks it?
KMC: Because if you have those two, you can rebuild everything else. To actually be able to move them, a few things have to be true. You own the domain and the top admin accounts, not your IT provider. Your users and their access live somewhere you can export, not baked into one app. Your data comes out in a format you can use, with the history, not a summary report. And somebody has actually done the export. Not read that it’s possible. Done it.
What gets in the way usually isn’t the technology. It’s a contract that makes leaving painful, a provider holding the keys, a pile of custom setup nobody wrote down, and the fact that nobody has ever tried. If you’ve never tested it, you’re just hoping.
The ten-minute diagnosis
Q10. Walk us through the six non-technical questions. What does a bad answer sound like, and what does a good one sound like?
KMC: These are the first six things I ask, and you don’t need to know anything technical to answer them.
1. Who decides what technology gets bought? Bad: whoever had the company card that day. Good: one person, by name, who says yes before anything new comes in.
2. Who has the keys? Meaning the top admin account for email and whoever owns the domain. Bad: “I think the IT company has it,” or someone who left three years ago. Good: the company has it, by name, and there’s a backup.
3. What’s the spreadsheet? Bad: there’s one doing real work on one person’s laptop and you didn’t know it existed. Good: you know about it, and somebody owns it or it’s being replaced.
4. What are you paying for every month? Bad: things nobody remembers buying, two tools doing the same job, licenses for people who left. Good: every charge has a reason and someone who answers for it.
5. What one outage stops you from making money, and what’s the plan? Bad: no plan, or “the IT company handles that.” Good: you can name the system, what happens in the first hour, and who makes the call.
6. If your most important system had to be replaced next year, how long would it take you to know what you’d lose? Bad: “I’d have to ask someone.” Good: you know who really understands it, what it feeds, how the data gets out and when it renews.
If you can answer all six, you’re running it on purpose. If you can’t, now you know where to start.
Putting the thesis to the test
Q11. What would prove you wrong — is there a case where a deliberately undesigned stack is the right call for a small company?
KMC: Yeah, there is. If you’re five or ten people trying to figure out whether the business even works, don’t design anything. Buy good tools month to month, move fast, and swap them out when they don’t fit. Governance at that stage would cost you more than the mess does.
Two things I’d still never skip. Own your domain and your admin accounts, and make sure your data can come out. That’s cheap to do early and really expensive to fix later. Once you have people depending on systems they didn’t pick, customer data in a bunch of places, or contracts longer than a year, the mess isn’t speed anymore. It’s debt.
Q12. What is the strongest argument against “better tools don’t fix this”, and how do you answer it?
KMC: The best argument is that the tools have gotten a lot better. Access reviews, audit logs, cost dashboards, export buttons, AI guardrails, it’s all built in now. So why not let the tools handle it?
Because every one of those still needs somebody to decide something. An access review doesn’t help if nobody owns the answer. A cost dashboard doesn’t save anything if nobody acts on it. An export button doesn’t matter if nobody tried it before the renewal. I’m glad the tools are better, because it makes good decisions cheaper. They still don’t make the decision for you.
TechRecast Analysis (The Recast)
The Shift in Context — Small and mid-size companies rarely design a technology stack; they accrete one. Each renewal and free trial is locally rational, and the aggregate is nobody’s decision. AI features arriving inside existing subscriptions accelerates this, because the architecture changes without a procurement event — which is where this fractional CIO interview sits.
Why This Interview Matters — Most technology commentary assumes the fix is a better tool. This conversation argues the fix is ownership and reversibility — which are unglamorous, cheap, and rarely discussed because nobody sells them. The framing also gives smaller companies a vocabulary for a problem they experience but cannot name.
Technology Perspective — The technical crux is dependency you cannot see. Two vendors look redundant until you discover both authenticate through the same identity provider, at which point the redundancy is cosmetic. The reversibility test and the “identity and data must be movable” principle are both attempts to make that dependency visible before it matters.
Business and Market Perspective — The commercial logic is that switching cost is the real lock-in, not licence price. A tool you cannot leave has a different economic weight than one you can, and most buying decisions do not price that difference. AI features switched on by default raise the cost of leaving without raising the price.
Leadership Perspective
A fractional CIO’s vantage point — many companies, limited tenure, no permanent empire — is unusually well suited to seeing accumulated architecture as a pattern rather than a one-off. The relevant lens is whether the six-question diagnostic is genuinely usable by a non-technical leader or is really a sales instrument.
The Counterpoint — A fair sceptic would argue that small companies have neither the budget nor the leverage to impose decision discipline on vendors; that some accumulation is rational when speed matters more than architecture; and that a diagnostic framed as six questions risks being a lead-generation device. On this view, the principle is sound but the prescription assumes authority the client does not have. This is the strongest opposing case and deserves a direct answer.
What Comes Next — Watch three signals: whether identity portability becomes a standard procurement requirement, whether AI features switched on by default attract contractual scrutiny, and whether “who owns this system?” becomes a routine board question at smaller companies.
Industry Outlook — If Coles is right, technology governance at the small end tightens around ownership and exit costs, and vendors face harder questions at renewal. If he is wrong, accumulation continues, and the cost shows up later as an inability to leave a stack nobody chose.
Key Takeaways
1. Most enterprise technology failures are decisions nobody owned, not technical failures.
2. Small and mid-size stacks accumulate one renewal and one free trial at a time, without ever being designed.
3. AI features switched on inside existing subscriptions change the architecture without a decision being made.
4. Better tools do not fix this; ownership and reversibility do.
5. The shared dependency trap makes redundancy cosmetic — both sides signing in through one identity layer.
6. The strongest counter-argument is that small companies often lack the leverage to impose this discipline on vendors.