Your team has gone full ostrich. Heads buried deep in the sand, convinced that if they can’t see the production data errors, those errors must not exist. The pipeline is deployed. The tests passed. Job done, right?
Meanwhile, you’re the one fielding angry Slack messages from business users who found garbage in their reports, and you’re starting to feel like the only person who actually cares about what happens after code hits production. The frustrating part? Your team isn’t lazy or incompetent—they’re just overwhelmed with development work and genuinely don’t realize how bad things have gotten downstream. The ostrich approach feels safe when you’re already buried in sprint work.
You can coax those heads out of the sand without turning it into a big confrontation or piling on more work. It starts with making the invisible impossible to ignore. The “deploy and forget” ostrich mindset is one of the most common—and most corrosive—patterns in data engineering teams. The good news? It’s fixable, and it doesn’t require a massive cultural overhaul or months of extra work. It starts with making the invisible visible.
Your team sees their job as done once the pipeline code is out in production, with all the unit and manual testing. They don’t really feel responsible for any data quality problems that pop up after deployment—you know, in the staged data, dimension marts, or wherever else it’s used. Finding that bad data, which can show up every hour or day, is just “not their job” in their eyes.
Your customers are getting hit with data errors, but the team either doesn’t realize how big a deal it is or doesn’t seem to care. They basically check out as soon as their deployment hits production. Since they’re already swamped with development work, they’re really pushing back against taking on any extra tasks. Customers are calling with questions and concerns about the data, which is also taking up team time. Adding data quality tests into the data production process – no one has the time or interest.
So what can you do to start a wave of change?
You’re not going to win this argument with opinions or gut feelings. Your team will push back, insist everything is fine, and point to their passing unit tests as proof. The only way to get those ostrich heads above ground is with cold, hard evidence they can’t ignore.
Step one: Gather the facts that prove there’s a problem
Start by talking to the people who actually use the data every day. Send a quick survey to your end customers—nothing fancy, just a few pointed questions. Do they trust the data? Have they built their own shadow QA processes because they don’t trust the data? (Spoiler: they probably have, and they’re not happy about it.) Next, do some archaeology on your own side. Count the data errors from the past month. Dig through tickets, bug reports, and Slack threads. Ask your team directly—you might be surprised what they remember once you start asking.
Then go a step further and actually score your data quality. Using an open-source tool like TestGen, you can profile your data, get instant data hygiene test results, and have a data quality dashboard up and running in less than an hour—no massive implementation project, no endless configuration—just real numbers showing the current state of things.
Once you’ve got all of this—the survey results, the error history, the quality scores, the hygiene test results—share it with your team. Lay it all out. I’m willing to bet they’ll be genuinely surprised. Most engineers don’t want to ship bad data; they just don’t have visibility into what’s happening after deployment. This is your chance to turn on the lights.
Step two: Show them that adding data quality tests isn’t the time sink they think it is
Here’s where the resistance usually kicks in. Your team is already slammed with feature work, and the last thing they want is another “initiative” eating into their sprints. Fair enough. So don’t make it a big, massive initiative—make it a small experiment.
Pick a handful of tables that have been causing the most pain. Add some data quality tests and let them run for a few weeks. Watch what they catch. Then start a quality circle—a short meeting every two weeks where you review production errors together. Look at what the tests found, what customers reported, and ask a simple question: Can we create a permanent fix so this doesn’t keep happening?
Here’s the secret weapon: tools like TestGen automatically generate several dozen data quality tests with the push of a button. That’s not an exaggeration. TestGen handles the 80% test coverage your team needs without anyone writing custom code. The remaining 20%—the tests that are unique to your business logic—can be built using simple templates right in the TestGen UI, often with input from your business partners who know the data best. The “we don’t have time” excuse evaporates pretty quickly when you can generate meaningful test coverage in minutes instead of weeks.
Step three: Show them that production data quality testing isn’t a burden—it’s a gift
This is where the mindset shift happens. A 2022 survey by Wakefield Research found that data engineers spend 40% of their time—two full days per week—firefighting data quality issues. That’s not a typo. Nearly half their workweek goes to chasing down bad data instead of building new things. Worse, 74% of data quality issues are first surfaced by stakeholders, meaning most teams are stuck in reactive mode, responding to complaints rather than catching problems before anyone notices.
The math is simple: teams that catch data errors proactively in production spend less time in firefighting mode. IDC research found that improving data quality reduced time spent on defects by 53%. That’s when your team gets back to the work they actually want to do.
And the business case extends beyond engineering productivity. Gartner research shows that poor data quality costs organizations an average of $12.9 million per year—and much of that cost comes from eroded customer trust. According to Accenture, only one-third of executives trust their data enough to derive value from it. When your stakeholders can’t trust the numbers, they stop using them.
The flip side? Organizations that invest in data quality see real results. McKinsey research shows companies with mature data governance programs report 15-20% higher operational efficiency. One e-commerce retailer that implemented a data quality initiative saw a 20% reduction in customer churn and a 300% ROI within the first year.
That’s the real pitch: caring about production data quality doesn’t add to your team’s workload. It’s the thing that finally gets them off the treadmill.
Conclusion
Getting your team to pull their heads out of the sand isn’t about shame or blame—it’s about showing them there’s a better way. When they can spot data problems before customers do, when the same issues stop breaking things week after week, and when those dreaded stakeholder calls turn into the occasional “hey, nice work”—suddenly, caring about production quality doesn’t feel like a burden anymore. It feels like the thing that makes their jobs less stressful.
Start small, gather the evidence, and let the results do the convincing. Your team didn’t get into data engineering to disappoint people. They just need a reason to look up.
FAQ
What are the key points in this blog?
Deploy-and-forget is a visibility problem, not laziness. Teams ignore production data errors because nothing tells them the errors exist. Testing in production changes that, and the payoff is measurable: less time absorbing customer complaints, more time on development, and higher stated trust from the people consuming the data. Moving from reactive to proactive starts by making the problem undeniable.
What is the ostrich problem in data teams?
It is the assumption that a data team’s job ends when the pipeline deploys. Code ships, the DAG turns green, and nobody watches what the data does afterward. The errors are still there; the team simply has no instrument pointed at them, so the first notification comes from a business user weeks later.
Why do data teams stop paying attention after deployment?
Because nothing makes the failures visible to them. A pipeline that completes successfully while producing wrong numbers looks identical to a healthy one from the engineer’s side. This is a tooling and instrumentation gap rather than a motivation gap, which matters because the fix is different: you cannot exhort a team into seeing something they have no way to see.
What is the business case for testing data in production?
Teams that test in production spend less time fielding customer requests about suspect numbers, which returns hours to development work. Gartner research has also linked production data quality practices to increased customer trust and satisfaction. The argument that lands with a budget holder is the reclaimed engineering time, since that number is visible on any sprint board.
How do you shift a team from reactive to proactive data quality?
Make the problem undeniable before proposing a solution. Survey the people consuming your data about whether they trust it. Count the incidents your team handled last quarter and how many were found by someone outside the team. Evidence beats advocacy, because the usual objection is not that quality is unimportant but that nobody believes it is currently broken.
How do you start finding production data errors today?
Install open-source DataOps TestGen, point it at one schema, and let it profile and generate a baseline test set. You are not trying to achieve coverage on day one; you are trying to produce the first evidence that errors exist in tables everyone assumed were fine. That evidence is what funds the rest of the work.
