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.

Written by GOODIN’s BI LEAD – Phuoc Tran Minh

If you work in data and analytics, you are used to the whiplash. Every few years, the industry promises a new architectural silver bullet that will finally solve the reporting backlogs, the data quality nightmares, and the governance headaches. Recently, that silver bullet has been Data Mesh.

I will be the first to admit I have been a strong advocate for it. The core promise of shifting data ownership away from a centralized IT bottleneck and putting it directly in the hands of the business sounded like the exact antidote large organizations desperately needed. And intellectually, it still does.

But after watching these implementations unfold in the real world, we need a serious reality check.

The War Story Nobody Publishes

I have watched some of the largest companies in the world, flagship enterprises, household names, fail at this problem repeatedly. Not once. Repeatedly. The pattern is almost identical every time.

They invest heavily in a centralized Data Warehouse. The project runs 18 months over schedule. By the time it delivers, half the business requirements have changed. The central data team, talented as they are, becomes a permanent bottleneck. They understand the technology but not the business, and every new report request joins a queue that never clears. The business loses patience and starts building its own analytics in spreadsheets, local databases, and disconnected BI tools. Shadow IT blooms.

Here is the part that rarely gets said out loud: most of these organizations do not actually choose between the two bad options. They end up with both simultaneously. A stagnating, increasingly outdated Data Warehouse on one side, and a sprawling mess of shadow self-service analytics on the other. They are paying for the warehouse they cannot retire and suffering the chaos of the self-service sprawl they cannot govern. The worst of both worlds, billed as a strategy.

When it fails, the instinct is to blame the technology or the consultant. Never the model itself.

The BI Manager’s Dilemma: both choices end in pain.

The Numbers Are Damning, Across the Board

The failure of centralized data platforms is not anecdotal. Gartner, IDC, and Forrester have consistently placed the failure or underperformance rate of traditional Data Warehouse initiatives at somewhere between 50% and 80% over the last fifteen years. The specific number varies by study and definition of failure, but the directional truth has been stubbornly consistent: most of these projects do not deliver their intended ROI.

The unsettling part? The decentralized alternative is not faring much better. Zhamak Dehghani first published the concept of Data Mesh already in May 2019 to much acclaim, but very few successful implementations have since emerged. In 2022, Gartner predicted that Data Mesh may become obsolete before reaching full maturity, and estimated that only 18% of organizations have the necessary governance maturity to successfully adopt Data Mesh architecture. Unfortunately, these estimates still seem highly accurate.

Two Books, One Argument

The industry’s frustration has recently found a voice in two very different books worth naming directly.

Martyn Jones’ F*CK DATA MESH says the quiet part loud. The title alone captures the mounting exhaustion with architectures full of grand theory about domain sovereignty that collapse the moment they meet an actual organization. The sentiment is valid. Data Mesh implementations have frequently produced fragmented, expensive messes that delivered less than the warehouses they were meant to replace.

At the other end of the conversation, Phil Le-Brun and Jana Werner’s The Octopus Organization, a recent Harvard Business Review publication, offers a compelling biological metaphor for what a genuinely decentralized, high-performing organization looks like: distributed intelligence at the edges, fast local decision-making, coordinated but not controlled from the center. It is a useful model, and one worth keeping in mind. But it is also a model that assumes the organizational foundations are already in place to support it.

Both books are participating in the same conversation: what does genuine, functional decentralization actually look like, and why does it keep failing in practice?

The Problem Is Not the Vision. It Is the Execution Trap.

Here is the reality CIOs must face head-on: the core principle of Data Mesh, business ownership of data, is fundamentally correct. Gartner’s recent CIO Agenda research is unambiguous on this point: the organizations winning at digital delivery are the ones with genuine business ownership of technology outcomes, not the ones that kept everything inside a central IT function.

The vision is not wrong. But the enterprise execution of it has been a disaster, for a specific and diagnosable reason.

Data Mesh implementations typically fail because they confuse organizational autonomy with infrastructure engineering. By asking business domains to take ownership of their data products, companies inadvertently require business analysts to master Git repositories, YAML configurations, dbt transformations, and CI/CD deployment pipelines just to publish a clean dataset. The autonomy on offer turns out to be an engineering curriculum in disguise.

Business units do not have the technical skills, the budget, or frankly the incentive to become software engineering teams. The result is anxiety, stalled adoption, soaring cloud costs, and, ironically, a new generation of exactly the same shadow IT silos the whole exercise was supposed to eliminate.

We gave domains the responsibility without giving them the means to carry it. That is not decentralization. That is delegation of blame.

The Question We Actually Need to Answer

So we are stuck. Going back to the centralized Data Warehouse means burying every request in an IT backlog and watching the business work around you. Pressing forward with a full Enterprise Data Mesh means handing business analysts an engineering toolkit they cannot use and watching the whole thing fragment.

The question is not which of these two paths to choose. It is how to escape the false choice entirely.

That is what this series is about. The argument is for a pragmatic middle path, one that keeps the principle of business ownership intact while stripping away the engineering complexity that has been killing it in practice. And by Part 3, we get specific about the technology that makes it executable.

COMING UP IN THIS SERIES
Part 2: Why real agility and ownership requires authority, understanding, and motivation, and why small business-driven teams are the only structure that delivers all three.
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.

The era of the IT-driven rigid data factory is ending. But the era of the over-engineered, under-delivered Data Mesh needs to end with it.

Mikon reaktio oli erityisen kiinnostava – hänelle nämä ominaisuudet
tuovat mieleen jotain hyvin tuttua.

“Tämähän on kuin 2018 – mutta parempi”

– Mikon tarina Podium Datasta. Mikko on pitkän linjan #Qlik-veteraani, ja kun hän ensimmäistä kertaa näki
uudet Data Products -ominaisuudet, hän hymyili tunnistavan hymyn.

Vuonna 2018 Qlik hankki yrityksen nimeltä Podium Data, ja Mikolla on siitä
omakohtainen kokemus – hän ehti työskennellä kyseisen tuotteen kanssa
ennen kuin se integroitiin Qlikin tuoteperheeseen nimellä Qlik Catalog.

Qlik Catalogin ydinajatus oli ratkaista se ikuinen ongelma: tekniset ihmiset ja
liiketoiminta ihmiset puhuvat samoista asioista eri kielillä. Mitä tarkoittaa
“asiakas”? Entä “tuote”? Catalogin avulla sekä data-ammattilaiset että
liiketoiminta ihmiset saattoivat määritellä ja arvioida käsitteitä samassa
paikassa – yhdessä. Mikon mukaan ajatus oli oikea ja tuote toimi, mutta oli
käyttäjän näkökulmasta kenties hieman tekninen. Visio oli aikaansa edellä.

Nyt visio alkaa näyttää todelta

Kun kävimme Mikon kanssa läpi Qlikin uusimpia julkaisuja, tunnelma oli selvä:
tämä on sitä, mitä 2018 tavoiteltiin – vihdoin kypsänä muotona.

Kolme asiaa erottuu erityisesti:

• Data saadaan kaikkien näkyville – Data Marketplace toimii yhtenä
ikkunana organisaation datoihin.
• Datan laatu selviää – Trust Score kertoo selkeästi, kuinka luotettavaa
data on. Ei enää arvailua.
• Dataa voidaan helposti jakaa eteenpäin – REST- tai OData-
connectorin kautta data liikkuu sujuvasti jatkokäyttöön.

Ja parasta kaikessa? Kaikki tämä löytyy yhdestä käyttöliittymästä: olennaiset
datatuotteet, niiden laatu, missä niitä käytetään, mistä data on peräisin ja
minne se kulkee – Data Lineage kertoo koko tarinan.

Miksi tämä on tärkeää juuri nyt?

Data ei ole enää vain raportoinnin raaka-aine. Kun tekoäly ja AI-agentit
hyödyntävät dataa yhä enemmän, datan laatu, löydettävyys ja luotettavuus
nousevat aivan uuteen arvoon. Jos AI saa syötteekseen huonoa tai
väärinymmärrettyä dataa, seuraukset voivat olla vakavia.

Qlik Cloudin uudet ominaisuudet vastaavat juuri tähän tarpeeseen. Kun
datatuotteet on määritelty selkeästi, niiden laatu on arvioitu ja ne ovat helposti
saatavilla – niin ihmisille kuin koneille – ollaan oikeasti valmiita tekoälyaikaan.

Yhteenvetona voinee todeta: hyvät ideat löytävät aikansa!

Podium Datan visio oli oikeassa. Se syntyi vain hieman ennen aikojaan. Nyt
teknologia, markkinat ja tarve ovat kohdanneet – ja Qlik Cloud vie tätä
kehitystä eteenpäin tavalla, joka saa kokeneenkin Qlik-ammattilaisen
hymyilemään. Mikolle se on selvästi palkitseva hetki.
Seuraamme kehitystä innolla Mikon kanssa ja autamme asiakkaitamme
Goodinilla ottamaan nämä mahdollisuudet käyttöön.

Terkuin, Mats (von Hertzen), GOODINilta

Kiinnostuitko? Laita meille viestiä!

2024 was a defining milestone for Qlik, as highlighted in our previous review by our Business Intelligence Lead and Managing Partner, Phuoc Tran Minh, in early 2025. Strategic goals were met, and the integration of Talend solidified Qlik’s position as the market’s most robust data integration platform.

But what lies ahead? 2025 and the beginning of 2026 have marked a fundamental shift in the ecosystem: moving from passive reporting to active, “agentic” analytics. Here are the key innovations shaping the daily operations of Qlik users right now.

1. From Assistant to Agent: The Rise of Agentic AI

If 2024 was the year of experimenting with Generative AI, 2025 was the breakthrough year for Agentic AI. Qlik no longer simply answers questions; it takes action.

These new AI agents execute complex sequences of tasks autonomously. They can detect an anomaly in sales data, analyse the root cause by comparing multiple data sources, and automatically generate a proposal for next steps – all without the user needing to build a query. Qlik Answers is pivotal here, integrating unstructured data (contracts, manuals, PDFs) into the analysis to ensure a true 360-degree view of the organisation.

2. Qlik Trust Score™: AI is Only as Good as Its Data

The biggest barrier to AI adoption is a lack of confidence as we know at GOODIN. Qlik addresses this with the Qlik Trust Score for AI, which automatically scores the reliability of data. As businesses build their own custom models on top of Qlik, the Trust Score ensures that AI does not draw conclusions based on flawed or outdated information. It is the “green light” management needs for automated, defendable decision-making.

3. The February 2026 Breakthrough: The Qlik MCP Server

The most significant update in early 2026 is the general availability of the Qlik MCP (Model Context Protocol) Server. This is a game-changer for AI Interoperability.

Rather than locking your data inside a single platform, MCP acts as a universal “USB-C port” for AI. It allows third-party assistants – such as Anthropic Claude, Microsoft Copilot, or your own internal LLMs – to securely “reach into” Qlik’s engine. This means your external AI tools can use Qlik’s governed measures and logic to provide answers that are actually accurate and grounded in your business reality. Here is more info!

“Qlik has gone so far beyond visualisations and dashboards: it has become the trusted intelligence layer for your entire enterprise AI ecosystem.”

Says Phuoc Tran Minh

4. Next-Level Integration: The Open Lakehouse

The Qlik-Talend merger has matured into a seamless Open Lakehouse architecture. In 2026, there is a massive emphasis on real-time data movement across Snowflake, Databricks, and AWS. Native support for the Apache Iceberg format allows enterprises to store vast quantities of data cost-effectively while avoiding vendor lock-in. Data quality is now managed by AI-assisted tools that rectify errors automatically as data moves through your pipelines.

5. User Experience: Beyond the Dashboard

Analytics visualisation has undergone a significant makeover to drive operations, not just viewing: Write-back Capabilities: Users can now modify or input data directly from a Qlik sheet back into source systems (like CRMs or ERPs). Discovery Agents: New “always-on” agents monitor your metrics 24/7 and proactively alert you to meaningful trends or anomalies before you even open a dashboard.

Conversational Interface: Interacting with data through natural language is now the standard. The dashboard has evolved from a primary interface into a supporting visual for deeper context.

Towards Autonomous Analytics

At GOODIN, we have followed Qlik’s journey closely, and the direction is clear: analytics is shifting from the “rear-view mirror” to real-time operational guidance. The Qlik MCP capabilities added in late February 2026 represent a “safe harbour” moment – providing a standardised, governed way to connect any AI tool to your most valuable data.

“The innovations of 2025–2026 represent a new era where data is a company’s most active asset. Agentic capabilities are already delivering massive value to end-users by automating the “boring” parts of data analysis and focusing on what matters: action.”

says Mikko Kuusela.

Is your organisation ready to leverage Qlik’s latest Agentic and MCP capabilities? At GOODIN, we help you translate technology into measurable business value and can train your entire organisation to make use of data and AI.

Reach out to our CEO Jarmo Rajala or Mikko Kuusela, Petri Viljanen, or Siru Saaristo. We are happy to help you find better ways to get the most out of your data and AI!

Our Business Development Lead Mikko Kuusela has worked in analytics for nearly three decades. This is the story of what he learned – and why one question stayed with him the entire journey.

Mikko has a habit of saying that his career has become more technical than he ever imagined as a young economics student.
But perhaps that’s exactly why he has held so firmly to one core idea. The most important job of technology is not to look complex. Its job is to help people succeed.

Where it all began

The year is 1997. Mikko starts his career at BasWare, working with budgeting and forecasting systems. Oracle consulting follows, then reporting, then business. Early on, a conviction takes shape that never changes:

The best solutions do not emerge on technology’s terms. They emerge when technology genuinely serves the business – with people at the centre.
In 2005, Mikko returns to BasWare and encounters QlikView. It changes his thinking. It is no longer just about reporting, but about analytics: the opportunity to understand the business more deeply, to spot patterns, to make better decisions.

#Qlik technology has been part of his career ever since. Around 20 years in total, more than 15 of them with Qlik directly.

The question that never went away

Alongside everything he learned, one thing kept nagging at Mikko. What if data entry could live in the same interface?
If viewing, analysing, and updating information could all happen in one place, a solution like that would serve the business in an entirely different way. No separate Excel files. No system-hopping. No unnecessary intermediate steps.

It’s a question he has heard from clients over the years countless times, too.

The answer arrived six months ago.

About six months ago, Mikko came across #Inphinity. He was immediately excited.

Inphinity enables data entry directly within Qlik – in the same interface where data is also analysed. No more separate processes, no more separate systems. One environment, one whole.

The concrete impact was visible quickly. In a client project, key metrics from around 50 companies were brought together into a single Qlik environment. Data entry, review, and utilisation – all in one place. It worked.

Why this matters – from a data empathy perspective

At GOODIN, we talk about data empathy. It simply means that data and solutions are not built for systems – they are built for people. Understanding users’ day-to-day reality and understanding what stories the data tells. Understanding the genuine needs of the business. Building something people will actually use.

When the process feels natural, users trust the data. When users trust the data, the organisation makes better decisions.
That is exactly what Inphinity delivers – and exactly what Mikko’s story is about.

30 years in analytics creates a certain level of #DataEmpathy

“The job of technology is not to look complex. It’s job is to help people succeed.” — Mikko Kuusela, GOODIN

#GoodIn #DataEmpathy #Qlik #Inphinity #Analytics #PeopleOverProcesses

1. Half still have no real touchpoint

Around 50% of participants have never opened an LLM before the course. This isn’t about the technology—it’s about caution, uncertainty, and the lack of guidance. Once people start experimenting in a supported environment, the hesitation fades quickly. Many express the same thought: “I didn’t know what I was supposed to ask, so I didn’t dare to start.”

2. Usage falls into three clear levels

Among those with at least some experience, usage forms a consistent three-tier structure:

• 90% use LLMs very lightly: translations, summaries, and simple edits.
• 10% use them more actively, but still at a surface level. Few users actually use frameworks, build consistent logic, or design workflows around the model.
• Deep usage is extremely rare.
  • Custom GPTs, structured tools, and process-level thinking are still marginal.

This pattern repeats across almost every organisation.

3. Agents generate interest – but they are not simple

Agents and custom GPTs now come up in almost every discussion compared to early 2025. Interest is strong, but real hands-on work is still limited. Across our training groups:

• About 50 people have built a custom GPT.
• About 20 people have built an agent (usually as a team).

Building an agent isn’t a “just do it” button. It requires quiet technical intuition, process thinking, and a willingness to experiment. Many are only now developing these foundational skills. This is why claims that “2025 is the year of agents” is more about marketing than reality. The real “agent year” in everyday work is likely closer to be realised end of 2026–2027.

4. Understanding is rising quickly – usage more slowly

Between January and November, the change is clear:

• People now better understand what LLMs do and don’t do.
• They recognise the importance of context.
• The model is seen more as a conversation partner, not just a text machine.

Yet everyday use is still largely task by task, not a continuous partnership with the model.

5. The “sparring partner” mindset works

One of the strongest findings relates to mindset. When the model is seen as a sparring partner, usage becomes more natural and relaxed. In our courses our mission, which is stated at the start of the course, is to make LLMs your sparring partner. At the end we ask how we succeeded and the results are striking:

• 95% of participants respond to our feedback survey.
• Of those, 97% say the model became a sparring partner during the course (N=1000).

Once people understand how an LLM works and where its limits lie, their usage becomes instinctive. The barrier isn’t technical—it’s emotional.

6. The biggest shift is in thinking, not yet in routines

The most notable change in 2025 is not what people do with LLMs. It is that more and more people understand what an LLM is, what it can be used for, and how it should be used. This unlocks internal conversations, role clarity, and new ways of dividing work.

And the one fact: The term “Artificial Intelligence” as a singular is the most misguiding term and should be completely abolished to create better understanding.

What does this tell us about Finnish organisations in 2025?

Based on everything we’ve seen in our training data, the situation looks like this:

🙌 Interest is growing relatively fast, but not like we inside the “AI bubble” think.

🙌 Usage is growing slowly—especially if the emotional barrier isn’t lifted.

🙌 Deep usage is still rare. People think this is a new Google, and naturally that will limit exploration as what you do with Google is already a habit—and as we know habits are hardest to change.

Finland is now in a phase where understanding is expanding, but everyday AI-Human working habits are still forming. This is a natural stage—and right now is the ideal moment for organisations to build their LLM strategy before the next major shift arrives.

Key Takeaways from #Harvest event 9 October 2024

Generative AI (GenAI), and artificial intelligence (AI) in general, is no longer a promise of the future; it’s the reality of today. During the Harvest event on October 9th, 2024, it became clear that AI’s potential, particularly GenAI, is immense, yet many organisations are still standing on the sidelines.

Why? Not because the technology isn’t mature—it is. The real challenge lies in the myths and misunderstandings that continue to slow its widespread adoption. As DB Schenker’s Samuli Salmela explained in his keynote speech, these misconceptions prevent businesses from fully embracing the transformative power that GenAI, especially, offers.

As leaders, it’s time for us to move beyond the myths and recognise AI as a strategic partner, not just a tool. AI can bring profound improvements to our organisational processes and, ultimately, transform the entire business. The question is no longer whether AI is ready – it is. The real question is whether our companies are ready to learn, experiment, and utilise AI in the right way. The businesses that seize AI’s opportunities now will thrive, while those waiting for the “perfect moment” – that never comes – will be left behind.

Let’s explore the key takeaways and insights from the event by addressing the most prominent myths about GenAI and their practical implications for our organisations in overcoming them.

Myth 1: “AI is difficult and expensive”

This belief often stems from a fear of the unknown. In reality, AI has become increasingly accessible, with many easy to use  tools available. The real challenge lies not in the technology itself, but in our willingness as people to adapt. As leaders, we must reframe AI as an investment in both the company’s as well as the people’s future rather than a burdensome expense or a new thing that ends up benefitting no-one.

Myth 2: “GenAI makes mistakes, so it needs constant human supervision”

While it is true that AI is not infallible, neither are humans. The key is to view AI not as a replacement for human intelligence, but as a powerful complement to it. This symbiosis of human intuition and machine processing power can lead to unprecedented insights and innovations for both organisational, as well as wider, good. A need for human oversight in AI related projects depends greatly on the use case and its risk profile. As we learn to understand and trust AI more, we can relax the oversight.

Myth 3: “We don’t have good enough data to use AI”

Perfect data is a mirage. Instead of waiting for an ideal dataset, we should focus on cultivating a data-driven culture where continuous improvement is the norm. AI can actually help us identify gaps in our data and AI can also allow us to start utilising unused or previously difficult-to-use data assets. AI can also refine our collection processes, so again, rather than thinking of it as a technology, think of it as an added competence to your organisation and treat it accordingly. 

Myth 4: “Our data is not safe with GenAI”

In an age of increasing digital threats, this concern is valid. However, it should not paralyse us. Instead, it should motivate us to implement robust data governance frameworks. By doing so, we not only protect our assets but also build trust with our stakeholders. It is also important to use technologies that are secure and enterprise-grade, such as the Microsoft offering.

Myth 5: “AI doesn’t really think”

This myth touches on deep philosophical questions about the nature of intelligence. While AI may not “think” in the human sense, it can process information and identify patterns at a scale beyond human capability in certain cases. Our role as leaders is to harness this power while providing the context, creativity, and ethical considerations and judgement that only humans can offer. This is one of the reasons it is important to focus on your people at the same time as you focus on technology.

Myth 6: “It’s just hype. Companies aren’t getting real benefits”

Scepticism is healthy, but it should not blind us to the real-world impacts of AI. From predictive maintenance to personalised customer experiences, AI is already delivering tangible benefits across industries and will also require a new set of measuring benefits. As leaders, we need to look beyond the hype and focus on practical applications that can drive our businesses forward. AI is like any major technology disruption; its short term implications are overestimated and long term impact under-estimated.

Myth 7: “The models aren’t ready; it is better to wait”

In the rapidly evolving world of AI, waiting for perfection is a luxury we cannot afford. The most successful organisations will be those that adopt a “learn fast” mentality, embracing current AI capabilities, while staying agile enough to adapt to future developments.

Building a Human-Centric, Data-Driven Culture: The Key to Successful AI Adoption

It is essential to remember that adopting AI goes beyond technology—it fundamentally revolves around people. To fully realise AI’s potential, the entire organisation must be engaged in the journey.

Since we’ve been talking about AI like a colleague, we figured, why not ask Copilot  itself, which of these myths resonated the most? “The myth that struck a chord was, ‘GenAI makes mistakes, so it needs human supervision.’ While it’s true that responsible AI use requires oversight in critical fields like healthcare, where accuracy and ethics are non-negotiable, the idea that GenAI always needs human supervision is a bit outdated.

This requires cultivating a culture that embraces data and AI literacy, with human leadership at its core. Such a culture encourages curiosity and experimentation, valuing human creativity and judgement. In this way, employees see AI tools as enablers rather than fearing replacement. This approach creates an environment where both human and artificial intelligence can thrive, laying the groundwork for genuine innovation and growth.

But as any good farmer knows, harvesting is only the beginning. The true value lies in how we refine those fruits—transforming them into products, services, and tangible results that drive real organisational impact. And just as importantly, we must sow new seeds for future growth by budgeting wisely and investing in the AI capabilities that will shape the years ahead. After all, success isn’t just about this harvest; it’s about laying the foundation for future seasons of prosperity.

Authored by:
Kira Sjöberg, GOODIN, Sami Masala & Nino Ilveskero, AIThink & CoPilot, Microsoft. 

Understanding the Learning Stages People in Organizations go through

1. Beginner Level: Grasping the Basics

The journey begins with foundational knowledge. For data literacy, this includes understanding data types, basic data manipulation, and the significance of data in decision-making. For AI literacy, it involves an introduction to AI concepts, what AI can and cannot do, and real-world applications. At this stage, short, introductory sprints focused on key concepts help demystify complexities and lay the groundwork for more advanced learning.

2. Intermediate Level: Enhancing Skills through Application

Once the basics are understood, employees should start applying their knowledge to real-world scenarios. This could involve structured projects or challenges where learners manipulate datasets or build simple AI models relevant to their roles. This stage is crucial for reinforcing concepts and gaining confidence. Naturally understanding that not everyone will utilize data or AI on this level in their roles, but understanding the side of applying is important. Generative AI utilization is however another relevant application mode often in such cases. Organizations can support this through workshops, guided training sessions, and practical hands-on projects that encourage active learning. One example of this is the GOODIN and Splended Data Learning Sprint.

3. Advanced Level: Specializing and Innovating

As learners become more comfortable, they can move into specialized areas such as predictive analytics, machine learning, and advanced data visualization techniques for data literacy. For AI literacy, this might include deep learning, neural networks, or robotics. Advanced learners should engage in longer, more complex sprints that challenge their understanding and encourage innovation within their specific areas of interest. This demands a “fail fast” or “learning by doing” -type of learning culture in organizations and positive and encouraging management practices and commitment that enable failing for learning.

4. Expert Level: Leading and Mentoring

At the expert level, individuals are expected not only to be proficient but to lead initiatives and mentor others. They stay abreast of industry trends and continuously adapt to new technologies. Here, learning involves self-directed projects, leadership in sprints, and contributing to strategic decision-making with data-driven insights become real life value for business.

Implementing Learning by Doing: The Sprint Method

A learning sprint approach can be highly effective in progressing through these stages. Each sprint focuses on a specific skill or project, encouraging rapid learning and application. Here’s how it can work:

• Define Clear Objectives: Each sprint has specific, measurable goals to ensure focus and alignment with business objectives.
• Time-bound Challenges: Limit sprints to a few weeks to maintain urgency and engagement.
• Cross-functional Teams: Include employees from different departments to foster diverse perspectives and collaborative problem-solving.
• Reflect and Iterate: At the end of each sprint, gather feedback and reflect on lessons learned to improve the next cycle.

Supporting the Journey

Supporting employees through this journey requires more than just providing educational resources; it involves creating an ecosystem that promotes continuous learning and application. This includes access to the latest tools and technologies, opportunities for peer learning, and a culture that celebrates experimentation and learning from failure.

As they become more fluent, they will be able to leverage these skills to innovate and lead in their respective fields, ensuring the organization stays competitive in a data-driven future making sure the human drives the AI and not vice versa.