We were half an hour into arguing about a technical choice when the architect stopped and named it. We're violently agreeing, he said.
He was right. We sounded diametrically opposed. We were fighting over the last few percent of a decision that didn't matter—two roads to the same place. So what was the argument actually about? Not the tool. But who gets to decide. Whether a choice gets written down so we can move on, or whether someone iterates on their own version, litigating decisions later once something is working. The technology was just the surface. Authority was what was underneath.
The Pattern Under the Patterns
This gap is the most expensive thing in your AI program this year, and it won't show up in any vendor demo. Every airline and travel company is chasing AI right now. Most of the failures won't be technology failures. They'll be organizational problems wearing a technology costume.
We reorganize faster than we transform.
This is the pattern under all the other patterns. Over the last five weeks we walked through five key patterns in our business—system design, shared definitions, existing assets, business ownership, data independence. Pull the thread on any one and you reach the same knot—organization and leadership.
Data problems in our industry are usually organizational problems. Technology is rarely the constraint but almost always the scapegoat. People, process, shared definitions and ownership are the hard part—and that's exactly why the work needs leaders, not just platforms.
Why does technology hide the hard part? Because you can buy it, demo it, put it on a roadmap and point to it in a board deck. Reorganizing looks like progress too—new boxes, new titles, a freshly minted VP of AI. We rename the boxes, reshuffle the reporting lines and call it transformation.
But actually transforming an organization—moving people through change—is slow and invisible in the short run. So we reach for the costume.
Nobody is foolish. The org chart is the easiest lever we can pull. And building capability is the work that costs a lot now and nobody rewards until after it's paid off.
What this error looks like in practice is consolidating everything into one central team without giving the rest of the business a way in. Trading a hundred slow answers for one long queue. Velocity dies. Hire a chain of managers who have never run the operation, and you take on domain debt—blind spots no platform corrects, because the people building our dashboards can't tell us which numbers are lying.
The reorg moves the boxes. The knowledge, the readiness stay the same.
I watched this play out on stage at the Skift Data + AI Summit a couple of weeks ago. The theme was Operational AI. The most honest data in the room wasn't on anyone's slides—it was in who these companies were hiring. The companies pulling ahead are building capability, not renaming functions and job descriptions with AI buzzwords.
We say the hard part is people and culture, but then we fund it like a tooling decision.
Build, Then Draw the Org
The alternative isn't a better reorg. It's a different order of operations. We should build the team around demonstrated success, not a theoretical end state we think solves the last failure. We prove something works in 90 or 180 days, then slowly design the org around what worked. We crawl, walk, then run. Most organizations do the opposite—they design the target-state org first and staff it before anything has shipped. That’s not only expensive. It’s risky. And I’ve seen it fail almost every time.
Whether it’s tools or teams, future-proofing is how data initiatives die.
But a working prototype is the best org chart you'll ever get. It shows you the roles that produced something. And the good news is building quickly is getting cheaper—ideas rather than skills are the constraint.
I built an always-on, agentic solution to replace a manual back-office workflow on my own stack over a weekend. Not to ship, but to make a point. The build is the easy part now. And the question of how to operationalize it, isn’t a technical one. It's whether the organization will let the people closest to the work use what they can build, instead of making them wait for permission.
A commercial leader I spoke to recently put it better than any architecture diagram. “We don't need a new system,” she said. “We need someone to own this.” She was right. The capability was real—it was just scattered, and nobody owned it as a strategy. That isn't a technology gap. It's an ownership gap. And you can't reorganize your way to capability—you have to build it, then give it a home.
You can't reorganize your way to capability.
And the order you do things matters more than the org chart. If we’re successful, it won't be because we have the best AI model—we all rent the same ones. We’ll succeed because we let the ones who built the capability use it, then draw an org around them. Demonstrate success first. Boxes second.
What this means Monday morning
If you're building the data: The thing you could prototype this week is probably the thing six months of org design is trying to specify. Build the smallest working version and ship it. If leaders like it, they’ll ask you how to get more.
If you're leading the data team: Before you draw the target-state org, find the one workflow your people can prove in 90 days. Staff against what ships, not what’s on the slide.
If you're the executive funding the next move: The capability you need may already exist—scattered and unowned. Ask who owns it as a strategy before you fund another platform or reorg to nowhere.
What's in the feed
On Friday the US Commerce Department ordered Anthropic to cut off all foreign-national access to its two most capable models, Fable 5 and Mythos 5—including Anthropic's own non-citizen employees. Unable to verify nationality at the API, Anthropic disabled both for everyone, worldwide, three days after launch. The lower models stayed up. The frontier tier went dark on the strength of one government letter. If your strategy rides a model you rent, your capability is one regulatory action from gone—and the model answers to someone else's government before it answers to you.
The center of gravity at Snowflake Summit this month was the context layer—Horizon Context, Cortex Sense, Semantic Studio. Strip the branding and a semantic layer is shared definitions with a price tag. That's the catch: the organization that never agreed what a booking means doesn't get saved by buying one. You can license the semantics. You still have to settle the argument about what they mean—and no vendor will sit in that meeting for you.
What I'm cooking this week
Soccer, volleyball and softball are all over. School’s out at the end of the week. It’s time to fire up the grill.
The carry-on
The fight is never really about the tool. A vendor will sell you a moat and call it new; a government can switch off your smartest model on a Friday. What's left when they do is whatever you actually built—and deciding to build it was the whole argument.
—Ben