Previously: In Part 1, we established that most large data initiatives fail not because of bad technology, but because of a flawed ownership model. Centralized Data Warehouses create IT bottlenecks. Data Mesh implementations collapse under engineering complexity. This part is about why the solution has to start with people and structure over platforms and processes.
There is a word that appears in almost every data strategy document written in the last decade. Ownership. Business ownership of data. Domain ownership. Outcome ownership. It has become so familiar it has almost lost its meaning.
But when you look at the organizations that actually execute well on data, the ones where insights reach decisions in days rather than quarters, something specific is true. Ownership is not a policy they have declared. It is a condition they have created. And that condition turns out to have a well-established scientific foundation.
What Behavioural Science Has Been Telling Us Since 2009
In his 2009 book Drive, Daniel Pink synthesized decades of behavioural research into a conclusion that was simultaneously obvious and ignored by most large organizations: for complex, creative work, the traditional management toolkit of rewards and penalties actively destroys the motivation it is meant to produce.
Drawing on Edward Deci and Richard Ryan’s Self-Determination Theory, Pink identified three conditions that drive genuine high performance in knowledge work: Autonomy, the desire to be self-directed and in control of how and with whom you work; Mastery, the compounding drive to get better at something that matters; and Purpose, the experience of doing work in service of something larger than the task itself.
Data and analytics work is exactly the kind of complex, contextual, judgment-heavy work Pink was describing. Yet most data organizations are still managed with the extrinsic toolkit: JIRA tickets, SLAs, burndown charts and project budgets. Then we wonder why talented people stop caring whether their deliverables have any real impact.
What Pink described at the level of individual motivation, strong data ownership requires at the structural level, but the similarities are striking.
The Three Structural Conditions of Strong Ownership
Pink’s three elements of intrinsic motivation translate directly into three structural conditions that a domain team either has or does not have. The difference between having ownership only in title or in practice depends on whether all three are genuinely present.
Authority (Pink’s Autonomy, made structural)
Pink’s autonomy covers four dimensions: what you work on, when you work on it, how you approach it, and who you work with. In a data context, this translates into two concrete requirements that organizations consistently grant the appearance of while withholding the substance.
The first is decision rights: the actual authority to decide what gets built, in what order, and when it is good enough to ship. Not the responsibility to execute someone else’s roadmap, but the power to set the direction. Without this, ownership is accountability without agency, which is a polite description of a demoralizing situation.
The second, and the one most often overlooked, is control over implementation resources: a dedicated, stable developer who is accountable to the domain, not to a central IT resource manager. This is where Pink’s team dimension of autonomy becomes structural. A domain team that shares a developer pool with seven other teams does not have authority. They have a prioritization problem with extra steps. And when the developer rotates every quarter, institutional knowledge drains away with every handover. The team may own the roadmap on paper while the expertise that could execute it lives nowhere.
Give a team responsibility without authority or implementation resources, and you have not created ownership. You have created a scapegoat.
Understanding (Pink’s Mastery, made domain-specific)
Pink’s mastery is the compounding drive to get better at something that matters, culminating in what psychologist Mihaly Csikszentmihalyi called flow: the state of complete absorption in work that is neither too easy nor too hard. In data work, mastery has a specific and often missed requirement: it must accumulate within a domain, not just within a technical discipline.
A data architect can have technical mastery of DBT and lakehouses but very little understanding of the ERP system and business processes they are modelling. Understanding, in the sense that makes ownership real, means deep contextual knowledge: knowing what a spike in a process control chart actually signals in this business, which data fields are trustworthy and which are artefacts of a system migration three years ago, which seasonal patterns are meaningful and which are noise. This knowledge cannot be documented into a data dictionary. It lives in people who have been close to the same domain for long enough to develop genuine fluency.
Rotating developers do not just lose technical continuity. They structurally prevent mastery from forming. They are permanently in the orientation phase, which is the least productive and least motivating place to be, for both the developer and the business they are serving.
Motivation (Pink’s Purpose, made tangible)
Pink’s purpose is the experience of doing work in service of something larger than the task itself. This is not manufactured by a motivational poster or a town hall about company values. It emerges from proximity to consequence.
When a developer can see the board presentation that used the analysis they built, or hears directly from a sales director that a segmentation model changed how the team approached a key account, the connection between effort and impact is visceral. That connection is what Pink identifies as the most powerful and most durable driver of high performance in knowledge work.
Conversely, a data engineer closing tickets in a central data team is operating in what Pink calls a Type X environment: one driven by extrinsic rewards, where the primary signal of success is task completion rather than business impact. Type X environments work reasonably well for routine, repetitive work. Pink’s research is unambiguous that they are counterproductive for the complex, contextual, judgment-heavy work that good analytics development requires. We have been organizing data teams using the wrong motivational model, then expressing surprise when the results are mediocre.
Why Centralized Teams Fail All Three Conditions
A centralized IT data team, however skilled and well-intentioned, is structurally set up to fail at least two of these three conditions, and usually all three.
On authority: centralized teams have technical decision rights but almost none over business priorities. They can build what is asked of them but cannot decide what should be built or when it is good enough to ship. And because developers are shared across domains, no single team gets the dedicated implementation capacity that genuine authority requires.
On understanding: a team serving fifteen different business domains simultaneously cannot develop genuine depth in any of them. They learn the data model. They do not learn the business. The result is technically correct data products that answer the wrong questions, slowly.
On motivation: when a data engineer is three stakeholders removed from the decision their work enables, the feedback loop is too long and too indirect to sustain real engagement. The work becomes about closing tickets, not improving the business. Furthermore, as IT only owns the costs and risks and not the business benefits, their natural focus is safety rather than betting on growth.
This is not a criticism of the people in those teams. It is a structural observation. Put it in Pink’s terms: centralized data teams are structurally Type X environments. The people are not the problem. The missing incentives and feedback loop is.
Comparison between Data Warehouse, Data Mesh and Pragmatic Mesh:
Most organizations don’t have the skill and resources to properly execute the Data Mesh playbook, that is why we need a simplified and humanized version of it ie. the Pragmatic Mesh.
The Insight That Changes the Engineering Calculus
Here is a practical observation that gets buried in most Data Mesh discussions but should be front and center: in most organizations, roughly 95% of data never actually needs to leave its home domain.
The Marketing team’s campaign performance data is primarily consumed by Marketing. Finance’s revenue reconciliation data is primarily consumed by Finance. The genuinely cross-domain analytical questions, the ones that require joining customer data with sales data with logistics data, are important, but they are a fraction of the total analytical workload.
This matters enormously for architecture. It means the vast majority of a domain team’s work does not require sophisticated enterprise-wide mesh infrastructure. They need a clean, reliable, well-governed environment they control. The cross-domain sharing problem, which is what most of the Data Mesh engineering complexity is designed to solve, is actually a secondary problem for most teams on most days. The architecture should solve for the 95% first and handle the 5% as a deliberate integration layer.
We have been building highways to solve a neighbourhood traffic problem. Most of the journeys are local.
Co-Creation: Where Knowledge Transfers and Relatedness Takes Root
There is one more structural shift that separates the teams that deliver real impact from the ones that produce beautifully architected but rarely used data products. It is how the work gets done, not just who does it.
Traditional data projects operate on a waterfall handoff model. A business analyst writes a requirements document. A data engineer builds to the spec. Three months later, the analyst looks at the output and explains why it is not what they meant. The mismatch is not incompetence. It is an information transfer problem: you cannot write down tacit knowledge in a requirements document.
Co-creation means the person who understands the business question and the person building the data model work side by side, iterating in real time. When a number looks wrong, the business expert says so immediately and explains why. When a data structure is technically impossible, the developer proposes an alternative on the spot. The feedback loop collapses from weeks to hours.
This only works when the developer is stable and embedded. A rotating developer who joins the sprint, builds to specification, and moves on cannot co-create. They can execute. Co-creation requires enough accumulated context to push back, to ask the question behind the question, to know which shortcuts will cause problems in six months. That context takes months to build and days to lose.
There is a dimension of this that goes beyond knowledge transfer. Deci and Ryan’s Self-Determination Theory identifies relatedness, genuine connection to the people you are working with and for, as a core human need in motivated, high-performing work. This is the element Pink’s framework underplays and that most discussions of data team design miss entirely. A developer who knows the business expert they are building for, who has been in the room when a decision was made and seen the consequence of a number being wrong, experiences their work differently from one who builds to a specification and moves on. That difference shows up in the questions they ask, the edge cases they anticipate, and the care they bring to the logic. It is not a soft benefit. It is a quality mechanism.
Co-creation is not just a knowledge-transfer mechanism. It is what makes the work feel worth doing at the level of human motivation.
The Platform Is the Team Size Constraint
Everything argued above depends on keeping the domain team small. A small team maintains shared context. A small team makes fast decisions. A small team co-creates without coordination overhead. The moment a team grows beyond four people, the dynamics start to shift. Processes appear. Handoffs appear. The backlog appears.
And here is the constraint: a team can only stay small if one person can do what previously required three specialists. If the analytics platform requires a dedicated data engineer to manage infrastructure, a separate developer to write transformations, and a BI analyst to build reports, together with a business owner, you have a minimum viable team of four before you have shipped anything. Add more stakeholders and you quickly also need a dedicated project manager or scrum master, growing to a size that requires separate budget and project stage gate approvals.
The data platform is not a nice-to-have. It is the load-bearing wall of the entire model, but its function is not measured by its grandiosity of covering all possible real-time IoT and Big Data requirements. Instead, the simplest possible platform that abstracts away infrastructure complexity, shortens the feedback loop between data and insight, and allows one capable person to own the full stack from raw data ingestion to dashboard is what makes a team of two or three genuinely viable.
The right platform should not add any unnecessary complexity. Instead, it removes the ceiling on how fast your team can be by keeping it small.
What This Actually Looks Like
A well-functioning small domain team in a large organization is embedded in a business domain, not reporting to an IT department. It owns the data pipeline from source to decision, not just one layer of it. It has a dedicated, stable developer who knows the domain well enough to push back. It is measured on business outcomes, not technical deliverables. It can ship a working data product in days and change direction the following week without filing a formal change request.
The best software product teams have operated this way for years. Small, cross-functional, embedded, autonomous. The data world has been slow to follow, not because the model is wrong, but because two things got in the way: platforms that required specialist engineering skills to operate, and organizational cultures that confused central control with governance. The first of those obstacles is genuinely falling away. The second requires courage more than technology.
In Part 3, we tackle the platform question directly, with a specific argument and a specific recommendation.
COMING UP IN THIS SERIES
Part 3: How Qlik Cloud Analytics breaks the engineering bottleneck and lets your team focus on business logic instead of infrastructure and governance processes.
Part 4: How to escape data silos while doing fast domain owned data iteration without a data lakehouse?
Part 5: Four lean governance rituals that bulletproof your data products without complicated software or bureaucracy.
Ensuring strong ownership is the only data strategy you need.
