Aritra Acharya explains why data literacy, governance, adoption and business alignment must come before organizations can generate trusted value from AI.
During a recent conversation on The Executive Outlook, Aritra Acharya raised a distinction that many organizations accelerating their AI investments have yet to fully confront.
The greatest obstacle to becoming data-driven is rarely the absence of technology. More often, it is the absence of understanding, trust, ownership and alignment around the technology already in place.
This challenge existed long before the current AI wave. Organizations built dashboards that employees did not use, analytical models that failed to answer real business questions, and governance frameworks that struggled to create lasting change.
AI may amplify these problems rather than solve them.
He has spent more than fourteen years building data strategies, teams and platforms across retail, finance, ecommerce and aviation. He began his career in 2012 as a data warehouse developer, at a time when the title “data engineer” was not yet widely used.
Initially, he did not expect data to become his long-term career.
He planned to master the domain and eventually move into another area of technology. Instead, every new capability led him deeper into the field. Data warehousing led to modelling. Modelling led to reporting. Reporting led to governance, business intelligence, and eventually the leadership challenge of connecting technical capabilities with business priorities.
He describes the data domain as an octopus. It never completely lets you go. Every time one area becomes familiar, another develops and demands attention.
For him, the people who thrive in data are those who stop treating this constant evolution as a problem and begin treating it as the nature of the profession.
One of the most consistent problems Aritra has encountered is the development of strong analytical solutions that never achieve meaningful adoption.
The problem is not always that the analytics is technically incorrect. It is often that the solution does not address the actual requirement of the people expected to use it.
He has experienced this mistake himself.
A data team may build what it believes is the best possible model: sophisticated, comprehensive and technically sound. The team expects it to solve major organizational problems. Yet stakeholders continue relying on spreadsheets, manual processes, or older reports.
This does not necessarily mean that the business is resistant to data.
The business may simply have needed easier access to a specific dataset or a direct answer to a particular question. Instead, it received a complex model designed around the data team’s definition of quality rather than the business team’s definition of usefulness.
The same risk now exists with AI.
Organizations may assume that an AI-enabled solution will be adopted because it is advanced. But sophistication alone did not create adoption for dashboards or analytical models and it will not create adoption for AI systems built on the same misaligned foundation.
He believes the solution begins with closer structural alignment between business and data teams.
One approach is to involve a business product owner who understands the operational context and works closely with technical teams throughout delivery. This reduces the distance between the problem being experienced and the solution being designed.
It also allows the feedback loop to begin much earlier.
An 80% solution developed with active input from the right users may generate more value than a technically perfect solution delivered after three months, only to discover that it does not address the business need.
Organizations that develop strong data cultures do not wait until the end of a project to show stakeholders what has been built. They share progress, gather responses, test assumptions and adjust direction throughout the process.
By the time feedback arrives after a long development cycle, changing course may already require significant time, cost and rework.
He has explained data literacy to senior executives across several organizations. He acknowledges that the theoretical definition is much easier to communicate than the practical reality.
In theory, data literacy means that people across an organization can read, understand, discuss and explain data.
In practice, it means understanding more than the numbers displayed on a dashboard.
A report may show that revenue reached seven million while costs reached five million. That information provides a picture of what happened. It does not explain why it happened, what influenced the outcome, whether the figures can be trusted, or what action should follow.
Data literacy begins when people can move beyond observing a number and start questioning the conditions that produced it.
The common misconception is that data literacy is primarily a skill for data teams. He argues that its greatest importance lies outside the data function.
The data team already works with data every day. The broader challenge is whether finance, operations, sales, marketing, customer service and other teams can understand the outputs they receive and use them responsibly.
He describes a practical, multi-level approach to data literacy.
At the basic level, a person can read a dashboard and understand what individual metrics represent.
At the next level, that person can connect different metrics, perform basic analysis, identify changes and ask meaningful questions about patterns.
A more advanced level is reached when someone can recognise that an unexpected result may originate from a data quality issue in a source system.
He recalls a situation in which costs were not adding up correctly because one data column had been entered incorrectly. The impact was not limited to a single cost metric. It influenced profitability, working capital, and elements of the revenue model.
The greatest organizational value begins to emerge when business users can identify these patterns and trace problems closer to their source without depending on the data team for every investigation.
The most advanced level remains within specialist data teams that understand full data lineage, system relationships, technical dependencies and the way one quality issue can affect multiple outputs.
The objective is not to turn every employee into a data engineer. It is to give people enough understanding to question data, recognise potential problems and make decisions with greater confidence.
One of Aritra’s most practical lessons concerns the way data teams gather requirements.
Stakeholders often approach technical teams with a proposed solution rather than a clearly defined problem.
They say, “I need a dashboard.”
The risk is that the data team accepts this statement as the final requirement and begins building immediately.
He prefers to challenge the request by asking why.
Why is the dashboard needed?
Because the stakeholder needs insight into a particular metric.
Why is that insight important?
Because it will support a specific action.
Why must that action be taken?
By continuing this process, often through the Five Whys method, the team can uncover the real operational requirement behind the initial request.
He gives the example of a stakeholder who wanted a static dashboard to monitor a live programme. Further questioning revealed that the requirement involved real-time or dynamic monitoring, something a conventional static dashboard could not adequately provide.
In another case, a stakeholder wanted a dashboard showing how many resources should be assigned to a shift. The deeper question was not simply how many people were currently available. It was how many resources should be kept in reserve for an upcoming shift.
That is a forecasting and resource-planning problem, not merely a reporting problem.
The question behind the question is where effective data leadership begins.
A team can deliver exactly what was requested, on time and within scope and still produce little business value. Another team may challenge the original specification, uncover the real problem, and develop a much more useful solution.
He recognises that this approach can create friction.
Stakeholders may feel that their requests are being questioned or delayed. His advice is to find one sponsor who believes in the process, demonstrate the value created through deeper discovery and use that success as evidence when scaling the approach across the organization.
He considers data governance one of the most challenging areas he has worked in throughout his career.
The difficulty is not primarily technical. It is human.
Governance programmes often begin from the top. Senior leaders approve a framework, create a governance board, introduce data quality checks and invest in tooling.
The initiative begins with energy and visibility.
Then the follow-through weakens.
People attend governance meetings, return to their teams and continue working as they did before. Issues are documented, but ownership remains unclear. Quality scores are reported, but decisions are not made.
The governance structure exists, but behaviour has not changed.
The reason is that the initiative was introduced before the organization developed the awareness and culture required to sustain it.
A data-driven culture is not created simply by announcing a governance framework. It develops when people understand why the data they work with matters, how poor-quality data affects the outcomes they care about and what becomes possible when information is reliable.
He identifies ownership as another major failure point.
People sometimes interpret data ownership as control.
“I own this data, therefore I decide who can access it and what can be done with it.”
For him, that interpretation works against the purpose of governance. Ownership should represent responsibility for quality, definition, availability and appropriate use. Governance should help data move across the organization accurately and responsibly, not allow one team to isolate it.
The second failure point is the absence of decisions.
An organization may discover that a dataset is 91% complete. That finding may lead to discussion, presentations, and meeting notes. But unless someone decides whether the organization should invest in reaching 95%, or whether 91% is acceptable given the cost and business impact, nothing has been governed.
Governance that produces documentation without decisions creates the appearance of progress without improving the quality or use of data.
His advice is to demonstrate the impact of governance rather than relying only on top-down enforcement.
Show people what becomes possible when data is trusted. Connect quality improvements with fewer operational errors, better customer experiences, faster analysis, or stronger financial decisions.
The objective is to make people want effective governance because they understand its value, not simply because a committee has required it.
One of the most expensive lessons he has experienced involved a data platform built for the organization’s current scale rather than its expected growth.
A solution designed to handle 100 gigabytes may not continue working effectively when the volume reaches one terabyte.
As demand grows, the platform may not fail all at once. Instead, it becomes increasingly unstable. Teams spend more time resolving performance issues, fixing pipelines and maintaining temporary workarounds.
In Aritra’s experience, as much as 80% of the team’s capacity became focused on resolving infrastructure problems rather than delivering new analysis and business value. The architecture eventually had to be reconsidered within months.
The lesson is not that every organization should build the most expensive possible platform from the beginning.
It is that budget limitations should lead to a basic version of the right foundation, not a temporary architecture that cannot support the organization’s likely direction.
The cost of rebuilding a platform is not only technical. It includes lost productivity, delayed insights, operational instability, repeated implementation costs and frustration across the business.
This is why scalability should be presented as a financial and strategic conversation rather than only an engineering preference.
For him, leading a data function means constantly negotiating between valid but competing priorities.
Engineering teams naturally want to build robust, scalable and technically strong solutions. Business teams need results quickly and cannot always wait several months for a fundamental insight.
Neither side is necessarily wrong.
The responsibility of the data leader is to maintain the balance.
Moving too quickly can create technical debt that eventually slows the organization down. Pursuing technical perfection can delay value until the business opportunity has passed.
The answer is not to choose speed or quality in isolation. It is to understand which compromises are temporary, which foundations cannot be compromised and what level of investment is justified by the expected outcome.
This also requires data leaders to communicate in business terms.
A technical platform does not create value simply because it is modern or sophisticated. Its investment must be connected to outcomes such as improved customer experience, higher net promoter scores, reduced customer service costs, stronger revenue opportunities, greater operational efficiency, or measurable return on investment.
As leaders move away from purely hands-on roles, the ability to translate technical requirements into business impact becomes as important as technical knowledge itself.
The build-versus-buy question follows the same principle of aligning technology with organizational strategy.
He considers three questions before recommending a direction.
The first is whether data is a core revenue-generating product or primarily an enabling capability.
When data is central to what the organization sells and differentiates in the market, he is more inclined toward building internal capabilities. When data primarily supports internal decision-making, operations, analytics, or future AI use cases, buying may offer a more practical starting point.
The second question concerns internal capabilities.
Does the organization have the team size, expertise and specialist resources required to build and maintain the platform?
Building a platform requires more than data analysts and engineers. It may also require cloud platform engineers and other specialists who are expensive to recruit and retain.
The third question is how much scale the organization expects over the next two or three years.
A solution should reflect not only current demand but also the direction of the organization’s products, customers, data volumes and analytical ambitions.
In many cases, he recommends buying first.
A commercial platform allows teams to begin working, learn how their data behaves, develop internal skills, and understand their requirements before making a larger investment in custom development.
This does not mean that buying is always the final answer. An organization may later replace, extend, or gradually retire purchased capabilities as its strategy and internal maturity evolve.
The important point is that the cost comparison should not be limited to a software subscription versus building something internally.
The true comparison includes recruitment, salaries, infrastructure, maintenance, technical support, specialist knowledge, upgrades, reliability, and the long-term opportunity cost of the internal team’s time.
When these costs are evaluated together, buying can often be more economical and less risky during the early stages of a data journey.
Across Aritra’s perspective, one idea connects every part of the conversation.
The most serious obstacles to data and AI transformation exist around the technology, not only within it.
They are found in requirements that were never properly questioned, analytical products that were built without users, literacy that was never developed outside the data team, governance that was introduced without cultural readiness and platforms designed for current demand rather than future growth.
They also exist in leadership conversations where technical investments are not translated into outcomes the wider organization understands.
The sequence matters.
Begin with the real business requirement, not the first solution proposed.
Develop data literacy across the organization, not only inside the data team.
Treat governance as shared responsibility rather than control.
Build foundations that can support where the organization is going.
Evaluate build versus buy using the full long-term cost.
Most importantly, connect every technical decision to the business outcome it is expected to produce.
The implication of Aritra’s argument is clear.
AI may process information with increasing speed and confidence while the organization itself remains uncertain about where the data originated, what it means and whether it should be trusted.
The defining question is therefore not whether an organization’s analytics or AI is sophisticated.
It is whether the people responsible for acting on its outputs can understand them, question them, trace problems to their source and trust them enough to make decisions for which they are accountable.
Until that foundation exists, greater technical capability will not automatically create greater business value.
That is the blind spot organizations must address before AI can deliver on its promise.
Aritra Acharya joined The Executive Outlook to discuss data literacy, governance, analytics adoption, scalable platforms and the leadership decisions behind trusted data organizations.
Have a leadership story, industry perspective, or transformation journey worth sharing? Get featured in The Executive Outlook and join the voices shaping the future of data, technology and AI. Connect with our editorial team to share your story.
Listen in for business strategies and interviews with business experts to help you build a business and a life that you love.
About Us
