Dieser Artikel ist auch auf Deutsch verfügbar
TL;DR
- Core problem: Data platforms don’t fail because of technology – they fail because people lack the skills to work with data effectively.
- Virtuous cycle: Data access and data literacy reinforce each other – access sparks curiosity, competence drives adoption, adoption generates new data.
- Motivation: Individual benefit matters more than organizational goals – leaders must model data-driven work, not just demand it.
- Learning system: Enabling teams, communities of practice, and a human-centered platform turn a tech project into a social learning process.
- AI reality check: Precisely because AI answers sound convincing, data literacy is the prerequisite for spotting errors.
The interplay between data literacy and data access
There are several definitions of data literacy. I really like the definition given by Jordan Morrow in his book Be Data Literate:
Data literacy is the ability to read, work with, analyze, and communicate with data. (Morrow, 2024, p. 36)
Morrow writes that not everyone needs to become a data scientist, but people should have these skills to succeed in today’s world. But, in my view, such learning efforts remain largely theoretical without access to data. Data architectures based on federation and data products, such as Data Mesh, can alleviate this problem because companies that implement these concepts should allow access to all company data where legally possible. However, such open data availability leads to chaos without data literacy, because without the ability to understand data and use tools, the likelihood of misinterpretation is very high. Together, however, data availability and data literacy form a symbiotic cycle:
When we are provided the opportunity to access data that is relevant to us (data access), curiosity can develop. This curiosity creates the basis for motivation to learn, which leads to new skills in working with data. This data literacy has the desired effect: the platform is used, which in turn leads to greater data variety on the platform. This makes further data available, which in turn may be of interest to others, and the cycle continues.
A well-designed data platform can reinforce this cycle by making data accessible and supporting users in handling it responsibly. Architectures that distribute data responsibility to the teams who know the data best can provide this foundation. By this, I mean architectures in which a central data team does not manage and provide all data, but rather domain teams act as autonomous owners of their data products. A data product is more than just a dataset; it is a clearly defined, documented and reliably maintained offering of data, developed specifically for use by others. In this article, when I refer to data product oriented architectures, I am not necessarily referring to a fully mature Data Mesh as described by Zhamak Dehghani. I am presenting a spectrum ranging from the initial steps towards decentralised data ownership to the full implementation of the four principles. However, the core idea remains: data responsibility belongs with the teams that know the data.
The rapid rise of large language models has made this cycle even more urgent, making it clear how much the value of these technologies depends on the quality of the underlying data. Organisations without reliable, well-structured and accessible data will find little value in AI initiatives. Therefore, data literacy and solid data architecture are not only prerequisites for data-driven decision-making, but also the foundation for the meaningful use of AI.
But how can we ensure that these users actually start using the tools, understand how to use them properly, and know how to interpret data correctly? The answer is straightforward, but implementing it is anything but: organizations need employees who are data literate.
“What’s in it for me?”: Generating interest in data literacy
The motivation to work with data does not always come naturally. In his book Humanizing Data Strategy, Tiankai Feng (2024) describes several exciting ways in which data strategies can be implemented sustainably. However, I would like to highlight one particular point: the individual benefits for employees are at least as motivating as the benefits for the organization. People use data when it makes their everyday work easier. Once they have mastered the tools on offer, workflows can be automated and thus simplified. If teams can increase their productivity and innovative strength, this not only helps them in their personal success and development but also the entire organization (Feng, 2024).
Managers have a unique role to play as role models. They exemplify working with data and create incentives to engage with it. This means they work with the data themselves and demonstrate this to their employees, encouraging them to do the same. It is crucial that communication is not only with data but also about data and the successes that have been achieved through its use. Examples include publishing data projects that have been successfully implemented or using gamification in learning path design.
Enabling Team & Community of Practice
The development of data literacy is supported by social structures. On the one hand, it can be driven forward by so-called enabling teams. This type of team is described in detail in Chapter 5 of Team Topologies (Skelton & Pais, 2019). This team works closely with the domain teams, coaching, accompanying, and supporting the practical development of data products through workshops, self-service offerings, or by actively fostering collaboration between teams that exchange data. The successes of an enabling team are almost always indirect, which is why clear support from managers is necessary. They must protect time for learning and reward collaboration (Skelton & Pais, 2019).
A community of practice dedicated to the topic of data keeps the learning process alive. It connects everyone who works with data, enables the exchange of positive and negative experiences, creates knowledge, for example about data quality, and establishes common standards. In this way, it complements the enabling team: the enabling team specifically creates new skills, while the community ensures that this knowledge is broadly anchored and the cognitive load is reduced by pre-filtering relevant content for the organization. Together, they make learning a continuous, social process.
Introducing a data product oriented architecture is not merely a project plan but rather the establishment of a learning system. To provide our employees with appropriate learning paths, learning aids, and tasks, we need to know them very well and group them according to skill level and areas of interest. Enabling teams can identify knowledge gaps and a good community promotes effective working methods and provides a forum for discussion of controversial topics. These feedback loops keep the transformation toward a data-driven organization going and make the data platform a living system.
The platform as a catalyst
In addition to social structures, the implementation of the technical platform is a key pillar for successfully rolling out a data product oriented architecture. The platform should promote engagement, not discourage it. This means that users must be the focus when selecting or building tools. For example, we use tools such as Terraform, which software engineers are already familiar with, for deploying data products. For non-technical users, we link data sources to familiar programs such as Microsoft Excel or Google Sheets.
The familiar tooling is not always sufficient to offer competent users all the options they need to make full use of the data. For example, users with a certain level of maturity in data analysis may also want to use BI tools such as Microsoft Power BI or Tableau. When it comes to software and data engineering tools, a basic knowledge of a tool is often not enough to be able to implement it in a specific environment without tedious trial and error. Clear documentation, simple onboarding processes, sensible defaults, and automated quality checks must be part of the design.
If tools are unfamiliar, they should be learnable within a reasonable amount of time because otherwise, the wrong lesson will be taught. It is important that employees internalize working with data. Programs and software libraries should primarily be understood as vehicles. This does not mean that the introduction of a new technology cannot serve as motivation. This is particularly appealing to tech-savvy employees. However, a technically brilliant but cognitively overwhelming platform is usually not accepted by users.
Making success measurable
We cannot force acceptance of our platform. Since not every organization is the same, there is no one-size-fits-all solution when it comes to creating learning paths and selecting tools. However, we can demonstrate our own data expertise by monitoring and analyzing the rollout process to make adjustments where necessary.
Relevant metrics include, for example:
Competence building — Are people actually developing new skills?
- Workshop participation indicates interest and shows that our measures are being adopted.
- The number of data products independently delivered by domain teams shows that what has been learned is also being applied.
- Regular surveys on data confidence reveal whether employees feel secure enough to use data in their decisions.
Cultural signals — difficult to measure, but particularly meaningful
- When data products are reused across domain boundaries, genuine collaboration emerges.
- Fewer ad hoc requests to the central data team indicate that teams are increasingly able to work independently.
- Internal and external talks or blog posts by employees on data usage signal that a data culture is not only being lived but actively passed on.
Platform usage — Is the platform making an impact in day-to-day work?
- The number of active users and published or reused data products indicates whether the system is growing or stagnating.
- Time to data access is particularly critical: if it is too long, the cycle of curiosity and learning breaks down right at the start.
Platform usability — Useful for real people with real tasks?
- Which features are preferred, which are avoided?
- Where do users abandon interaction paths?
- Are data products found and then actually used?
We should not use these metrics to make ourselves look good to the outside world or gloss over the success of our projects. They are mirrors that show whether people are learning, working together, and trusting the system. And that is precisely how we must use them.
The elephant in the room: Data Literacy & AI
Few topics currently dominate corporate discussions as much as artificial intelligence. AI tools are being connected directly to company data more and more. The idea is simple: ask a question and receive an immediate answer. “Talk to your data” is no longer just a vision for the future; the actual possibilities are impressive. Relationships that previously required deep specialist knowledge and considerable time can now be explored in a matter of minutes. This significantly lowers the barrier to entry and can considerably speed up the cycle of data access, curiosity and expertise.
However, this opportunity also brings with it new responsibilities. Large language models can produce answers that are factually incorrect but sound convincing. Those unfamiliar with the underlying data and lacking basic skills in working with it will not recognise such errors. Therefore, data literacy is not an alternative to AI tools, but a prerequisite for using them responsibly. It enables people to question, contextualise and act on answers with care.
I see chatbots and similar tools as further tools in our ecosystem to which data should be made available in a targeted way, just as with Excel or Power BI. The difference is that errors are harder to spot here because the output appears as a definitive statement rather than a traceable formula. In this context, data literacy means being able to recognise errors and other inconsistencies.
References
Morrow, J. (2024). Be Data Literate: The data literacy skills everyone needs to succeed (2nd ed.). Kogan Page
Feng T. (2024). Humanizing Data Strategy: Leading Data with the Head and the Heart. Technics Publications
Skelton, M., & Pais, M. (2019). Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press