Why Technically Excellent Data Teams Still Fail

By Goutham Budati

There is not much data in data roles, at least not where the value gets created. The work that ultimately creates value in an organization is decisions, and decisions require something that pipelines, schemas, and dashboards alone cannot provide. That something is Perspective: the interpretive layer between raw output and real action. Most data teams have no systematic way to develop it.

I have rebuilt data organizations three times in my career. Different industries, different stacks, different business models, and the pattern was the same every time. The team was technically capable. The data was accurate. The team had learned to serve the stakeholder: fulfill requests, close tickets, ship dashboards, and measure success by how much was produced. Nobody ever asked whether any of it was changing how the organization made decisions.

Technical excellence and organizational irrelevance are not mutually exclusive. I have watched well-engineered data systems get deprioritized, defunded, and reorganized out of existence. The work was good. The team had simply never made a habit of drawing a line from the work to a decision. They had optimized for the wrong output.

The Data-Perspective-Action framework is the operating model I developed to fix this. It has a name because naming a pattern is the first step toward making it deliberate. The framework has three layers most practitioners recognize immediately, because they work inside them every day. Most teams never leave the first one. The goal of this article is to change that.

Where the framework came from

Nearly seventeen years ago I made a deliberate move from software development toward analytics. I wanted to be closer to how decisions were made. I joined an ad agency as an analyst and quickly discovered that the team’s monthly reporting process took four weeks to produce something that was already outdated by the time it landed.

I automated the reporting workflow in about a day. My boss had left the week I started, so I reported directly to the CMO, and nobody had a plan for my time. I spent it on something nobody had asked for: forecasting.

The models were not sophisticated. But they gave the CMO a concrete view he had not had before of what would happen if the business shifted budget from one channel to another. Clients shifted channels and ran experiments they had not previously justified, because they could see the expected return before committing the dollars.

That sequence (data, then an opinionated interpretation, then a specific decision) has been the mental model I have carried through every organization since. The framework is an attempt to make that sequence deliberate.

Layer One: Data

Data is the foundation. Infrastructure, reliability, consistency, and how information flows to the people who need it. Pipelines, schemas, models, dashboards. This is where most of the day-to-day work of data engineers and analytics engineers lives, and it is where it should live. You cannot build perspective on data you cannot trust.

The failure mode is not that teams focus here. The failure mode is that they stop here. The scope of the work quietly collapses to: receive request, fulfill request, close ticket. The team’s calendar fills accordingly. The report goes out. The dashboard gets built. The ticket closes. And nothing downstream changes. The data was not wrong. Accurate data without framing hands the hardest interpretive work to the person least equipped to do it.

I once audited a team that had built 200 dashboards. When we sat with the business stakeholders and asked a single question, which of these do you actually open before making a decision, it came down to ten. The other 190 had full data pipelines behind them, careful schema design, tested refresh logic. They had never been used to decide anything. The technical bar had been cleared. The business bar had never been discussed. We killed the dashboards that did not matter, but that was only half of it. The root cause was that the data team and the stakeholders had no shared definition of what the work was for. Data availability does not lead to decisions.

This is the hidden cost of staying at the Data layer. You keep building, the backlog stays full, and the distance between your work and any actual decision grows wider. The team stays busy and becomes increasingly easy to deprioritize.

Layer Two: Perspective

Perspective is where data teams that inform become data teams that influence. And in 2026, it is the layer that AI cannot replace, which makes it the layer that matters most.

That claim aligns with a pattern Randy Bean, Thomas Davenport, and others have documented in Harvard Business Review and MIT Sloan Management Review for more than a decade. Bean’s annual AI & Data Leadership Executive Benchmark Survey has found, cycle after cycle, that the primary barrier to becoming data and AI-driven is culture and change management. In the 2026 edition, 93 percent of senior data and AI leaders named culture and change management as the key challenge to adoption, and only 7 percent pointed to technology, the most lopsided split in the survey’s fifteen annual editions.

That pattern has held for the survey’s entire run, and it tells us something important: organizations are spending heavily on infrastructure and talent, and the returns are being gated by a capability nobody has named clearly enough to build deliberately. Bean and Davenport’s research has framed the problem. The Data-Perspective-Action framework is an attempt to answer it.

With AI now capable of generating pipelines, running preliminary analysis, and producing dashboards from a prompt, the data team’s competitive advantage has shifted. The bottleneck is no longer building. It is trust. Guardrails like data quality, governance, and clear definitions of truth become more critical as output volume rises.

Mick Dreeling of Netflix, speaking on a panel I moderated at the Data Engineering Open Forum (DEOF) in 2026, described this as a shift toward “golden agents”: as stakeholders query agents directly, “the accountability is probably on the data engineering team” to guarantee the answer is right, and to keep raising that bar.

And domain knowledge remains the irreplaceable edge. AI can generate a dashboard, but it cannot tell you whether the metric you are tracking is the right one for the decision you are trying to make. That judgment lives in the Perspective layer. It is the one asset that appreciates with organizational experience rather than depreciating with technological change.

Shridhar Iyer of Meta made the same point on that DEOF panel: as agents absorb general knowledge, domain expertise is “clearly the IP that I don’t see going away.”

The practical implication is direct. The data professional who develops a systematic habit of Perspective work becomes more valuable as AI tools improve. The one who stays in the Data layer becomes easier to automate.

The objectivity trap

Data professionals are often trained into a form of objectivity that quietly becomes passivity. Offering an interpretation feels like overstepping, like claiming authority that belongs to someone else. So the analysis goes out without framing, and the stakeholder, who has fifteen minutes and five competing priorities, does the interpretive work however they can. The data team considers the deliverable complete. The stakeholder is doing the hardest part of the job without any help.

Data does not speak for itself. Someone always interprets it. The question is whether that interpretation happens in your hands, where you have the context and the craft to do it carefully, or in the hands of someone making a gut call with a dashboard they half-understand.

The feedback blind spot

There is a second reason perspective gets skipped, and it is structural. Engineers build systems that work. The data flows. The dashboard loads. The tests pass. What engineers almost never see is what happens after the handoff. The stakeholder exports the data to a CSV, opens Excel, adds their own columns and formulas, and recreates the analysis from scratch every time they need to make a decision. The system is technically healthy. It is practically bypassed.

The way through this is proactive engagement. Talk to five stakeholders about the decisions they are making and where they feel uncertain. You will find problems you could address in a day or two. Those quick wins build the kind of trust that eventually earns you a seat in the room where decisions are being made before they are made.

Building perspective as a habit

The mechanism I have found most useful is a weekly one-pager. One page. Three sections. What the data shows (one paragraph, factual). What it means for this business right now (one paragraph, opinionated). What it implies we should do next (one or two bullet points, specific). That last section is where most people stop, and where the most important work starts.

Write it. Share it with one person, a manager, a peer, or someone on the business side. Get one piece of feedback. That cycle, done consistently over three months, builds a fundamentally different intuition about what data actually matters to the people who make decisions. It also forces you to have an opinion, which is uncomfortable at first and essential in the long run.

Macros and micros

One concrete expression of perspective is what I call knowing your macros and micros. There are very few metrics that represent the heartbeat of the business, the numbers that answer the question every executive actually carries into every room: is the company healthy? And there is a small set of input metrics that explain movement in those macros when something shifts.

Monisha Kanoth of Apple, speaking on the same panel, described trust as resting on “really solid northstar metrics that the business as a whole agrees upon,” which is the macros-and-micros discipline by another name.

For a marketing leader who was receiving data from dozens of sources, we rebuilt her reporting around three macro indicators and five micro signals. Within a quarter, she went from not knowing which numbers to trust to walking into any boardroom conversation and articulating precisely what was driving growth, and what was not. The shift was deciding what actually mattered and protecting the integrity of those metrics above everything else. Once she had that clarity, she started asking better questions, and the data team started building better answers.

Design with, not for

Perspective also requires doing the design work alongside your stakeholders. I use a practice I call launching at version 0.8: bring something before it is polished, invite the stakeholder into the final 20 percent of the build. When they co-create the output, they feel ownership over it. Ownership is what converts a deliverable into a commitment to act.

I once had a stakeholder write down 100 questions that really mattered to them. Over the next few years, virtually no question they asked fell outside that list. It became a roadmap for what to build, and equally important, the single most effective scope-control tool I have used. When a new request came in that was not on the list, we had a shared artifact to point to. The conversation shifted from “why won’t you build this” to “is this more important than what we already agreed matters.”

The narrative is the deliverable

One of the most consistent failure modes I see is a data professional sharing a link to a SQL query, a spreadsheet, or a dashboard and considering the communication complete. A link is raw material with a note attached that says good luck. You have handed the hardest manufacturing step to the customer.

Writing a narrative, even a short one, immediately changes the level at which you operate. It forces you to commit to an interpretation. It forces you to decide what matters. It creates something that can receive feedback, be challenged, and be refined.

One note as generative AI becomes standard in the workflow: outsource the polish if you need to, but do not outsource the thinking. Writing is thinking. An AI tool can clean up your prose. It cannot develop your point of view. If you let it generate the narrative and ship it without engaging with the ideas, you have skipped the one layer of this framework that builds on itself over time. The perspective has to come from you. Everything else is formatting.

Layer Three: Action

Action is the hardest layer, and I want to be direct about that. I have had partial success here, more than I had before the framework, less than I want. The gap between a recommendation and an actual organizational decision is wide. Most data teams underestimate how much work that crossing requires. More importantly, they underestimate that crossing it is their job.

There is a large white space between your analysis and the room where the decision gets made. When Tobias Macey and I discussed this on the Data Engineering Podcast, it was the sharpest point of the conversation. The DEOF panel circled the same gap from the angle of trust and validation. The question was not whether data teams should develop this capability. Everyone agreed they should. The question was who owns accountability for the translation. My answer: the data team does. If you are not extending yourself into that white space, with clear recommendations, opportunity sizing, and sustained advocacy, the stakeholder will fill it with their own interpretation, their own incentives, and their own timeline.

Sometimes their interpretation is right. Sometimes it is not. Either way, the data team has yielded the most important part of the work.

The no-data-alone rule

The rule is simple: you cannot present data alone. Every analysis must include a recommended action. This single constraint changes how engineers and analysts scope their work from the very start. When you know you need to recommend something at the end, you scope differently from the beginning. You investigate with a specific question in mind. You instrument for decision-relevant metrics. You think about what a leader would need in order to move.

Early in my career, I violated this principle in the most instructive way. I had identified a significant growth opportunity, built a model to quantify it, and presented it to a leadership team. They nodded, thanked me, and did nothing. The analysis was not wrong. I had produced a finding without a recommendation, and without having built any shared context with the people who would need to act. I had moved from Data directly to what I thought was Action, skipping the Perspective layer entirely: the relationship work, the co-creation, the trust-building that makes a recommendation land rather than sit. The approach was wrong.

Opportunity sizing and advocacy

When hypotheses emerge from analysis, do not leave the sizing to your stakeholder. Have an opinionated view of what the opportunity is worth and why it should be prioritized. You may be wrong. But a number on the table gives the decision maker something to challenge, and a challenged estimate produces a decision far more reliably than a vague direction.

Repetition and the learning agenda

Just because you presented something once does not mean it will make it onto a roadmap. Getting an insight into the Action layer of an organization can be a patient journey over months. Maintain a learning agenda. Track which recommendations were acted on and which were not. Continue to advocate for the ones that still matter. Showing up again with updated numbers is what believing your own recommendation looks like. This is the work most data teams abandon after the first presentation does not land.

The org structure that supports this

The framework is an individual practice and an organizational one. The structure I have found most effective organizes data teams around a simple pairing model. At the embedded level, the ideal unit is a duo: one analytics engineer paired with one analyst, aligned to a specific business domain such as marketing, supply chain, or growth.

The analytics engineer maintains the robustness of the system. The analyst owns the narrative, the stakeholder relationship, and the action advocacy. Together, they cover the full framework. Neither can operate effectively without the other. An engineering partner without a storytelling counterpart builds for completeness rather than for decisions, and a storytelling partner without a reliable build counterpart has nothing credible to say.

For teams that are not starting from scratch, this does not require a reorg. Start with one pairing: one analytics engineer and one analyst assigned to one business domain for one quarter. Prove the model before expanding it. The structure follows the proof.

In earlier-stage companies where infrastructure work consumes most of the team’s capacity, the duo model is a luxury you may not yet have. Create protected time for perspective-sharing instead. A weekly business review, a monthly demo to a team outside your immediate stakeholders. The habit matters more than the org chart.

The rhythm that compounds

The version of data work this framework points toward is an operational rhythm: perspective produced and action advocated consistently, weekly, compounding over months and years.

When that rhythm is in place, something changes in how you build. You start questioning why certain pipelines exist. You see which alerts are noise. You understand which infrastructure investments the business will actually need in two years, because you are in the rooms where those decisions are being made.

The data team’s job is to build a shared reality: a common, reliable understanding of what is happening and what it means, so that the organization makes better decisions than it would otherwise. The Data-Perspective-Action framework is a way of keeping that purpose visible while doing the technical work. It is the reason the pipelines and schemas exist.

Decisions are the point. Everything else is how you get there.

Author bio

Goutham Budati has over 10 years of experience in building and leading the Analytics, Data Science and Data Engineering functions in various domains, such as advertising, e-commerce, saas and health tech.