A hundred people making the same mistake isn’t a compliance problem. It’s a systems problem.

At one global enterprise I worked with, the branding was having a crisis. Every department, operating group, and regional team had their own version of the company logo. Some had their department name under it. Some had their operating group. Some had their team. The typography was inconsistent across all of them, and no single PR agency globally was in alignment with another.

And the colors were everywhere. The same logo ranged from fire engine red to pink depending on who made it and when.

The instinct was to treat this as a compliance problem. People aren’t following the brand guidelines. Send another memo. But when I dug into it, the root cause was technical, not behavioral. There was no approved RGB color specification and no digital master artwork. The brand guidelines had been built for print. When people needed the logo for a website or a presentation, they recreated it themselves and eyeballed the color. They weren’t being sloppy. They were working without a standard that fit the medium they were working in.

As part of a global SEO and brand realignment I was leading, I brought in a designer experienced in corporate brand guidelines at this scale and commissioned a streamlined set of standards built around the company’s identity priorities. We reduced the logo sprawl down to one master logo, two operating group variants, and a handful of controlled carve-outs for specific use cases like environmental branding, and a couple of regionally required variants that I recall.

Then my team built out a digital version of the brand guidelines with downloadable master artwork for every medium: web, letterhead, presentations. For web logos specifically, we created pre-sized assets at every standard dimension with a clear rule: if you need a size we haven’t provided, you contact Corporate Communications. You don’t make it yourself.

After rollout, I’d routinely spot-check logos across the company with an image editor’s color picker. Trust the process, but verify the pixels.

The lesson is the same one that shows up everywhere in operations: when a lot of people are doing the same thing wrong, the problem usually isn’t the people. It’s the system they’re working in. Make the right thing the easy thing, and you’ll spend a lot less time chasing the wrong thing.

Listening is one of the more critical diagnostic skills you can practice.

At one company I worked with, the support team kept getting tickets for their fax modem banks… busy signals, dropped connections, intermittent failures across the document ingestion system. The issue could last for hours if not longer at times.

And every time it happened, the team would review the hardware. They would check the intake software that controlled the modems, restarting the software controllers. They would pull logs and look for errors. Even testing equipment by running extensive self-checks. They usually found nothing wrong.

Then the problem would go away on its own, and apparently this had been going on for months.

One day it happened while I was in the room. I listened to the troubleshooting for a few minutes and asked one question:

“Has anyone called the number to hear what it’s doing?”

Blank looks.

I picked up a phone and dialed the line. Fast busy tone. Beep beep beep.

“The problem isn’t here. It’s at the exchange. Call the telco.”

An hour later the carrier opened a service investigation and found intermittent hardware failures on their end.

Months of tickets. Hours of internal troubleshooting per incident, and the final fix was simply getting it to the right people. Granted one of the guys asked me later how I knew what that kind of beep meant. I referenced past work at an ISP (oh, the skills you pick up over a career).

The instinct when something breaks is to look inward. Check your code, check your hardware, check your config. But sometimes the problem isn’t in your domain at all. And no amount of expertise applied to the wrong layer will get you there.

The diagnostic that matters most is often the simplest one nobody thought to run.

There’s a difference between managing a problem and solving it.

On a recent gig, I watched a support team chase the same category of ticket for weeks, drive space alerts on machines with 128–256GB system drives. The standard fix was to log in, clean temp files, move user data to network shares, and close the ticket. Rinse repeat. Daily ticket volume drove a quick resolution then move on.

At the management level where only the ticket class was seen there were comments of better education to the users on how to manage their data or to tell them not to keep so much work on their devices. There were also talks about larger drives or increased VM allocations. All of these are reasonable options to consider.

I looked at a handful of these systems myself and found an incorrect page file configuration in the standard deployment image. It was consuming up to 40% of the drive before the user even started working. On one system with a 128GB drive, the page file allocation alone was 96GB. Three quarters of the drive, before accounting for Windows, applications, or user data. Every machine deployed from that image inherited the problem.

In this case, one configuration fix addressed the source of the recurring tickets and freed up support time. No new hardware. No budget request.

The team handling this was working hard to help. Their cleanup work gave users enough room to get back to work. But every ticket treated as an isolated incident was another opportunity for the underlying problem to keep going. When the queue stays full, making room to investigate a pattern can be difficult. Yet that’s often where the biggest return is: asking why the same work keeps needing to be done.

A drive space alert that seemed like a generic user problem turned into a higher level technical problem, and when repeated across a fleet, it suddenly becomes a problem where you can calculate lost employee time, support overhead, and potentially an unnecessary hardware expense if resolved incorrectly.

That’s the connection I look for when I’m helping someone, and it’s been the pattern across my career. Get close enough to the systems (technical and human) to understand what’s actually happening, then connect the finding to what it’s costing the business and help deliver a solution to close the loop.

A career of work in infrastructure and technology leadership, and I still look under the hood.

I configured my server by the book. Ten AI models still couldn’t read my documents.

I set up a technical documentation bundle: eight markdown files, a PDF, a diagram source, and an llms.txt manifest with absolute URLs, token estimates, and a reading order. Correct MIME types. Validated headers. Clean UTF-8. Every URL resolves.

Then I asked ten commercial AI models, including frontier-class, to fetch the manifest and read the documents. Same server, same files, same day and none of them succeeded cleanly. Believe it or not, this was a step up from having them ingest from an HTML landing page with direct file links!

But, two couldn’t reach the server at all (blocked by their own infrastructure, not mine, although they both blamed my server). Two rejected every markdown file because their fetchers don’t accept text/markdown. The correct configuration makes content less accessible than serving the wrong type.

Four silently truncated the largest document. One stopped at 32 KB (13%). Another at 120K characters (49%). None knew they had partial copies with one exception: Claude Opus 5.1 (High) told me its parser only retained the first and last thirds of my document and asked me to resubmit. That’s the behavior I want to see but doesn’t help much in an unattended mode.

Four served cached versions despite headers requiring revalidation. Three models returned three different stale versions of the same file on the same day. Every one blamed my server. There was definitely a trend to blame me or my infrastructure when things failed and I’m not pleased with that. Either the models don’t have full visibility to their failure modes or they’re just hallucinating. The latter is probably the more dangerous though.

One decoded UTF-8 as Latin-1. Every diacritic destroyed. Not critical but still irritating. I’ve fixed that on my server to enforce decoding in the future.

One fabricated a finding… reported a file that doesn’t exist, cited footers that don’t reference it, and presented invented observations alongside real ones at identical confidence. This set off a scramble to figure out if a stray error had gotten into the text somehow, but it ended up being a confabulation based on a phrasing expanded to imagined content.

The dangerous failures were silent. Truncation, caching, encoding corruption, and fabrication produced no errors. The model answers confidently from whatever it retrieved, and nothing in the output tells you retrieval failed.

The industry sells “give it a URL” as a core capability. For most models on most documents, it isn’t as reliable as opening the link in a browser. And you can’t tell from inside the conversation unless you’re actively probing secondary to whatever it is you’re actually trying to get done.

If you’re building an llms.txt: the format works. The implementations don’t. Plan for rejected MIME types, ignored headers, silent truncation, and stale caches. Verify independently and across models.

I’ve been talking with smaller construction firms at local meetups lately, and the energy around AI is genuinely exciting. Owners are automating proposals, generating scripts, pulling data out of documents faster than ever. The enthusiasm is real, and a lot of what they’re building is legitimately impressive.

But I keep noticing the same gap, and it’s one I’ve seen play out time and again over the years.

There’s a meaningful difference between ”an AI can write a script” or “configure your settings” and “an AI can architect, secure, and maintain a production environment.” That’s not a knock on anyone’s intelligence or the tools. It’s just that most smaller firms have never needed to think at the enterprise level before and any professional IT experience they’ve encountered was probably on the user side of someone else’s environment. AI is quietly pushing them into territory that looks and feels genuinely good.

What I’m watching happen though is firms handing the keys for a sports car to an algorithm that doesn’t know what a brake pedal is, simply because the car goes fast.

Here’s what that looks like in practice:

When you swap reliable, deterministic software for a chat-based AI workflow, you’re introducing a system that can fail in ways that don’t look like failures. It doesn’t throw an error code. It just confidently gives you the wrong number on a bid, or silently drops a compliance document, or racks up compute costs that don’t show up until the invoice hits. And if nobody on the team knows what a failure state looks like in that stack, nobody catches it.

The owners I talk to think they’re saving on headcount. What they’re actually building is invisible technical debt. The kind of debt that can surface as a legal exposure or a cost blowout on exactly the wrong project.

And I get the appeal. These tools are incredible. They’re validating in a way that most software never has been. They give you a sense of command over problems that used to feel out of reach. That feeling is real! But it’s not the same thing as a sound architecture.

AI is a fantastic tool for generating code, pre-visualization, drafting documents, and accelerating work you already understand. It falls apart when you ask it to be the architect, especially when nobody on the team actually knows what an enterprise IT architecture even looks like, let alone how to maintain one. That’s when you lose the person in the loop who knows when to step in, redirect, or just say “no, we’re doing this the boring reliable way.”

So if you’re a construction firm leaning hard into AI right now, here’s my honest ask: get a technical review. Not from your AI vendor. From someone who’s built and maintained production infrastructure. Have them look at where your AI tools touch your actual operations… your bids, your compliance docs, your financials, and map out where a silent failure would hurt you most.

You don’t need to slow down. You just need to know what you’re standing on.