Presented by Fivetran
Your pipeline works great for 3 data sources. But what happens when you hit 30?
Building custom connectors is fine until you have to scale. Fivetran takes the headache out of the equation by handling the schema changes, API updates, and retries across hundreds of sources, delivering analytics-ready data in hours.
They handle the ingestion mechanics. You handle the actual data strategy, modeling, and AI.
Try Fivetran free for 14 days.
Somebody at a big company told me this week that their department has to grow by 30% this year with 20% fewer people, and the plan to get there is to roll out agents. They’ve also been told to watch the token spend, because that’s gotten expensive. So grow by a third, lose a fifth of the team, become AI-first, and keep it cheap. All within a year.
I hear some version of this every day now. The mandate comes down, everybody nods, and almost nobody has done the structural work that would make it possible. That’s where I think most of these AI initiatives are quietly going to die, and it won’t have much to do with the models.
I wrote on Thursday about the Data Anarchy Tax. The June pulse survey of 212 people found that three out of four data teams have no one who owns their data products, and the teams running full anarchy burn 45% of their week firefighting. Perhaps you’ve experienced some version of this yourself. What I didn’t get into is why it happens, and what happens when you point a pile of agents at an org built in ways that facilitate firefighting and other reactive behavior.
Conway’s Law Lives. You Already Ship Your Org Chart
Melvin Conway wrote this down in 1968 in How Do Committees Invent, and it has held up annoyingly well. This became known as Conway’s Law, which says that organizations that design systems produce designs that mirror their own communication structures. The paraphrase everybody uses now is that you ship your org chart.
The survey results make a lot more sense once you look at them through the lens of Conway’s Law. 85% of teams have a clear owner for infrastructure, and only a quarter have a real owner for data products. That looks strange until you realize the infrastructure often sits within a single team. The platform team owns the pipelines, and everybody knows it, so the org chart hands you an owner by default.
Data is like water. It’s often longitudinal across an organization, owned by many and nobody at once. Data products (the datasets, dashboards, and models that stakeholders actually use) don’t usually sit within a single team. The exec dashboard (now your CEO with Claude) pulls from marketing, sales, and finance. The churn model touches product and support. Those things live in the space between the crevices on the org chart, and nobody in your company is responsible for the space between these spaces. AI is finally shining a light on the ownership holes in our organizations, often revealing what should’ve been obvious all along.
The Walls You Hit, and the Ones You Don’t
I’ve talked before about org charts versus work charts. The org chart is who reports to whom. The work chart shows how the work actually moves, cutting sideways across the org chart through whoever actually knows things and gets stuff done.
People absorb the difference between those two without thinking about it. You know the process says file a ticket, but you also know the one analyst on the payments team who actually understands the data, so you Slack her instead. And you carry a running list in your head that nobody has ever written down: the stale tables, the field got deprecated in March, the strange filter in the SQL WHERE clause. Nobody has touched this pipeline since the guy who built it got laid off in 2023.
Now put agents into that. This is the part I think people get wrong, and I got it wrong in an earlier draft of this piece. An agent doesn’t float free of your org chart. It runs into your org chart constantly because Conway’s Law means the systems it’s working in are the org chart, poured into schemas, permissions, and pipelines.
What actually happens is that an agent hits two kinds of boundaries and handles them backward.
The hard ones stop agents dead - permissions it doesn’t have, a join key that was never modeled because those two teams never talked to each other. Or maybe datasets that dead-end at the edge of a domain because that’s where somebody’s mandate ended. That’s all org chart, and the agent runs face-first into it. It gets locked out of exactly the cross-domain work that made you want agents in the first place.
The soft ones don’t slow it down for a second. Don’t trust that table. That number’s been wrong since Q1 2023 when that one guy was fired. Nobody owns this, so it hasn’t been fixed. All of that knowledge is unwritten precisely because there’s no owner to write it down. It lives in people’s heads and in old Slack threads (let’s have agents read our Slack for “context”). An agent has no gut feel about your data, nobody to overhear at lunch, and no reason to hesitate, so it goes right through and hands you a confident answer built on questionable data foundations.
A person hits both of those and manages both. They ask for access when they get blocked, and they use judgment on the stuff that isn’t written down. Humans find a way to plod along. This is how much of our economy functions.
As I’ve written before, AI amplifies things you’re both good and bad at. It also compounds, because agents don’t only work inside your org chart; they build new systems in the shape of it. Point a swarm of them at a siloed company, and you won’t end up with fewer silos; you’ll end up with more of them, faster, with better test coverage. Conway’s Law doesn’t care whether a person or an agent is writing the code. Whatever your communication structure looks like, that’s what gets built.
The honest counterargument is that if you eventually let agents roam across every domain, they might start dissolving silos rather than reinforcing them. Maybe. But that only works after you’ve given them the access, the shared semantics, and a human who owns the result, which is the same organizational work nobody wants to do. If it were that easy, organizations would’ve succeeded not just with their AI transformation but with all the other IT transformations of the past. Alas, the graveyard of failed IT transformations is vast, and the grim reaper of change management carries on. I suspect most companies will fail at AI for precisely the same reasons. Organizational change is incredibly difficult.
Allow Me to Reintroduce Myself, My Name is Team Topologies
Matthew Skelton and Manuel Pais wrote Team Topologies a few years ago, and the second edition just came out. It’s the clearest thinking I’ve found on any of this. The core move is to design your teams, so you get the architecture you actually want, on purpose. They call it the reverse Conway maneuver. Instead of letting the org chart you inherited dictate the systems you build, you reshape the teams so the systems come out right. Of course, this is far easier said than done.
Two of their team types align directly with the survey results.
Platform teams provide the self-service guts that everybody else builds on. Most data orgs have this one figured out. It’s why 85% of you have a clear owner for infrastructure.
Stream-aligned teams own a slice of end-to-end value for a domain. Most data orgs don’t have this, at least not for data. It’s the “the payments team should own the payments pipeline” answer that came back from the survey respondents who’d actually solved their ownership problem. Data Mesh attempts to solve for this. Perhaps agents offer a reason to move toward stream-aligned teams.
By the way, we’re running a Team Topologies book club in the Practical Data Community Discord, and Matthew Skelton is doing a live Q&A on July 23rd. He just published a report on org structure that reached many of the same findings as this survey, which was validating and slightly eerie.
Let’s Just Make AI the Owner
Every executive will have the same thought eventually. If the problem is ownership, just make the agent the owner. Let AI own the data products. Fully autonomous data org, no messy humans involved.
Go try it and report back, but I think that’s a bad idea and I don’t think it’s close.
Owning something means being accountable when it’s wrong. It means knowing why the model got built that way, what the fields actually mean, and what breaks downstream when you change them. You can absolutely use AI to build, maintain, and debug a data product. Somebody still has to approve the change and answer for it when the number in the board deck is off. An agent can’t be held to that. Maybe we get to a world where nobody is accountable for anything and the agents just run it all, and I’m only half joking when I say that world has a pile of problems nobody has thought through yet. We’re definitely not there now. But who knows. Maybe AI agents end up running our world, and we’re all free to live a life of leisure, as Keynes predicted almost 100 years ago.
Why This Never Gets Fixed
If it’s this obvious, why is ownership missing almost everywhere? Two reasons, and they feed each other. As my other surveys pointed out, people identify a lack of clear ownership and a lack of time as their two biggest obstacles to getting work done.
Ownership is a hot potato. Owning a data product means you’re the one who gets paged at 9 pm when it breaks, so everybody is quietly working to make sure it lands on somebody else. And there’s never any time. Something gets built because a stakeholder asked, then the next thing gets built because another stakeholder asked, and nobody has a spare hour to sit down and decide who owns any of it. No time means no owner, no owner means you spend the week reacting, and reacting all week means there’s no time for thoughtful work. It just goes around, and I see it in the numbers in every survey I run.
What’s finally forcing the conversation is the mandate itself. All the money and hope pouring into AI right now is running straight into the people, process, and structure problems we’ve been sweeping under the rug for a decade. That’s the good part, weirdly. AI is making us confront a bunch of stuff we should have dealt with years ago.
So you can do the actual work of reshaping the teams and ownership, which is slow, political, and probably painful. Or you can keep buying Copilot licenses and tokenmaxx and limp along like we have been, expecting different results. Is the hard version of organizational change worth it? I honestly don’t know, but it’s all counterfactual. But I think we need to try. What I don’t believe is that the way we’ve been doing things gets us anywhere near where everybody says they want to go.
Anyway, go look at your org chart, then go look at how work actually moves through your company. However far apart those two pictures are, that’s about how much trouble your agents are in.
The numbers here come from the June 2026 Practical Data Pulse Survey (212 anonymous responses, a snapshot of the community at one point rather than a matched panel). The dataset’s free to download, and Thursday’s post has the full anarchy tax breakdown if you want the diagnosis before the prescription.
In this Freestyle Friday episode, I break down results from the June 2026 Pulse Survey on organizational dysfunction among data engineers. I also dig into why data product ownership (or lack thereof) is one of the fundamental issues standing between companies and success with data and AI.
Freestyle Fridays and my other podcasts are available on Spotify, Apple, and wherever else you get your podcasts. Please support the show with a review. It means a lot.
Presented by Revefi
Save serious money on your cloud costs with Revefi’s new autonomous AI DBA, a tool built to handle the gritty reality of cloud data management so you can stop babysitting your infrastructure.
With a five-minute, zero-touch setup, it deploys 18 specialized agents across your data estate to automatically manage FinOps, performance tuning, and data quality.
If you want to cut your cloud costs by 30% to 70% and get back to actual data architecture, engineering, and AI, check out Revefi and start saving money today.
Start saving money on your cloud costs with Revefi
Where I’m At
My fall calendar is shaping up, and here’s an idea of what I’ll be doing.
Dataversity’s Data Architecture Online. Me, Bill Inmon, and several others talking about the future of data architecture. July 22. Register here.
Big Data London. September 22-24. Register here.
More to be announced very soon.
Cool Videos and Reads
Kirill Bobrov, a senior data engineer at Spotify and author of the blog luminousmen, joins me to talk about his viral “Drunk Post” repost, whether the AI boom is real infrastructure or another bubble, why engineering judgment can’t be automated away, and the process of writing a technical book on concurrency.
Here are some things I read this week that you might enjoy.
Ford rehires human engineers after AI fails to match quality checks
In a notable turn of events for the automotive sector, Ford recently re-admitted that their aggressive shift toward AI-driven quality control fell short, prompting them to rehire over 300 veteran engineers to bridge the gap left by automated systems. For those of us navigating the intersection of engineering and emerging tech, this serves as a powerful reminder that while AI is an incredible force multiplier, it is only as effective as the data and knowledge—and the deep, tacit domain expertise—used to train it. The company’s subsequent return to the top of the JD Power Initial Quality Study confirms that there is no substitute for hard-earned experience; the most successful strategies, even in highly automated environments, remain those that place human wisdom at the center of the training loop. (BBC)
A return to two-pizza culture
Werner Vogels’ latest reflection on Amazon’s "two-pizza" philosophy highlights a critical evolution in how we build: when AI tools like coding agents compress the prototyping phase from months to days, our traditional "working backwards" process needs a rethink. While clear writing remains essential for logic and strategic clarity, it is no longer the exclusive starting point; instead, we are seeing a shift where building a functional prototype first—and then writing the PRFAQ—allows teams to pressure-test their assumptions against reality before committing them to paper. For those of us focused on building lean, high-velocity data and product teams, this underscores that the core of the two-pizza model was never just about headcount, but about total end-to-end ownership. (All Things Distributed)
How to Plagiarize
Plagiarism sucks. I’ve had it happen to me, and so have my friends. Jessica Talisman’s recent piece explores how AI has effectively "professionalized" plagiarism, transforming it from a student shortcut into a pervasive systemic issue where intellectual squatting is now incentivized by algorithms prioritizing clicks over original thought. As the distinction between professional expertise and derivative content blurs, Jessica argues that we are losing the media and information literacy required to value authentic research. (Jessica Talisman)
The Reading Crisis in a Postliterate Age
In The Atlantic, Rose Horowitch examines the unsettling possibility that the era of deep, sustained reading—once viewed as an inevitable pillar of human progress—may have been a historical anomaly, now rapidly giving way to a "post-literate" age. As digital environments, algorithmic feeds, and generative tools increasingly replace the cognitive demands of linear reading with frictionless, synthetic consumption, our relationship with complex thought and original inquiry is fundamentally changing. For those of us creating educational content and curating communities, this is a profound wake-up call: we are operating in an ecosystem that actively competes against the focus required for deep work. To counter this, our challenge is to create experiences that don't just supply information, but actively reward the cognitive effort of "reading"—proving that in a world of instant synthesis, the ability to slow down, engage deeply, and synthesize complex ideas remains the ultimate professional and intellectual edge. (The Atlantic)
Note: I curate and read everything in this article link list. I use AI as a collaborator to synthesize and distill these summaries. I have the final say in what’s here.
Find My Other Content Here
📺 YouTube - Interviews, tutorials, product reviews, rants, and more.
🎙️ Podcasts - Listen on Spotify or wherever you get your podcasts
📝 Practical Data Modeling - This is where I’m writing my upcoming book, Mixed Model Arts, mostly in public. Free and paid content.
If you’re interested in sponsoring my newsletter and podcast, Q3 and Q4 2026 are opening up. Space is very limited. Please fill out this form if you’re interested.
The Practical Data Community
The Practical Data Community is a place for candid, vendor-free conversations about all things tech, data, and AI. We host regular events such as book clubs, lunch-and-learns, Data Therapy, and more.
Years later, data ownership remains the same problem!
I do wonder, however, if deployed agent teams can help ease the burden of data ownership. I'm cautiously optimistic that a data owner can lean on an agent team to run down the root cause of 10pm data pipeline problems and translate messy pipeline and SQL issues into the business logic decisions that need to get made.
I think the technology is mostly there, in reality. And there's an opportunity for data owners to be empowered in ways they weren't before.
Everything you describe is correct. In fact, this has been my work for years: helping organizations transform. And there are positive examples, organizations that have successfully made this shift. The theoretical foundation for doing so has existed for decades. It is neither new nor a secret.
I think that part of the problem lies in education, where this knowledge is often not taught.
But the much bigger obstacle is something different. Whenever someone says that something is "political," it points to the fact that politics emerges wherever interests are strong and power is distributed unevenly.
You cannot build an organization without distributing power. That is simply a fact. But how do you do it differently?
If you want to transform an existing organization, or build a new one, the very first task is to define how you see people and what assumptions you hold about human beings. That decision determines everything that follows.
In every successful transformation I have witnessed, where large corporations fundamentally redesigned the way they work, this was the very first step. And it should always be the first step: clarify your mindset.
Because if I believe that people cannot work effectively without being managed, then I will naturally conclude that every team needs a manager. From there, it seems logical to organize around purely engineering teams or purely data teams, because the manager is expected to ensure that everyone in the team develops within their own discipline.
This way of thinking is one of the greatest obstacles to organizational change.
Even if it is true that people need to grow in their area of expertise, it does not follow that everyone needs a leader. The same applies to the outdated concept of disciplinary management. If I believe I need disciplinary managers, I am implicitly assuming that people are fundamentally lazy and require supervision. That assumption is equally flawed.
Once you let go of these beliefs, entirely different organizational structures become possible. The disciplinary manager becomes a largely administrative role while the other dimensions of leadership are distributed across different people instead of being concentrated in a single position.
But even that is only the beginning of organizational transformation.
The broader point I want to make is this: the way we view people determines the way we design organizations.
Another fundamental building block is how we define success. If success is measured only by making or saving money, we should not be surprised when organizations eventually become dysfunctional and political.
I intend to write much more about this, because I believe we need to make these ideas more widely understood. Organizations need the conceptual tools to transform themselves. And when new organizations are created, they should not fall back into the same outdated patterns and behaviors.
There will be much more from me on this topic soon.