Written by Phuoc Tran Minh

The Legitimate Objection
Every technically sophisticated reader who has followed this series to Part 4 has a version of the same concern, and it is a fair one.

The Pragmatic Mesh model argues for small domain teams owning their analytical environment end to end. In Part 3, that environment was Qlik Cloud. But large organizations are not collections of isolated domains. At some point, Finance needs to join their revenue data with the Marketing team’s customer acquisition data. The enterprise data team needs to understand what logic the Sales domain has applied to their pipeline numbers before they publish the consolidated forecast. The data science team needs access to the clean, curated datasets that the domain teams have built, in a format their tools can actually consume.

If each domain team is operating in its own Qlik environment, and Qlik’s native format is a proprietary binary, does the Pragmatic Mesh model just recreate the silo problem at a smaller scale?

Does starting with Qlik mean being stuck with Qlik? Not at all, due to many recent improvements in Qlik and open standards like Parquet and Iceberg.

Parquet: The Open Handshake
Apache Parquet is an open-source, columnar storage format that has become the closest thing the modern data ecosystem has to a universal language. Snowflake reads it. Databricks runs on it. Apache Spark processes it natively. AWS, Azure, and Google Cloud all support it as a first-class format. It is the file format that data pipelines, data lakes, lakehouses, and machine learning platforms all agree on.

Qlik Cloud can export data directly to Parquet. This means the curated, business-logic-enriched datasets that a domain team builds in Qlik — the clean sales data with correct product hierarchies and attribution rules, the customer segmentation with AI-enriched classifications, the financial metrics with the right aggregation logic — can be written to a shared data lake in a format that every other tool in the enterprise can read without any translation layer.

The domain team is not locked into Qlik for their data outputs. They choose Qlik because it makes their development fast and their models powerful. But they can easily make data products available to the enterprise in a format that imposes no dependency on Qlik at all. The Finance team’s Snowflake queries can read the Sales domain’s Parquet files directly. The data science team’s Python notebooks can load them without a Qlik licence. The enterprise data platform can ingest them into its central data lake without knowing anything about how they were produced.

Data Product REST API: The Lighter-Weight Alternative
Parquet is the right answer when the consumer is another data pipeline, a data science notebook, or a lakehouse query engine. But not every cross-domain data exchange is a bulk file transfer. Sometimes what a downstream system needs is a governed, on-demand query against a specific dataset: a business application pulling current KPIs, an AI agent retrieving validated figures for a response, a downstream dashboard refreshing a single metric.

Qlik’s Data Products feature, with its REST API, addresses this pattern directly. A domain team can package a curated dataset as a governed data product, with defined ownership, versioning, and quality rules, and expose it via a standard API that any application can call. The consumer does not need to understand how the data was built, who maintains it, or what transformation logic produced it. They call the API and get a validated, trusted result.

This is not a replacement for Parquet-based data sharing at scale. It is a complement: real-time, low-volume access for applications and AI agents alongside bulk export for analytical pipelines. Together, the two patterns cover the vast majority of cross-domain data consumption scenarios without requiring the domain team to build custom integration work for every new consumer.
Earned Trust: Quality Signals for Downstream Consumers

There is a question that any downstream consumer of a domain team’s data will eventually ask, and it is not a technical question. It is a trust question: how do I know this data is good enough to use?

In a centralized data warehouse, the answer was implicit: the central team certified the data, and certification was their job. In the Pragmatic Mesh model, where domain teams own and publish their own data, the answer needs to be explicit and auditable. Trust cannot be assumed from the source. It has to be demonstrated at the point of consumption.

Qlik addresses this through its Trust Score feature, which assigns a quantified quality signal to a dataset based on measurable properties: completeness, consistency, freshness, and — for teams using their data in AI workflows — fitness for LLM consumption, including factors like metadata richness and potential bias. The score is not a marketing badge. It is a structured quality assessment that a downstream consumer can inspect, question, and factor into their decision about whether to use the data for a given purpose.

For the Pragmatic Mesh model, Trust Score does something organizationally important: it makes a domain team’s quality standards legible to the rest of the organization without requiring a central governance team to audit every dataset. The domain team owns the quality. The score makes that quality verifiable. That is the right division of responsibility.

The Growth Path: When the Data Lake Needs to Scale
For many organizations, Parquet files in cloud storage is sufficient for cross-domain data sharing. But for teams operating at significant scale, or with complex requirements around data versioning, schema evolution, and time-travel queries, there is a natural next step: Apache Iceberg.
Iceberg is an open table format built on top of Parquet that adds the capabilities that enterprise data teams need when their data lake starts to behave more like a data warehouse: ACID transactions, schema evolution without data migration, partition pruning for fast queries, and the ability to query data as it existed at any point in time. It is supported by every major cloud data platform and is rapidly becoming the standard for serious lakehouse architectures.

The relevance for the Pragmatic Mesh model is this: a domain team that starts by exporting Parquet files can graduate to writing directly to Iceberg tables as the organization’s data maturity grows, without changing the fundamental approach. The domain team still owns its pipeline. The data still reflects their business logic. The difference is that it now participates in an enterprise lakehouse architecture that supports cross-domain queries at scale, versioned data contracts, and integration with cloud data platforms like Snowflake and Databricks. The starting point does not constrain the destination. Each stage is a genuine upgrade rather than a rebuild, as described in table below.

The domain team’s Qlik environment and strong ownership does not change as the enterprise layer matures. What changes is the output format and the orchestration around it. That continuity is itself a form of organizational capital that most data platform migrations destroy.

AI as the Documentation and Translation Layer
One of the persistent concerns about domain teams owning their own pipelines is lineage and legibility. If the Sales domain’s Parquet files land in the enterprise data lake, and those files were produced by a Qlik load script that only one developer fully understands, what happens when that developer leaves? What happens when the enterprise data team needs to audit the logic for a regulatory review? What happens when someone downstream gets a number they cannot explain and needs to trace it back to the source?

This is a real concern and it deserves a practical answer rather than a reassurance. The practical answer, in 2025, involves large language models used in a specific and grounded way.

A Qlik load script is readable code. It is not a black box. Given a load script, a capable LLM can do three things that are genuinely useful for lineage and governance:
Generate human-readable documentation. Describing in plain language what each section of the script does, what business rules are encoded, and what transformations are applied at each step. This documentation can be maintained automatically alongside the script, so it stays current rather than drifting from the code it is meant to describe.

Flag logic that warrants review. Joins that could produce fanout, fields with ambiguous naming, hardcoded date filters that will break at year boundaries, business rules that are applied inconsistently across different sections of the script. A senior developer reviewing the script manually would catch these. An LLM can surface them as a checklist before the review rather than during it.

Translate load script logic to SQL. For teams that need to migrate a Qlik pipeline to a different platform, or that need to replicate the logic in a downstream system, an LLM can produce a working first draft of the equivalent SQL transformation. It will not be production-ready without review, but it reduces what was previously a weeks-long reverse-engineering exercise to a starting point that takes hours to validate and refine.
AI readability doesn’t stop at the load script either: Qlik’s extensive API’s make all the app UIs, semantic layer (called master library in Qlik), access rights and reload task configurations accessible to automated documentation and auditing.

The Architecture Earns Its Freedom
The argument across Parts 3 and 4 is essentially this: the Pragmatic Mesh model is not a compromise between speed and scalability. It is a sequenced approach that delivers speed first, at the domain level, and earns its way into enterprise-scale architecture through open standards rather than being forced into it from the start.

Starting fast and staying open are not in tension. They are a sequence.

The domain team that ships a novel sales analysis in three days is not doing something that conflicts with the enterprise data team’s lakehouse strategy. They are doing something that can feed into it, once the output format is Parquet and the governance rituals are in place, which brings us to the last part of this series: how to implement lean governance that doesn’t create centralized bottlenecks.

COMING UP IN THIS SERIES
Part 5: Four governance rituals that bulletproof your data handoffs without slowing your team back down to the pace they were trying to escape.

Fast and trustworthy are not opposites. Part 5 shows you how to be both.

BY Phuoc Tran Minh, GOODIN BI Lead

Previously: In Part 2, we established that strong ownership requires authority, understanding, and motivation, and that authority is hollow without dedicated implementation resources and stable developers. The platform choice is the load-bearing wall of the model: it determines how small and fast your domain team can actually be. This part is where the platform argument gets specific.

A straightforward disclosure

In Parts 1 and 2, the argument was purely structural: why the current models fail, and what the right organizational conditions look like. From here the series gets specific about technology, and specifically about Qlik Cloud Analytics. I consult with Qlik. I am going to make a case for the platform. I want to be clear that this recommendation comes from having watched what works and what does not in real enterprise environments, not from a feature sheet.

If you use a different platform and the principles from Parts 1 and 2 resonate, the principles still apply. But if you are evaluating your options, I am going to give you an honest account of why I think Qlik gets the fundamentals right for the model we are describing.

Let us start with a real-life situation. Just the kind of moment that happens in every large organization, probably multiple times a month.

It is Tuesday afternoon. The VP of Marketing needs to present Customer Acquisition Cost by channel to the board on Friday. The numbers currently live in three places: the CRM, the ad platform exports sitting in someone’s Downloads folder, and a finance reconciliation spreadsheet that the CFO’s team updates monthly.

The marketing analyst knows exactly what the answer should look like. She has built versions of this report in Excel before. But the data needs to be clean, joined, and defensible before it goes to the board. So she raises a ticket with the central data team.

The central data team is not being obstructive. They are genuinely busy. The ticket lands in sprint planning. The earliest they can look at it is three weeks from now. By which point the board meeting is over, the decision has been made on the basis of the Excel version anyway, and the carefully engineered data product will be used once, by the analyst who already knew the answer.

This is not a data quality problem or a governance problem or a prioritization problem. It is a latency problem. The gap between the moment a business question becomes urgent and the moment a reliable answer is available is too wide to be useful. And it is structural: it is baked into any model where the person who understands the question and the person who can answer it are separated by an IT backlog.

The Pragmatic Mesh model solves this by putting the analyst and the developer on the same small team, co-creating in the same environment. But that only works if the environment itself does not require three specialist roles to operate. Which brings us to the platform.

What the Platform Actually Has to Do

Most platform evaluations focus on the wrong question. The question is usually: what can it do? The right question for the Pragmatic Mesh model is: what does it stop you from having to do?

A platform that makes a small domain team viable needs to do three specific things well.

First, it needs to abstract away infrastructure. The developer on the domain team should be thinking about business logic, not cluster management, container orchestration, or storage configuration. Every hour spent on infrastructure is an hour not spent understanding the business problem. The platform should handle the plumbing invisibly so the team can focus on the data flowing in the pipes that actually matter to the business.

Second, it needs to close the feedback loop. The marketing analyst in the scenario above should be able to see the impact of a data model change immediately, not after an approval and deployment cycle. When a join produces unexpected nulls, that should be visible in minutes, not discovered by a stakeholder in a meeting three weeks later. Short feedback loops are what make co-creation between a business expert and a developer actually work in practice.

Third, it needs to enable full-stack development by a single capable person. This is the capability that makes the small team model viable. If one analytically capable developer can take a business question from raw source data all the way to a governed, shareable data product and management dashboard without needing to hand off to a pipeline specialist, a modelling specialist, and a visualisation specialist, the team stays small. The moment the platform requires multiple handoffs and coordination between different specialists, the team grows, the backlog appears, and you are back to the centralized model with domain branding.

The best platform is not the one with the longest feature list, but the one that keeps your team small and agile by having full control of their own pipeline.

Why Qlik Cloud Analytics Gets This Right

Qlik Cloud Analytics fits the Pragmatic Mesh model so well because of three architectural decisions that happen to align with exactly what a small, autonomous domain team needs.

1. The Associative Engine: Exploration Without Pre-Planning
Most BI platforms are query-based. You define what question you want to answer, build the query or the model to answer it, and get the result. This works well when the questions are stable and known in advance. It works poorly when the business is trying to understand something it does not fully know how to ask yet, which is most of the time.

Qlik’s associative engine holds the entire dataset in memory and tracks relationships across all fields simultaneously. When the marketing analyst selects a single campaign in a chart, every other visualization on the screen updates to reflect what is associated and what is not, without her having to write a filter or rebuild a query. Furthermore, this automatically extends to all available data fields, so she can follow a thread of interest across the data without knowing in advance where it leads, and without having to specify all the required drill-down paths in advance when developing a dashboard.

For a domain team co-creating with a business expert, this is significant. The team can explore the data interactively during the development session itself, catching incorrect joins, missing data, or unexpected patterns in real time instead of waiting for 2 week springs. The feedback loop that matters most, the one between the data model and the business expert’s intuition about whether the numbers make sense, closes during development, not after deployment.

Back to the marketing analyst. With Qlik, she and a domain developer go through a new requirement on Tuesday morning. By afternoon, the developer has loaded the CRM data, the ad platform exports, and the finance reconciliation sheet directly into the Qlik associative engine. She clicks through it, spots that the CRM is attributing some paid social conversions to organic search, and explains why. He fixes the attribution logic on the spot and she quickly validates the corrected numbers. By Wednesday afternoon, they have a governed, shareable app. The board presentation on Friday uses defensible data. No tickets. No sprint planning. No three-week wait.

2. The Load Script: Transparency That Builds Trust and Enables Rapid Iteration

One of the persistent problems with self-service BI tools is that they make it easy to produce numbers but hard to understand where the numbers come from. A drag-and-drop report can look authoritative while quietly producing nonsense because of an unnoticed join issue or a filter applied three screens back. When a stakeholder challenges the number, the analyst often cannot trace it back through the visual interface to show all the relevant steps of the data pipeline.

Qlik’s load script is a first-class citizen of the development experience. Every transformation, every join, every business rule is written explicitly in readable script that sits within the Qlik application. When a CFO asks how the revenue figure of a new business unit was calculated, the developer can show the exact logic in two minutes. When a new team member joins the domain, they read the script and understand the model. When something breaks, the script tells you where.

Although powerful, it doesn’t mean that all data pipelines for Qlik applications need to be handled entirely in its load script. Especially when using more mature data products, most of the business logic can be maintained in a separate data layer independent of any single Qlik application. However, it is a tremendous advantage to be able to iterate quickly the entire data pipeline defined in a Qlik load script when business logic is still uncertain and requires rapid learning by trial and error.

3. Managed Cloud Infrastructure: The Overhead That Disappears

Qlik Cloud is a fully managed SaaS platform. There are no servers to configure, no Kubernetes clusters to maintain, no storage tiers to optimize. The domain team connects their data sources, writes their load script, builds the UI, and publishes it. The infrastructure that makes all that possible is fully maintained by Qlik.

For a small domain team, this is not a minor convenience. Infrastructure management is one of the most common reasons a domain team grows beyond the size where it remains effective. The moment you need someone to look after your compute environment, you have added a role that is not about the business domain at all. That person is focused on uptime, not outcomes. Their work is necessary but it is not the work the team exists to do.
Qlik’s access rights framework makes it easy to provide each team with its own work spaces, totally independent of each other in terms of federated management of data, user permissions and compute resources. This makes it safe to give full autonomy to each team without a risk of unintended consequences that would affect resources not owned by said team.

The Full-Stack Data Developer: One Person, End to End

Together the aforementioned three capabilities produce something that most analytics platforms cannot: a credible path to full-stack data development by a single non-techie person.

In the traditional analytics stack, you need at minimum these roles: a data engineer to build and maintain the data pipeline, a data modeller or analyst to structure the data for analysis (e.g. create a data mart), and a BI developer to build the reports and dashboards. These require genuinely different skills, and in a complex enterprise environment with custom infrastructure, they often require different people. But much of that specialization is a consequence of platform complexity, not of the business problem being solved.

When the infrastructure manages itself, and when the data loading, transformation, modelling, and visualization all happen within a single coherent environment, the cognitive load drops to the point where one capable person can own the entire stack. Not because they are a superhero hacker, but because the stack is no longer artificially divided by tooling boundaries.

In the Pragmatic Mesh model, this person is the full-stack data developer: embedded in the domain, co-creating with the business, owning the logic from source to insight. They write the load script that pulls the data. They build the associative model that structures it. They design the app that makes it explorable. And when the CFO asks how the number was calculated, they can explain the full data pipeline in two minutes.
In the Pragmatic Mesh, the full-stack data developer is not a legendary superhero hacker. They are what naturally happens when the platform stops creating artificial specialization.

What This Is Not

This is a good moment to be clear about two things the Pragmatic Mesh model with Qlik is not.
It is not a replacement for enterprise data infrastructure. Large organizations will still have shared data platforms and cross-domain analytical requirements that need coordinated engineering effort. Part 4 is specifically about how domain-owned Qlik applications connect to the wider enterprise data ecosystem through open standards.

It is not a way to avoid governance. The argument has never been that small autonomous teams should operate without oversight. It is that governance works better when it is designed for the team rather than imposed on them. Part 5 covers four practical governance rituals that work specifically because they are lightweight enough for a small team to maintain without a dedicated governance function. What we are eliminating is governance theater that is more concerned about procedures than business impact.

The Honest Assessment

Qlik is not the only platform that can support small, autonomous domain teams. Thoughtful implementations on other platforms can achieve similar outcomes with more custom engineering work. What Qlik offers is that these outcomes are closer to the default experience rather than the result of significant platform customization.

There are genuine trade-offs to acknowledge. Qlik’s load script language has a learning curve for developers coming from SQL-first environments. The associative engine, while powerful for exploration, behaves differently from the query based models that many data teams are accustomed to, and that difference requires time to internalize. For teams with very large data volumes or real-time data streaming requirements, the architecture will eventually need to evolve beyond what a Qlik load script handles natively.
Part 4 addresses that last point directly. It is about how a domain team that starts with Qlik Cloud for fast iteration does not paint itself into a corner as the organization’s data maturity grows.

COMING UP IN THIS SERIES
Part 4: The Parquet handoff: how domain-owned Qlik applications connect to the enterprise data ecosystem through open standards, and why starting small does not mean staying small.
Part 5: Four governance rituals that work precisely because they are lightweight enough for a small team to maintain without a dedicated governance function.

The strategic advice is cheap. The execution is everything. That is why the platform enabling small autonomous teams matters.

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.

So Why Bother with Data Utilisation Design?

You can think of data as this treasure trove of insights just waiting to help you make your next big move. It is not just about having loads of data as data that is not used is a waste of money; it is about knowing what to do with it and actually utilising it. But naturally if you have not thought about the why’s, what’s or how’s that can be hard. So we collected a list to help you on the way. Here is why you should care about data utilisation design:

• Make Smarter Decisions: When you base your decisions on what the data is telling you, it is like having a crystal ball kind of. It means you are making moves based on what is actually happening, not just gut feelings. And the best scenario is of course to combine the data with you gut feeling as that should not be undervalued either as it is usually data that comes from experience.
• Stay Agile: Markets move fast, and data helps you keep up. You will see the trends as they are happening, so you can steer your team in the right direction without missing a beat.
• Spot Risks and Opportunities: It is like having a map and a flashlight in a dark cave to put it in a simple analogy. Data helps you see where the pitfalls are and where the gold is hidden.
• Keep Your Customers Happy: By understanding what your customers are into, you can tailor what you do to match their expectations. It is a win-win – they get what they want, and you get their loyalty.
• Drive Innovation: Data is POTENTIALLY a goldmine of insights that can spark new ideas. It is all about finding better ways to do things, making your business stand out and the knowledge of market trends, opportunities, cross-level cooperation and so forth are human-led but when backed up by data the delivery can really help you jump over several hurdles.

The importance of data utilisation design for business leaders cannot be hence overstated. It is a critical competency that enables leaders to navigate the complexities of the digital age with confidence and foresight.

In the journey towards data-driven excellence, the role of leaders is not just to manage data but to inspire a culture where data is a strategic asset, driving every decision, every innovation, and every success together with the human aspect that lead the change.

Here is a To-Do List for you to think about when wanting to get started:

Here are the first few steps to take that’ll set you on the right path:

1. Set Clear Goals: Decide what you want to achieve with your data and and your people. It could be improving customer satisfaction, boosting sales, or streamlining operations. Having clear objectives will help you focus on the data that matters and help your people understand how to utilise it.
2. Get to Know Your Data: Take a moment to understand what data you already have, where it is coming from, and how it is being used and if it is not being used, why? It is about getting the lay of the land before you start digging deeper.
3. Build a Data-Savvy Team: Surround yourself with people who get excited about data! If your team can understand and use data effectively, you are already halfway there. There are several methods and services available to enable change with for instance GOODIN and Splended designed data learning sprint to get everyone up to speed.
4. Invest in the Right Tools: There is no shortage of tools out there to help you collect, analyse, and visualise data. Find the ones that fit your goals and your budget. It is about making your life easier, not more complicated.
5. Start Small and Scale Up: You do not have to build the full picture in one go. Rome wasn’t built in one day either. Start with a small project or area where data can make a difference, learn from it, and then gradually expand your data initiatives.

We are also happy to help to get you going so just be in touch!