The data warehouse of the 1990s, the data lake of the 2010s and today’s GenAI platform fail surprisingly often for the same reasons. Three decades, three generations of technology, one set of mistakes. That is difficult to explain if the problem is the technology.
My thesis for this series is therefore that data and AI initiatives rarely fail because of technology. They fail because of organizational structures, badly chosen metrics, misread data and self-inflicted complexity.
Mental models for data and AI are simplified explanatory patterns for situations that keep recurring. They do not replace analysis, but they shorten the path to the right question. Someone familiar with Conway’s Law will not respond to a data silo by asking about the architecture first, but by asking about the org chart, which is usually the faster route to an answer.
Most of these models are already familiar, and another list of them would be worth nothing. This series is not that list. It differs in two respects. Every model is carried through to what it actually means for pipelines, metrics, ML systems and GenAI products, rather than stopping at the general principle. And where a model is shakier than its reputation, I say so: the Dunning-Kruger effect has known methodological problems, the original Hawthorne data has not survived reanalysis well, and data mesh does not resolve Conway’s Law so much as move it. A model quoted uncritically stops being a thinking tool and becomes a slogan.
The series has four parts. Part 1 covers organization and collaboration, Part 2 metrics and incentives, Part 3 data and judgement, Part 4 complexity and simplicity.
Conway’s Law
Three departments, three definitions of customer, and a meeting in which nobody gives theirs up. No architecture diagram explains why that happens. The org chart does, and Melvin Conway wrote down the reason in 1967: organizations inevitably design systems that mirror their own communication structures.
In the data world this is probably the single most powerful explanation available. When sales, marketing and controlling hold three different definitions of a customer, the cause is not a lack of modelling skill. It is that these three units never had to agree on one. Data silos are, in the vast majority of cases, simply team silos that have materialized as tables. This also explains why the standard rescue attempt fails so reliably: a central platform is purchased, every source is migrated into it, and two years later the silos sit in the same storage layer and still do not fit together. A central data lake does not integrate an organization that cannot agree on a definition.
The same pattern reappears in AI initiatives in a new guise. A RAG application whose knowledge base is built and maintained per department cannot answer cross-functional questions, because the boundaries of retrieval run exactly along the boundaries of the org chart. Users experience this as a quality problem of the model, when it is a scoping problem of the knowledge base.
The practical consequence is uncomfortable, because a data architecture cannot be imposed against the organization, only built with it. If you want an integrated view of the customer, you first need a role or a body that owns that view. Data mesh approaches are, at their core, nothing other than Conway’s Law taken seriously, leaving domain ownership where the knowledge already sits. They do not, however, solve the problem; they relocate it. What distinguishes a domain from a silo is not the boundary but the contract at that boundary: a defined schema, a committed level of quality, a named owner. Where that contract is missing, introducing domains produces nothing but a renamed silo. And because domain boundaries are in practice usually inherited from the existing org chart, Conway’s Law tends to win a second time in the process.
Brooks’s Law
In “The Mythical Man-Month” (1975) Fred Brooks described a counterintuitive experience from software development: adding people to a late project makes it later. There are two reasons. New team members have to be onboarded, which consumes exactly the capacity that is already scarce. At the same time, coordination effort grows quadratically rather than linearly with team size.
In data projects the effect is even stronger than in classic software development, because a substantial share of the relevant knowledge is documented nowhere. Why a particular field is empty for 2019, why a transformation handles three special cases, why a report deliberately deviates from the official metric: none of this lives in a repository. It lives in the heads of two or three people. Those are exactly the people who, when the team grows, spend their time explaining instead of delivering.
The counter-example worth knowing is Amazon’s two-pizza rule: no team so large that two pizzas cannot feed it, on the reasoning that coordination cost, not headcount, is the binding constraint. The interesting part is not the team size. It is the direction of scaling that follows from it. Amazon grew by adding teams with defined interfaces between them, not by adding people to teams. Translated into a data organization, that means a second team owning a separate domain with a contract at the boundary, rather than three more engineers inside the pipeline team. The first option costs an interface. The second costs everyone’s attention.
For leads this means that adding staff is almost never the right first move when a data project slips. Reducing scope, removing dependencies or freeing the team from side tasks is far more effective. If headcount does have to increase, it should happen early and in clearly bounded work packages that require little context knowledge.
The Dunning-Kruger Effect
The Dunning-Kruger effect describes the tendency of people with low competence in a domain to systematically overestimate their own competence, because they lack precisely the knowledge required to judge how difficult the domain is. The effect has attracted serious methodological criticism, partly because of statistical artefacts in the original studies, but as a description of a familiar pattern it remains useful.
In the AI space that pattern is currently everywhere, and it has acquired a name of its own: the demo-to-production gap. An LLM prototype accounts for roughly twenty percent of the total effort and generates eighty percent of the enthusiasm. The remaining eighty percent of the effort consists of evaluation criteria, handling hallucinations, data protection, cost control, monitoring, model migrations, edge cases and the question of what happens when the input data changes. None of that is visible from the outside, and what is invisible does not make it into estimates. The enthusiasm therefore arises exactly where knowledge about the difficulty is lowest.
There is now a measured version of the gap. METR ran a randomized trial in which sixteen experienced open-source developers worked through 246 real issues in repositories they had contributed to for years, half the tasks with AI tools allowed and half without. They expected the tools to make them 24 percent faster. Afterwards, having done the work, they estimated the tools had made them 20 percent faster. The measured result was 19 percent slower (METR, 2025). Sixteen developers is a small sample, but the direction of the error is the point: expertise in the domain did not protect anyone from misjudging their own speed, and the misjudgement survived doing the work.
In organizations this individual effect compounds into the planning fallacy, because a management review only ever sees the twenty percent that has a surface. Governance, edge cases, hallucination handling and drift have no demo, so they are not on the slide, and a schedule gets built from what was on the slide. The most expensive published version of this is a cancer hospital that signed a six-month, 2.4 million dollar contract with IBM in 2012 to build an AI advisor for oncologists. Five years and roughly 62 million dollars later the contract lapsed and the system had never been used on a single patient (JNCI 2017). That is institutional overconfidence rather than the individual effect Dunning and Kruger measured, but the mechanism is the one described above: nobody involved could see, at the start, what the remaining eighty percent consisted of.
What follows is an operating rule rather than a mood dampener: every prototype comes with a written list of what is still missing for production, and that list goes to the same people who saw the demo. A prototype demonstrates what is already possible; the list demonstrates what is not yet solved, and only one of the two ever gets shown. It, not the timeline, is the real communication tool. Show only the demo and you calibrate management expectations against twenty percent of the work, and that calibration is very hard to correct later.
Bikeshedding
C. Northcote Parkinson described a committee that waves through the construction of a nuclear reactor in minutes and then spends a long time debating the bike shed for the staff. His explanation: nobody can contribute to the reactor discussion, everybody can contribute to the bike shed. The effort spent on a discussion therefore tends to be inversely related to its importance. Software people call this bikeshedding, after a 1999 mailing list post in which a FreeBSD developer used Parkinson’s image to end a debate that had run for days.
Data organizations offer plenty of material here. Naming conventions for tables, the colour scheme of dashboards and the question of whether a field should be called kunde_id or customer_id generate long and enthusiastic debate. The far more important questions often remain unanswered: who is accountable for the quality of a metric, which data products should actually be operated, and what happens when a source system fails. Those questions are unpleasant because they assign responsibility, and they are hard because answering them requires real depth. I have sat in enough architecture reviews to notice which questions actually get settled: the ones a room can judge without knowing the domain. The ones it was convened for tend to need context that nobody present has.
GenAI projects have produced a new and very pure version of this. Weeks go into the choice of model, the temperature setting, the chunk size and the wording of the system prompt, all of them questions on which everybody present can hold an opinion after ten minutes of reading. Meanwhile nobody has built the evaluation set of two hundred realistic questions, and nobody owns the knowledge base. Those two pieces of work decide whether the thing is usable, and both of them require someone to sit down with the domain for a week.
For anyone in a leadership role this translates into a concrete task. Trivial decisions do not belong in a committee. They belong in a convention that one person defines and that is then no longer up for negotiation. The time freed up belongs to the questions where a wrong answer becomes expensive.
Takeaway
The four models in this part share one property: they describe problems that look technical but are not. A data silo is an organizational problem, a late project is a capacity problem, an unrealistic estimate is a communication problem, and an endless naming debate is a decision problem. Solving them with technical means guarantees meeting them again in the next generation of technology.
Part 2 (published soon) turns to metrics and incentives, and to the question of why data-driven organizations are so reliably good at measuring the wrong things.
