During a recent conversation with The Executive Outlook, Adam Roderick highlighted a distinction many small and mid-sized businesses discover only after making an expensive mistake in their data journey.
Data simplification does not begin with technology. It does not begin with an enterprise data warehouse, a modern data stack, or a vendor selection process. It begins with the business questions an organization cannot answer today.
When companies reverse that sequence, teams spend months connecting systems, moving data, and building infrastructure without delivering a single answer the business can use. The budget is consumed, expectations fall, and the organization begins to question whether its data investment was worthwhile.
He spent years working with some of the world’s largest companies and institutional investors as they invested tens of millions of dollars in master data, reporting, analytics, and enterprise platforms. That experience led to the idea behind Datateer: could similar capabilities be made accessible to a $20-million-revenue business without requiring tens of millions of dollars in investment?
His answer was yes, but only if data was approached in a different order.
The traditional model asks a company to make a long list of technical decisions before it receives value. Which warehouse should it use? How should it ingest data? Which tools should it buy? How will those products integrate?
For a mid-sized organization without a mature data team, those questions create complexity before the business problem has even been defined.
The datateer approaches the problem differently. Instead of recommending separate technologies, the company packages commercial tools and open-source components into a cohesive platform. Most of the technical foundation is designed to work without requiring the client to become an expert in data architecture while leaving room for necessary customization.
The commercial model follows the same principle. Rather than asking leaders to understand consumption credits, infrastructure pricing, or cloud spending, Datateer prices work around understandable data assets.
A data asset might be an extraction from a source system, a reporting model, a dashboard, or an AI agent. Each has a clear cost, allowing a stakeholder to ask a simple question: does this asset create enough value to justify the investment?
That framing enables companies to start small, prove usefulness and expand only when the business case becomes clear.
He does not describe data maturity as a rigid series of levels. He sees it as a spectrum that most organizations travel in a similar way.
It often begins with one capable person. They download CSV files, manipulate information in spreadsheets and produce reports for a department or leadership team. The work is useful, so the organization begins to rely on it. Over time, that person becomes indispensable.
The value is real, but the process is fragile.
Different people may calculate the same metric in different ways. One report shows one number, while another shows something else. The person producing the reports becomes overwhelmed because every request requires another extraction, spreadsheet update and round of manual checking.
The next instinct is to centralize the data. The company introduces a warehouse and automates feeds from source systems. This is important, but it does not solve the entire problem.
Two analysts can access the same warehouse and still produce different answers if the organization has not agreed on how a metric should be calculated.
The real turning point comes when the business establishes canonical definitions. What counts as an active customer? What does revenue include? How should project progress be measured? Which definition applies across departments?
Once those decisions are reflected in the reporting model, centralized data becomes trusted data. From there, the organization can extend analytics across departments, provide information to customers and build AI systems on fresh, reliable, governed data.
The shift from spreadsheets to a warehouse matters. The shift from inconsistent definitions to shared business meaning matters more.
The most common failure begins with good intentions.
A company decides it needs to become more data-driven. The logical first move appears to be collecting everything. Data is extracted from every application and moved into a warehouse or lake. The assumption is that value will emerge once the information is in one place.
He argues that this is the wrong starting point.
A horizontal extraction project with no specific business outcome has no clear definition of success. The work expands, integrations become more complicated and the business waits for a result that remains somewhere in the future.
The better first step is a focused working session with the right stakeholders. The discussion should not begin with tools or even metrics. It should begin with questions.
Which customers may be at risk of churning? Which projects are moving outside acceptable thresholds? Which decisions are delayed because the data is unavailable or unreliable?
Questions are easier for business leaders to articulate than KPIs. A stakeholder may struggle to explain which metric should be built, but they can usually describe the decision they are unable to make.
Once the questions are visible, the team can priorities them and select one or two that matter most.
He calls this the slice approach.
The team begins with one business question. It defines the metric needed to answer it, agrees on the calculation, decides how the result should be presented and identifies the minimum data required.
From the bottom up, the team connects only the relevant systems, tables, or API endpoints. It does not extract every table or endpoint simply because they are available. The platform and tooling remain packaged and managed, while the custom work is limited to the slice the business has chosen.
This approach can produce a working answer in weeks rather than leaving the organization waiting through a broad infrastructure program with no immediate outcome.
The first slice also creates credibility. Executives can see that the investment has answered a real question. Analysts become familiar with the integration and quality patterns. The delivery process becomes repeatable, making each subsequent slice easier to define and justify.
A horizontal project says, “Let us gather everything and see what becomes possible.” The slice approach says, “Here is the question we need answered and here is the minimum capability required to answer it.”
One begins with infrastructure. The other begins with value.
He is equally clear about what organizations should not do when spreadsheets become difficult to manage.
They should not begin with the goal of eliminating them.
A wholesale replacement program asks people to abandon familiar workflows before the alternative has earned their trust. Even an imperfect spreadsheet process may still support important decisions. Replacing everything at once creates unnecessary resistance and a much larger change-management problem.
The more effective approach is incremental.
Choose one metric for one audience and centralize it. Leave the rest of the process untouched.
Once that metric proves reliable, analysts can point their spreadsheets to the warehouse instead of downloading and manipulating data manually.
This reduces extraction work without forcing people to give up the tools they know. Analysts gain more time for interpretation and problem-solving, while the business gains more consistent data.
The goal is not to remove the analyst or the spreadsheet. It is to remove the repetitive, error-prone work that prevents the analyst from doing more valuable work.
Some data problems cannot be solved through better engineering alone.
Adam’s clearest principle is that data is downstream from the business processes. If the process creating the data is undefined or inconsistently followed, analytics will reflect that inconsistency.
Consider a company with customer records in both a CRM and an ERP. If there is no reliable process for creating and maintaining those records, the organization may not be able to determine whether two entries represent the same customer.
The problem becomes harder when a private equity firm acquires several companies using different ERP systems and operating practices. Mapping those systems into a common reporting model is significant technical work, but technology is only part of the challenge.
A reliable unified view requires enough consistency in the upstream processes producing the data. Departments and acquired businesses need shared definitions for concepts such as customers, revenue, job progress and operational status. Without that alignment, consolidated reporting will continue to require manual reconciliation.
A data team may sometimes have to say that it cannot produce a trustworthy answer until a business process is clarified and followed more consistently.
Engineering around a broken process rarely creates simplification. It usually creates a more sophisticated way of managing confusion.
Departmental reporting is often manageable because one team controls the source system and understands its definitions.
The difficulty begins when a question crosses departmental boundaries.
How many customers are active across multiple systems? Are customer records in the CRM and ERP referring to the same organization? Which projects are financially healthy and operationally on schedule?
These questions require multiple systems and shared definitions. “Active customer” may mean one thing in a CRM and another in an ERP. Customer identifiers may not match. Ownership of the cross-functional definition may be unclear.
At this point, the challenge becomes one of governance and alignment. The organization must agree on a common definition and reflect it in the data model. Departments may need to accept that the enterprise definition differs from the number they previously reported.
Once that agreement is established, the benefits compound. Each department that adopts the shared model makes reporting more reliable and the data platform more useful. The business can move beyond describing what happened and begin understanding why it happened and where action is needed.
The most forward-looking part of Adam’s approach is the unified data model.
In vertical industries such as construction, companies often use a limited number of ERP and project-management platforms. Their systems differ, but many of their business questions are similar.
Which projects are performing above expectations? Which are falling behind? Which costs are outside acceptable thresholds? Where should a leader focus attention this week?
Datateer maps information from different source systems into a common industry model. Once that mapping exists, dashboards, reporting logic and AI analyst agents can be reused because they are built against the unified structure rather than every client’s raw ERP design.
This changes analytics from a custom project into a repeatable product.
For industries where Datateer already has prebuilt models and analytics, some initial reporting can be delivered within 24 hours. Fresh data can then arrive daily or hourly. Where a company needs custom logic, additional systems, or unique reporting, the work may take several weeks.
The important shift is not speed alone. It is the reduction in repeated engineering.
A construction company does not need to finance an entirely new analytics foundation simply because it uses a different ERP. Once its data is mapped to the common model, it can access reporting and AI capabilities that already understand the structure and meaning of the information.
For mid-sized companies, capabilities that once required lengthy projects and large teams become accessible through a managed and reusable platform.
He also acknowledges where data projects go wrong on the delivery side.
Failures are often caused by expectations. A team may be overly confident about connecting to an unfamiliar system, assume a vendor will provide access, or underestimate the complexity or volume of the data.
The solution is not a larger commitment. It is an earlier test.
When Datateer encounters an unfamiliar system, the team uses proofs of concept to confirm that the data can be accessed and handled before moving into a full implementation. This creates evidence before timelines and outcomes are promised.
Structured workshops play a similar role on the business side. Instead of holding broad conversations and hoping all necessary requirements emerge, the team uses repeatable working sessions designed for the specific type of data asset being built.
These practices expose risk early, clarify what the business needs, and reduce the gap between expectations and realistic delivery.
Across Adam Roderick’s perspective, one principle connects every part of the discussion: data simplification depends on sequence.
Technology should not be chosen before the business question is clear. All available data should not be extracted before value has been defined. Spreadsheets should not be replaced before the new process has earned trust. Cross-departmental reporting should not be expected before shared definitions exist. Integration should not substitute for process discipline. New system connections should not be promised before a proof of concept establishes what is possible.
The practical sequence is straightforward.
Start with the questions the business cannot answer. Priorities: one. Define the metric and the shared meaning behind it. Build only the data slice required. Prove that it creates value. Then use the credibility, patterns and definitions from that first result to build the next one.
The organizations that follow this approach can begin creating useful capability within weeks and mature it over time. Those that begin with every system, every table and every possible future requirement often spend far longer waiting for the first answer.
Data simplification is not about making the ambition smaller. It is about making the path to value clearer.
Adam Roderick joined The Executive Outlook to share his perspective on business-first data strategy, focused delivery and unified data models. Has a perspective shaping the future of data, AI, or enterprise technology? Apply to be featured on The Executive Outlook.
Listen in for business strategies and interviews with business experts to help you build a business and a life that you love.
About Us
