Fair enough. But four issues of that starts to sound like a man who thinks nothing works.

So this month I want to go the other way, and I'll tell you now — none of the things that worked were the exciting ones. Starting with the least exciting project I have ever been part of.

Macro-heavy spreadsheets. PDFs. And the largest category by far, the one that wasn't in any file at all: tribal knowledge. Things a handful of people simply knew, and had known for so long that nobody had thought to write them down.

Upon completion, that project returned more than twelve million dollars in new sales.

Start with the customer, because that's where this (no, everything really) actually begins.

A customer, replacing a legacy product, needs to know one thing: which current product replaces it, and what will be different. That's the whole question. It is not a hard question. It has a correct answer.

Here is what asking it used to look like:

They'd call customer care, because that's the number on the website.

Customer care maybe couldn't answer it (not through any fault of theirs, the answer simply wasn't available to them), so they'd transfer the customer to technical services. Or to inside sales. Or to a district manager. Depending on the day and who picked up, the customer, who wanted one fact, would instead get a tour of our organizational chart.

That's the part that made people angry. Not the wait. The handoffs. Nobody calls a manufacturer hoping to meet four departments — every warm transfer is a customer being handed your org chart and asked to navigate it themselves.

Because the answer was real, but it wasn't anywhere a person could reach.

It lived across a matrix of macro-heavy spreadsheets and PDFs that had to be cross-referenced and deciphered to produce a single recommendation. Even the people whose job it was found it slow going, and customers who tried to work it out from published material were frequently confused by it. The information was there, technically, and it was nearly impossible to identify what applied to you.

And it was frequently never kept up-to-date.

So the real answer was a reconciliation: the documents, plus whatever a long-tenured person happened to know about which parts of them were still true. That's what tribal knowledge actually is, most of the time. Not secret expertise. A correction layer people carry in their heads because nobody maintained the source.

Here's the detail I still think about: The person everyone deferred to for that correction layer had been there for years and was also one of the least technology-comfortable people in the building. They didn't care for computers. Used what they had to, because the job required it, not because they trusted it.

They were also the one person who reliably knew which parts of thirty years of files were still true, and it wasn't only in their head. They kept working files — a record of what was actually current, maintained on their own schedule, in their own way. Those notes were frequently more accurate than anything the rest of the company had. They also frequently never left the desk. Other teams didn't know that shadow records existed, so they kept working from documents they had no way of knowing were already wrong, while the corrected version sat somewhere else.

Sit with that for a second, because it cuts against the story we usually tell ourselves. The most valuable knowledge asset in the company wasn't held by whoever was most fluent with the tools, and it wasn't centralized even in the one place you might expect it — one person's head. It was scattered a second time, privately, inside the correction itself.

Tenure beat tooling, every time somebody actually needed the real answer.

Nobody had gotten around to asking whether tenure was sharing what it knew. The company knew the answer. No single person did except the person with the tribal knowledge. But even their own records didn’t reliably reach other teams, and no customer could get to any of it.

We consolidated all of it — spreadsheets, PDFs, the corrections that had only ever existed in conversation, and one person's private working files that nobody else had access to into one maintained source, turned it into an application, and put it directly on the e-commerce site.

The customer searches for what they have, what recommendations replaces it, and a highly visible marked icon calling out exactly what's different between the two. In the buying flow. At the moment they're deciding.

No call. No transfer. No waiting on the one person who knew.

Customers loved it, and I don't mean that as a figure of speech — we have it on recorded calls.

Unprompted praise, from buyers, about a parts lookup!?!

I've worked in this industry a long time and I can tell you that is not a sentence I expected to write.

Here's the part I find more interesting than the money.

Nothing about this was technically hard. No model to train, no platform to select, no architecture worth arguing over. Any competent team could have done it in any of the preceding thirty years.

Nobody did, and I don't think that's an accident. A file-consolidation project has no demo. You cannot put it in front of a steering committee and watch anyone lean forward.

It's the exact inverse of issue #10's chatbot. That one demoed beautifully to decision-makers and got rejected by the people who had to use it. This one was impossible to demo the art of the possible and the users adored it. The demo and the job are different audiences, and they disagree more often than anyone wants to admit.

Not the budget. Not the technology. The customer-facing team.

Here's what makes this story sting. This is the exact tool that teams had been asking someone to build for years — long before I ever started, and for several years after. A straightforward guide, easy to administrate, so the data was kept up-to-date, a customer wouldn't have to guess, and a rep wouldn't have to field the same question for the thousandth time. Nobody built it earlier, because the pieces that made it possible hadn't come together yet. Then they did, and I led the teams putting them together.

You'd think that's the happy ending. The thing they'd spent years asking for, finally built.

It wasn't.

They were invited in at the start. They declined — and not quietly. They didn't agree the project should be undertaken. They didn't see a need for it. They said it would fail. This, for the tool they had been requesting for years.

So Phase 1 got built without them. Then it shipped.

Customers started praising it on recorded calls. Real revenue moved — the exact outcome all those years of requests had been aimed at. Nobody argued with the numbers. The complaints that came back were about the paint color. Literally: design choices. Nothing that touched whether the thing worked.

Then Phase 1 kept succeeding. That's when they insisted on changes — not because the objection had ever been about the results, but because the results were now impossible to ignore. They got their seat. What they did with it: hand over requirements, then step back. No testing. No work with the other teams building alongside them.

I'm not going to pretend that's a structural inevitability nobody could have anticipated. It's a recognizable pattern, and it has a shape worth naming, because it will happen to you:

Opposition before, ownership after.

The people most likely to contest credit for a success are frequently the ones who declined to carry any of the risk of it failing. That's not cynicism, it's arithmetic :

What sharpens this version past the ordinary turf story is that the objection was never really to the idea. They'd been asking for the idea for years. The objection surfaced only once somebody else built it.

What I'd do differently is still not include them; they were asked to be included and refused the first go-around. I would however document the refusal. Not as ammunition — as memory. Write down who was asked, when, and what they said, and keep going. Costs nothing at the time. It is worth a great deal on the day the history of the project begins to be rewritten by those who weren't there to see it happen.

The work still shipped. The revenue was still real. But I spent time, a lot of time, defending the origin of a successful project that I should have spent extending it, and the only reason that was possible is that the record lived in my memory instead of in writing.

It didn't end there, either. The credibility gap outlived the project. Every effort since then to modernize what that group had grown comfortable with — whether a new interface, a new workflow, or a faster way to reach the same answer — has had to climb the same hill, dragging the same weight: a doubt that was never really about the technology.

I've spent this year building systems to evolve from legacy comforts, so I'll say the uncomfortable thing plainly: A great deal of what AI or digital evolutions are being asked to do right now is compensate for data nobody organized.

Point a model at scattered spreadsheets, stale PDFs and undocumented tribal knowledge and it will produce confident answers assembled from an incomplete picture — which is issue #12's problem wearing a different costume.

Fix the foundation first and you frequently discover you needed less intelligence than you thought. Some of what looks like an AI opportunity is a filing problem with better marketing.

Before you fund the next interesting thing, one question:

Not “What could we build?” What already exists — records, history, equipment in the field, knowledge in three people's heads that isn't queryable by anyone who needs it. That list is usually short, usually boring, and in my experience it is where the highest-return work of the next two years is sitting.

Four Tuesdays of failures, then this: one of the best-returning projects I've been a part of.

I'll go further:

The broader push this project was part of is going to turn out to be one of the highest-return decisions this business makes for years.

Plant Floor to Cloud goes out every Tuesday. A monthly companion podcast comes later in the month — same charter, more room to think out loud.

What do you already own that you can't currently see? Reply, I read every one.