I've seen this pattern enough times to name it: The worst software calls in an org rarely come from the people who'll use the tool. They come two or three levels up, from someone who heard a name in a meeting, heard that competitors use it all the time and now are eager to put their crew through hell and overthrow an entire operational workflow established over several years just to rebuild the entire structure from scratch with patches that look more like something MacGyver put together with bubble gum and paper clips just because that tool was hyped up to be the answer to all their preyers.

It tends to go like this:

1. Someone senior hears a product name -- > A webinar, a vendor pitch, a peer at another company. It *sounds* right. They read the homepage tagline, not the docs.

2. The name travels down as a decision, not a suggestion. By the time it reaches the team, it's "we're using X for this now" — not "would X even work?"

3. Nobody checks the category. This is the one that actually hurts. Software lives in categories, analytics, field and ops service, CRM, project management and they do NOT cross over. A marketing-analytics tool will never send a work order. A dashboard will never dispatch a crew. But the name *sounded* operational, so in it goes.

It can get absurd, tools picked that are literally one letter off from the product someone actually meant. Different company, different category, different everything, chosen purely because the names look alike. Weeks get burned forcing the square peg before someone finally says "Wait this doesn't even *have* that feature we actually need?" Because people who actually have to use it daily are not being consulted or not involved in the process.

The pattern underneath: Leadership optimizes for *making a decision*, the team optimizes for *the work getting done*.

Those aren't the same goal. A choice made off the homepage feels like progress. It's just deferred pain — handed to whoever has to use it.

>Here's where I've landed, and it's the part that's shifted for me this past year:

**When the off-the-shelf tool is a mismatch, you're not stuck picking the closest wrong thing anymore. You can build the exact right thing or at least develop the MVP to understand what the requirements are.**

I heavily use Claude Code for this, not because it's magic, but because it collapses the gap between "the tool we were told to use" and "the tool the work actually needs":

1. It builds to your workflow, not the vendor's.** The work order form has the fields your team actually fills out — not 40 generic ones with the 3 you need buried somewhere.

2. No per-seat licensing, no category lock-in.** The mismatched enterprise tool is often $5k–$20k/yr. A focused internal tool you own is just the time it takes to build it.

3. You ship a working v1 in a day, not a procurement cycle.** Describe the real job — "field crew gets a work order with site, date, materials, status" — and you've got something running before the vendor returns your demo request.

4. It explains every decision as it builds**, so the person who owns the tool actually understands it instead of inheriting a black box nobody can change.

TL;DR So if your team's about to adopt something because the name sounds right — pull up the actual feature list first and ask one question: *does this tool do the literal thing we need, or does it just sound like it?* Half the time the honest answer sends you back to building it yourself.

And the irony is: The tools leadership grabs to "save time" usually cost more time than building the right thing would have. The category was always the problem. The name was never the answer.

Anyone else had a front-row seat to a tool getting picked by name and category-confusion? Curious whether this is as universal as it feels.

Last night I spent two hours trying to get AI to post images to my WordPress blog.

After going down every rabbit hole imaginable, I finally gave AI one instruction:

"Give me the simplest, most foolproof solution. No clever hacks. No elaborate Python. Pretend I'm exhausted and just want the thing to work."

It did.

That somehow turned into a conversation about all the little pieces of tribal knowledge every IT veteran collects over the years.

So consider these AI-assisted, human-approved, and field-tested against production.

Operator Maxims

1. The phrase "all you have to do is..." is the leading cause of undocumented technical debt.
2. Never confuse motion with progress. Six months of meetings is not a project. One working prototype is.
3. The first AI answer is a junior technician: useful, confident, and occasionally spectacularly wrong. Review accordingly.
4. If three AI models agree, verify anyway. Consensus is not evidence.
5. Every five-minute tutorial secretly contains four hours of prerequisites.
6. If the tutorial begins with "Obviously...", clear your afternoon.
7. Documentation is an apology to Future You. Be kind. Future You already has enough problems.
8. Never memorize what you can document. Memorize judgment instead.
9. Everything is a cable until proven otherwise.
10. When troubleshooting exceeds two cups of coffee, go outside and observe something that does not require overclocking your brain's CPU.

That's about 25 years of enterprise IT, a lot of coffee, several AI conversations, one dumpster fan, two squirrels who still think I'm holding out on the peanut inventory, and I generated enough profanity to train the next large language model.

AI assists. Humans approve. Operators document the parts everyone else forgot.