The churn dashboard is beautiful. Clean SQL, gorgeous visualizations, a deployment pipeline that would make a DevOps engineer weep with joy. The stakeholders are thrilled. You celebrate, update your LinkedIn, and move to the next ticket.
And then nothing changes. Churn stays flat. Product doesn’t shift their roadmap. The business keeps bleeding customers.
This scenario plays out in data teams every single week, and it’s not because the dashboards are broken, it’s because data teams are solving the wrong problems. A recent discussion on data team priorities has been making the rounds, and the core complaint from practitioners is uncomfortably specific: we’ve built an entire industry of elaborate infrastructure that makes our teams feel productive while the business barely notices.
The most damning question came from a Reddit user who cut straight to the heart of it: “Is the business even asking the right questions to be answered using data?” The top reply, with brutal efficiency: “Give me profits?”
That’s the uncomfortable truth. And it starts with something called problem-swapping.
The Art of Substituting an Easy Problem for a Hard One
Attribute substitution is a well-documented cognitive bias, when faced with a hard question, our brains quietly replace it with an easier one and answer that instead. Data teams do this at an organizational scale.
You’re asked to reduce customer churn. That requires understanding the root causes, then convincing product, marketing, and possibly sales to change their behavior. Multiple teams need to alter how they work. So instead, you build a churn dashboard. It’s a clean deliverable that demonstrates competence, but as one commenter noted, “A churn dashboard can show where customers leave. Someone on the product side still has to decide what to change and check whether it helped.”
The dashboard is the easy problem. The behavior change is the hard one.
Data platform migrations are the more expensive version of the same trap. Nearly every company struggles with slow development cycles, unreliable pipelines, or poor data quality. Along comes a vendor promising Platform B will solve all of it. The company spends 12 months migrating. If they’re lucky, they finish. Then, months later, they realize the platform was one small piece of what was actually keeping them from using data effectively.
The real problems, the politics, the policies, the process issues, remain untouched. As SeattleDataGuy’s piece on data fundamentals points out, these questions are timeless precisely because nobody answers them.
What Question Is This Data Actually Supporting?
Here’s the question that should precede every pipeline, dashboard, or agent you build: what decision is this data supposed to inform?
In a world where producing proofs-of-concept is faster than ever, where individual employees can spend more than their monthly salary on Claude credits, it’s become easier to build impressive things that matter to no one. Vibe-coding a dozen ideas against the wall takes roughly the same time as building one solid POC, and both can arrive at the same outcome: nothing that changes the business.
The harder questions are:
- How will this solution actually be implemented?
- Does it require a technical fix, a process change, or both?
- Once implemented, how does it change behavior?
If you can’t answer those, your POC is destined for the digital shelf alongside all the other projects that felt important in the planning meeting.
The Source of Truth Problem Nobody Wants to Own
Ask any data engineer about source-of-truth debates and watch their eye twitch.
The canonical example is embarrassingly common. Salesforce says a customer is on a $120,000 annual contract. The customer renegotiated down to $100,000 months ago. Billing updated their system. Sales never touched Salesforce.
Ask Sales where the truth lives: Salesforce. Ask Finance: the billing system. Ask leadership and you’ll get a shrug, they just know the revenue number keeps not adding up. And somehow, both systems are “kind of right and wrong depending on which region you’re working with.”
The real problem isn’t data quality. It’s that the business process itself is broken, and no data model can fix that.
This is where the tension between centralized data governance and decentralized business needs gets genuinely uncomfortable. Centralized teams try to enforce standards, but the domains that own the data often resist because the standards don’t reflect their reality. The conflict between agile BI teams and slow governance processes isn’t a personality clash, it’s two groups optimizing for different outcomes with no one bridging the gap.
Bob’s Head Is Still Your Most Critical Data Source
Nearly 2027, and billions of dollars are still being directed by knowledge that exists in exactly one location: one person’s head, or at best, a spreadsheet they maintain.
You can spend days digging through systems, talking to people, and tracing lineage, only to discover the information you needed lived in a single workflow managed by one IC. The culture of isolated personal workflows, that Google Sheet that Karen updates every Friday, the Access database that Dave built in 2007 and never documented, is still the invisible architecture of most enterprises.
This is partly a data governance problem, but it’s more fundamentally a knowledge management problem. The growing skill gap and lack of on-the-job learning in data teams doesn’t help, when your senior data engineers are running on tribal knowledge, that knowledge becomes an unmanaged production dependency.
The fix isn’t more governance tools. It’s recognizing that this is an organizational design problem masquerading as a technical one.
Stop Modeling Data. Start Modeling Business Processes.
“Let’s pull in all the Salesforce data” is the most dangerous opening line in data engineering. It feels productive. You hook up the ELT tool, load the data, and get started.
The problem is that almost no business process lives in a single system. The CRM contains the opportunity, customer, sales rep, quoted amount, expected close date. The ERP contains the actual sales order, line items, quantities. The internally developed warehouse system tracks what was picked, packed, and shipped. Each holds a fragment of the story.
Query-driven data modeling, ingesting whatever’s available and hoping it joins nicely, produces siloed datasets that can’t capture the actual business flow. You end up with tables that can’t be joined because IDs don’t match, or that capture only part of the customer journey.
This is why the cultural divide between platform-centric roles and hands-on engineering work is so corrosive. Building the platform isn’t the goal. Understanding the business process and modeling it faithfully is the goal. The platform is just infrastructure.
You might also be surprised how many of these problems get easier when teams start treating data collaboration like code collaboration, versioning data and enabling diffing and review changes the conversation from “whose data is right” to “let’s look at what changed.”
The Question Nobody Asks: What Happens If We Don’t Build It?
The most powerful question in project intake is the one almost nobody asks: what actually happens if we don’t do this?
The answers get very revealing very quickly. Sometimes it’s “we lose millions.” That’s a project worth building.
Sometimes, more often than you’d think, the answer is “well, it would be nice to have.” Nice-to-have is great. But when there are dozens of other projects competing for the same team, “nice to have” needs to be weighed against everything else. And that requires some deeper reasoning.
The quiet reality is that what happens if you don’t build something is just as important as what you’ll gain if you do.
The Governance Trap and the Data Mesh Escape
The data mesh movement has been controversial since its inception, but its core insight remains relevant: treating data as a product rather than a byproduct shifts accountability to the domains that actually produce the information.
In a data mesh architecture, governance is not a centralized function dictating how every piece of data should be handled. Instead, it’s a collaborative process where domain representatives define common standards for interoperability, security, and privacy. Each domain owns its data products. The central team focuses on the platform and federation.
However, the path from centralized governance to a working mesh is strewn with failure. Enterprises attempting this transition often underestimate the change management burden. The self-service infrastructure platform required is a big technical lift, but the cultural shift is bigger. Teams that never had to think about data ownership suddenly own data products. That doesn’t work without substantial enablement.
The Real Problem Is the Reward System
Here’s the cynical-but-accurate take: data teams build the wrong things because their incentives reward it.
Building a pipeline is tractable. You can scope it, ship it, and get a sense of completion. Changing how product thinks about churn? That’s messy, political, and potentially takes months with uncertain success. You can’t put “changed product’s roadmap” in your OKRs cleanly.
Platform migrations are worse because they’re expensive, time-consuming, and completely miss the point. There’s real money in convincing you that your platform is the problem, and the budget realities facing modern data teams mean the sales pitch often lands right where the team is hurting.
What This Means for Your Data Team
The uncomfortable conclusion is that the problem isn’t technical, it’s systematic. Data teams that successfully avoid the problem-swapping trap need to rewire how they evaluate success:
- Build the business change, not the dashboard. Make the behavior change part of the deliverable. The dashboard is just instrumentation.
- Refuse to substitute easy problems. When asked for a solution, ask first what decision it supports.
- Find Bob. Before building any pipeline, map where the knowledge actually lives.
- Model processes, not systems. The CRM isn’t the business. The business is the end-to-end flow across every system, spreadsheet, and pair of hands.
- Ask what happens if you don’t build it. And be prepared for the answer to be “nothing at all.”
This isn’t about being more skeptical of stakeholders, it’s about being more honest about what constitutes progress.
The tools are converging fast. Lightweight, developer-friendly options like DuckDB 2.0 LTS are making it easier to iterate on data workflows quickly, and AI agents are changing how teams can automate their infrastructure. These are enabling conditions, not solutions.
The solution is asking better questions before writing a single line of SQL. Because the fastest way to solve the wrong problem is to start building before you understand what right looks like.
And if you’re the data leader in the room, remember the question that was asked in that Reddit thread: is the business even asking the right questions? Sometimes the most valuable thing your team can do is help them figure that out.
