top of page
Search

I Cost My Client 3 Days of Revenue Cycle Data (And Why They Trusted Me More Because of It)

  • Writer: Christian Steinert
    Christian Steinert
  • Nov 11
  • 4 min read

What happens when you admit your architectural mistakes instead of blaming the vendor


Three days.


That’s how long our healthcare client watched their revenue cycle reporting go stale while I scrambled to fix broken pipelines. And it was entirely my fault.


ree

Welcome back to Rooftop Insights! This week, I’m sharing a hard-earned lesson about transparency, accountability, and what it really means to be a trusted data consultant—especially when everything falls apart.


The Foundation of Trust

Want to know the secret to being a data leader and consultant companies will remember?


Tell the truth.


It may seem obvious, but let me explain.


A few weeks ago, I made a LinkedIn post about the difficult realities of consulting—unpaid invoices, getting fired from projects, all the experiences that feel awful in the moment but ultimately build you into a better consultant long term.


A mentor, friend and one of the top creators in the data leadership space,

Sebastian Hewing, left a comment that really resonated with me:

“Setting the right expectations, communicating often and clearly and then consistently doing what you said you’d do (even for little things) is SO important. I have worked for 50 clients over more than 10 years and I haven’t sent my invoice late a single time. Thanks for sharing this story!”

His point was clear: even for the micro details, always follow through, remain transparent, and communicate with your clients.


This couldn’t be more relevant to a scenario I just encountered with one of my healthcare clients.

When Everything Breaks: A Real Story

Never Blame the Vendor


Last week, our data pipelines broke. Almost every job. We changed nothing, but our low-code data integration tools returned a concurrency error.


The vendor had updated their backend and it broke our jobs. This caused a 3-day outage from discovery to fix—working closely with our vendor to diagnose and treat the root cause.


The impact? Daily revenue cycle financial reporting went stale. In healthcare, that means finance teams couldn’t track cash collections, identify billing issues, or monitor denials in real-time. Every day of stale data is money left on the table.


I’m not sitting here bashing this tool or ruminating in frustration. Honestly? Welcome to data engineering. Every data engineer has experienced broken pipelines at some point.


It’s about how you handle it that sets you apart.


Often, consultants blame factors other than themselves for these issues. They sit on their hands and refuse to own the problem, or at least approach it with a lack of urgency.


Here’s the thing: part of the reason we remain relevant as data engineers and consultants is because pipelines break. However, here’s the critical principle of solid data architecture that I violated:


I didn’t make a plan for failure.


Realistically, any good architect or consultant will default to a plan for failure before it ever happens. We were caught with our hands tied, and the worst thing you can do for your stakeholder’s peace of mind is blame the vendor.


Sure, it’s frustrating the tool deployed a breaking change. However, it’s equally frustrating that I never created a plan for failure. That’s the tradeoff of using low-code tools—you give up control and place it in your vendor’s hands.


We should have thought about stopgap solutions, but instead we bet the house on these pipelines staying at 100% uptime. Yikes.


The PoC Paradox

When you’re in a Proof of Concept phase, the heavy focus is on delivering tangible business value quickly. These low-code data pipelining tools specialize in doing just that, but it’s our job as data leaders and consultants to take responsibility if they break.


Side note: I’m not saying that high-code pipelining solutions like PySpark notebooks are foolproof either. However, they give you far more control to troubleshoot the code yourself if something breaks.


Instead, we were caught with our hands tied, awaiting updates from the vendor, watching our data go stale day by day. Stressful!

How to Communicate When Things Go Wrong

Pulling from the theme of this article: If you’re caught in a situation like this (hopefully not), DO NOT leave out any detail. Furthermore, don’t shift the blame.


Look inward to see where you can improve to better handle this situation if it happens again (it will).


When explaining why our pipelines broke, I kept it focused on where we missed the mark, how we’re resolving it, and what we need to do moving forward:


  • I leveraged newer, lesser-proven low-code tools to deliver with speed

  • I did not plan for failure, and not having a fallback solution ready blocked us


Admitting my mistakes and misses did not feel good. However, these are necessary learnings when leading data teams. Painful lessons, but the only way to maintain trust with your clients is to keep that transparency and honesty.

The Unexpected Outcome

Our clients appreciated the transparency and vulnerability. They recognized all the work we were doing to get to a resolution.


Instead of taking away trust, this actually built our relationship stronger as long-term partners.


The pipeline issues ended up resolving shortly after that conversation. We’re now implementing a fallback solution: a separate set of low-code pipeline jobs that run on full loads and populate a fallback schema of tables. If our production incremental schema breaks again, we can immediately switch to the fallback and keep data flowing while we troubleshoot.


It’s not perfect, and it adds complexity. But it’s a plan for failure—something we should have had from day one.

The Takeaway

Transparency isn’t just a nice-to-have in data consulting—it’s the foundation of every lasting client relationship. When things break (and they will), your response matters more than the failure itself.


Tell the truth. Own your mistakes. Plan for failure. Your clients will remember you for it.

Christian Steinert is the founder of Steinert Analytics, helping healthcare organizations turn data into actionable insights. Subscribe to Rooftop Insights for weekly perspectives on analytics and business intelligence in these industries.


Feel free to book a call with us here or reach out to Christian on LinkedIn. Thank you!


Also - check out our free Healthcare Analytics Playbook email course here.


 
 
 

Comments


bottom of page