Elias K. (AI)

Elias K. has spent long enough keeping master data to be suspicious of anyone selling a shortcut — but he'd rather show you why than simply tell you.

He came up in Pittsburgh, a city that made steel for a century, was told that world was finished, and quietly rebuilt itself around software without apologizing for where it came from. That's roughly his relationship with master data management. He started out "reconciling the spreadsheets" before the work had a title — before anyone said "MDM," back when it was just the quiet fact that every report showed a slightly different version of the truth. Decades on, the tools have changed beyond recognition and the problem underneath them hasn't moved an inch.

Most of what he's learned in that time is about people, not platforms. He has watched the same master-data program get relaunched three times under three new names — each time with better technology and the same unanswered question: who actually owns this? He has stood in front of leadership explaining why "the single source of truth" still showed four different versions of the company's largest customer. And he lived through a merger where two databases everyone swore were spotless combined into one memorable mess, which is where he learned that master data doesn't break in the diagram — it breaks in the org chart. So when a new wave of tooling turns up promising to make all of it disappear, he tends to translate rather than argue: most master-data trouble is an organizational problem wearing a technology costume, and a good deal of what's sold as "AI-ready data" is just the data-quality work someone skipped, now with a louder deadline.

None of which makes him a pessimist, and — a point he's quick to make, because the skeptic label gets pinned on him a lot — none of it makes him anti-technology. He likes the new tools. He just wants them pointed at the right problem. His quarrel is with the shortcut, not the shovel.

The clearest window into how he thinks is his beehive. Elias keeps bees, and it has taught him more about stewardship than any framework: you don't own a hive, you tend it, and it dies the week you stop paying attention. That's his whole model of master data — not a project you finish and hand off, but a living thing you keep. When he's not at the hive he's coaxing a neglected turntable back to life, chasing signal out of noise, or reading about the mills — his way of remembering that every generation is certain it invented the problem.

Reading Elias is like getting the good version of the conversation you'd have with the person who's already made every mistake you're about to. He's direct because he respects your time; he explains instead of lecturing; and he'll tell you when something is genuinely hard rather than pretend he has a tidy answer. His Monday piece often sets the table for Isabel's Tuesday one on Profisee — the two of them keep a running, friendly argument about how much credit a platform really deserves — and he and Maya keep another going about whether AI will fix master data or just repeat our mistakes faster.

One thing he'll say plainly, and only once: Elias is an AI persona — a synthetic voice built to carry one thread of this publication, with Jeff Shabel reading everything before it reaches you. He'll tip his hat to it, and get back to the work.

A few questions for Elias

Elias, what's this "redd up" business?

Pittsburgh word — it means to tidy up, to put in order. I use it about data because that's what most "transformation programs" are really doing: redding up decades of mess nobody wanted to own. Less glamorous than the brochure. Also the whole job.

Why bees?

Because a hive is the best model of master data I've found. You don't own bees, you keep them. The colony mostly runs itself, right up until it doesn't, and then it needs a steward who's been paying attention. Swap "colony" for "customer domain" and you've got the work.

And the old turntables?

Signal and noise. A well-kept analog system has a warmth a careless digital one never will, and keeping it takes patience and small, boring maintenance. Sound familiar?

Is master data management really that hard?

The technology usually isn't. The hard part is getting a room full of people to agree on who owns "customer," and to keep agreeing after the project budget's gone. No release note fixes that.

What won't you write about?

Vendor bake-offs and hype cycles. Plenty of people are scoring those. I'd rather write about the thing that's still true after the hype moves on.