What Actually Counts as a Pain

One thing to clarify - what is a pain? I’ve had lots of confusion around this question the past 3 years. An annoying task felt by an executive like manual reporting in Excel appears to be a pain because they talk about it. In my experience, a task like this isn’t a true pain (even though I’ve mistaken it for one). Sure, saving an exec 75 hours per year by automating a report is great, but it isn’t a deep enough problem. It’s an annoyance more than anything. It takes time away from their strategic work, but at the end of the day it’s not derailing their growth.

A pain is something significantly impacting revenue, driving material cost at scale, or exposing the organization to regulatory risk. In healthcare that last one carries as much weight as the first two. Unmanaged HIPAA exposure is a pain before and after there’s a violation.

Where the Real Pains Live

A pain is either causing issues with an organization’s current processes and/or blocking a specific function from happening entirely. Take revenue operations for example - if you can’t accurately tie back the source of your customers, how will you confidently allocate lead gen/marketing dollars? Since subscription-based healthtech companies lean on Meta Ads often, if the website tagging and flow is broken, attribution and the origin of leads becomes impossible to track.

Furthermore, if you don’t have a structured process or tool in place to generate claims to payors, your denials may be increasing. There is obviously more to it on denial rates, but solving for pieces like this giant puzzle gives data expertise a seat at the strategic table. If a healthcare company is struggling to get paid, the pain felt because of that process gap impacts the entire company.

Use This as a Filter

As either a healthcare data team or data consultancy, don’t confuse annoyances with true pains. An executive complaining about a manual report or an IT leader wanting to migrate the data from on prem into the cloud appear as pain at first glance. Dig further. Always ask where a particular problem is directly impacting revenue, cost at scale, or regulatory exposure - that’s how you build solutions carrying deep impact and weight within an organization. Otherwise you’re just building data solutions that maybe one or two people care about, but makes you look like “data theater” to investors and leadership that are actually trying to build and sustain company growth.

Thanks for reading Rooftop Insights! Subscribe for free to receive new posts and support my work.

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 eBook course here.

I’ve been having plenty of conversations on this and experiencing a lot of interesting shifts in the market for the future of data teams in organizations.

Here’s how I’d define data teams in each environment based on my experience:

In the enterprise, it’s an IT function that owns the implementation of data integration, consolidation of sources and reporting.

In a mid-sized company, more of the same. It’s largely an IT function. Reporting, reporting, reporting. As Sebastian Hewing refers to it - a Dashboard Factory.

A start-up is where data teams create the most value. You’re working under either the Finance or Product department. The organization views you as more of a strategic enabler than just an IT-focused report creator and owner.

Based on my experiences, I’m laying out observations for where data teams stand in the Age of AI. Do they have a place inside a company or not?

The $75M Question Nobody Wants to Answer

On the surface, the need for a Data Team is a no-brainer to technical avatars of mid-sized to large organizations. Data is being generated from all angles, multiple source systems (EHR, CRM, Accounting/Budgeting), siloed Excel spreadsheets and various workflow automations (lead capturing into a CRM for example).

However, in the enterprise and mid-sized businesses, there is not enough strategic thinking. The data team ends up pulling in all of this data and plopping it into a data lake/lakehouse. As we’ve called it for many years now, it turns into a data swamp.

Data and analytics engineers build what they’re told to. KPIs without business definition, data models that have no applicability to a stakeholder’s actual pain, and a whole lot of guessing and hasty assumptions to boot.

In both my FTE and consulting life, this breakdown happens at the bridge between the business and the data team. You typically have a product manager interviewing the business for requirements. Somewhere along the way, the translation for value gets lost.

Either an inexperienced product manager who struggles to ask the right questions to identify a problem worth solving. A business analyst that sucks at writing acceptance criteria. Or engineers that only care about tools and build without understanding their business’s value chain.

Beyond strategic misalignment, I think a hard truth is that data teams just move too slow for business in the Age of AI (they’ve moved too slow for business even before the AI boom). I understand the push to build things “the right way”. I understand the need for best practices in data modeling, data visualization design and database optimization. However, is something truly “right” if it delays time to value and eliminates the chance for buy-in from the business? I talk more about this in one of my articles that Bill Inmon called “a masterpiece”.

Due to all these factors, I had a conversation with a founder of a 400 person, $75M revenue mid-sized scale up at a healthcare conference a few weeks ago. We were at a bar at 11:30 PM (funny enough, neither of us were drinking alcohol). After chatting about how he led his engineering team to beef up their AI skills, I asked him about his data team point blank - do you get value from them? His answer was “not really”. He then went into how complex his organization’s processes are. The failure to account for the tribal knowledge of workflows and how data is generated internally is the root cause of his discontent. I’d have to imagine the lack of business translation by the data team and slow time to value adds to this friction he feels (Big surprise! Haha).

Where Data Teams Earn Their Keep (And Where They’re Dead Weight)

On the flip side of the value gap, I’ve seen and learned about data teams that work well in the Enterprise for two main reasons.

Leadership at the top prioritizes data heavily

If you don’t have buy-in from the top down, just forget it. You’re always going to be fighting for requirements, time and resources to build things that actually help a business grow revenue, increase profit and enhance a product/service.

Governance and Master Data Management

If leadership prioritizes it, data governance can be extremely effective for defining KPIs and detail fields. Every definition and change runs through the data team, flowing through an approval process to ensure the data reporting source is always updated and representing the agreed upon definitions. This is extremely rare and hard to find a culture like this.

In the start-up world, I don’t think a data team is entirely necessary. Many startups scale on Google Sheets and a CRM. It’s not enough digital source systems to justify the overhead a data team carries and builds.

Many of the issues faced in these startups/smaller companies can be solved with a heavy focus on Revenue Operations and other core business processes. So many of them do not have their sales process defined (in my experience). Setting up their CRM and getting data generated correctly is the first step. A data infrastructure/team is far too out of scope at this maturity.

Any solutions you build at this stage can most likely exist in a Google Sheet or Excel. You DO NOT need a full blown data infrastructure with governance yet.

I think data professionals need to put more energy into functions like RevOps. I’ve been chatting extensively about this with Ergest Xheblati. So extensive, that it’s re-shaping the offer at Steinert Analytics. It’s one of the cleanest ways to establish value as a data professional while satisfying their need for quick turnarounds. Build that trust, and you’ve got a seat at the table.

If a start-up is extremely data centric (telehealth, for example), the data team could technically be part of the product or finance team. This was, in fact, the structure at the first healthcare company I ever worked for as a lead data analyst.

Their goal is to build data assets that help with product-level automations. It’s about using business logic and criteria defined in data models to produce outputs that trigger an action for revenue or a better customer experience. (ie. automating billing codes for healthcare claims or sending patient documents to the correct providers, totally automated).

I don’t believe it takes the overhead of a data team to build these things. Either roll one or two data platform engineers into your engineering team, or hire a highly specialized consultant/boutique consultancy to own these data platform builds and the reporting layer. You’ll stay leaner, move faster and operate with more precision to the business needs because of their out of the box expertise and ability to ask the right questions to the business directly, without all the noise of a team structure and hierarchy dynamics created with a data team.

The Verdict: Leaner, Faster, or Gone

So all in all, where do I think data teams are headed?

Let’s start with the biggest shift: viewing data development as an engineering function needs to die. Having middlemen between the business and engineering is over. The best data professionals are both technical and great communicators. Leveraging AI helps with the communication side as well - prepping you on questions to ask and becoming more familiar with a business’s value chain quickly.

From there, the verdict by company size is simple.

Enterprise and mid-sized companies? Data teams stay relevant. Governance and master data management aren’t going away - not with the vast amount of source systems these organizations operate with.

Startups? Revenue ops workflows paired with quick and dirty data solutions. That’s it.

Data-centric startups (like a telehealth SaaS)? Data automations tied to value producing workflows - owned by a couple versatile engineers on your platform team or a highly specialized consultant.

Leaner. Faster. Without all the team structure fat.

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 eBook course here.

The stakes of a data breach are incredibly high, and HIPAA laws aren’t something you can overlook due to speed of delivery.

Ensuring your setup is indeed compliant, and the infrastructure you’re implementing at your clients comes with audit logging, AES-256 encryption, etc. is a steep learning curve. Luckily, cloud solutions such as Microsoft Fabric cover much of the HIPAA compliance a Business Associate is responsible for. For items such as audit logging, there are a few solutions you can buy or build fairly easily.

From Dreading It to Embracing It

When I first began building data systems in healthcare, I dreaded the added work to remain HIPAA compliant. Coming from various other industries like fast food, it wasn’t nearly as complex. The deeper I’ve gotten into healthcare, the more I’m embracing compliance as an advantage.

The knowledge gaps amongst healthcare companies and practitioners is real, and I feel it daily working in the space. I’m not saying I have it all figured out. We’re a boutique consultancy that is learning daily, but taking HIPAA compliance seriously. Holding a compliance-first mindset already separates you from the pack. First internalize the foundational HIPAA compliance frameworks, then ask the technical questions about security.

What South Africa Taught Me About Compliance

One of the most productive actions we’ve taken in the last month is travel to South Africa. You might be thinking — what the heck does South Africa have to do with United States HIPAA data compliance laws?

It just so happens that the firm I visited in South Africa is on the cutting edge of healthcare data compliance. They follow POPIA (South Africa’s equivalent of HIPAA for personal data protection), and they’re leveraging AI to build compliant data solutions in ways that genuinely impressed me. It served as an inspiring reminder that these capabilities are at the tips of our fingers in the Age of AI. Compliance innovation is a global movement, not just a US problem.

The Opportunity Is Massive

The market for building compliant data solutions is massive. High demand, low supply. There are very few subject matter experts when it comes to compliance globally. We need to embrace healthcare data compliance as a massive opportunity, not a constraint towards innovation. The innovation comes from differentiated compliance knowledge and implementation of infrastructure.

That’s our industry. If you’re working in healthcare and are annoyed by the guardrails (used to be me), then maybe you need to rethink your purpose here. As healthcare data consultants, it’s time to own compliance innovation!

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 eBook course here.

This is what you walk into for a healthcare data migration—and how to handle it without burning out yourself, your team, or your client relationship.

We’re getting technical for this issue of Rooftop Insights. My goal is to paint the picture crystal clear for what you’ll walk into for a data migration at a majority of healthcare/healthtech companies and how to handle it smoothly.

A tale as old as time: when it comes to platform work vs. data infrastructure, prioritization of the platform is always on top. HealthTech companies know data is extremely important, often being the true lifeblood of their business. However, the platform (in my case telehealth) is what the customer actually sees and interacts with.

Therefore, it’s chosen over everything else as priority. When I say “chosen,” I’m specifically referring to resource investment. You might have 2-4 senior software engineers working on the platform, and 0-1 data people curating reports and analysis of the data.

I’ve seen environments where a sole analyst built out over 15 Power BI dashboards with multiple pages equivalent to 10,000 lines of code directly querying the production OLTP database. We’re talking around 30-35 semantic models that are really just massive SQL queries sitting in Power Query.

Timezone nuances, grain differences, CASE groupings, and specific filters for each report force these queries to reuse many of the same tables—but reading the code becomes critical to spot the differences and their intent.

Layer on the high-pressure timeline deadlines for a project like this when working with a high-growth (and sometimes seed-funded) HealthTech scale-up, and you’ve got A LOT on your hands to ensure this migration goes smoothly.

Now I’ll begin walking you through how we at Steinert Analytics handle projects like this to ensure they go smoothly. This is pulled directly from my own success navigating projects like this. I don’t want to give the impression that I’ve never hit a bump in the road.

I have—and more likely than not, you will too at some point. But it’s my best play for giving you something valuable to walk away with and take action on today in your own data migration projects.

Win as a Consultant by Setting Expectations

The first piece of success is to manage expectations with stakeholders and your team. Stakeholders want things FAST. And as your customer, it’s your duty to strive hard to deliver fast. But that doesn’t mean sacrificing quality and overpromising.

In the Statement of Work (SOW), I’ll map the deliverables to their expected timeline, but I’ll clause that we will deliver as many migrated dashboards as possible in the allotted time (ie. 20 hours per week, etc). I always allow for buffer/breathing room in how I write the SOW for a project like this.

It’s impossible to know at the start of a project what snags or gotchas you might hit. Especially when logic is extremely nuanced in the arcane legacy SQL written by an analyst/engineer years ago with depths of business knowledge you’re just getting up to speed on.

Furthermore, build out a Gantt Chart and use Trello for your Kanban board internally. Assign your team individual tasks on the Gantt Chart that can be mapped onto the Trello board. Each weekly sprint, new tickets are added.

This gives your team operating structure and flat visibility into what everyone is responsible for. A key to successful data migrations.

The Development Process That Actually Works

Step 1: Inventory Check All Tables for Each Dashboard Migrated

Do you have all the source tables pulled into your data platform (in my case Microsoft Fabric)? If not, the first thing to do is load those tables and build any required DDL and stored procedures.

If you have the metadata from the database’s information schema, leveraging Claude to create the DDL and Stored Procedure scripts is super convenient.

Step 2: Validate the Legacy Query in Your Data Platform

Rebuild the legacy query you’re migrating away from in your data platform. Don’t jump right into building the data model just because you’ve checked the table counts and done some quick data quality checks on the pipeline.

The reality is, timezone offsets, case sensitivity, and other data types can cause slight differences from source. The best baseline is to get the legacy query matching in the new environment—this also forces you to become intimately familiar with the logic.

Real example: I was recently migrating a patient report on a telehealth engagement. Table counts matched. Quick spot-checks looked fine. But when I lined the new query up against the legacy numbers, episodes were landing on the wrong week.

The culprit? The legacy SQL was implicitly converting UTC timestamps to the client’s local timezone before applying the week boundary. The new environment wasn’t. A handful of episodes near the Sunday-Monday cutoff were flipping into the wrong reporting week and throwing off the totals.

The fix was straightforward once I found it—AT TIME ZONE with an org-to-client or person-to-client timezone join. But here’s the point: if I had skipped this validation step and gone straight into building FACT and DIMENSION tables, that timezone drift would have been baked into the entire star schema. Every dashboard built on top of it would have been wrong.

Validating the legacy query first is the most critical foundation to build in a healthcare data migration.

Step 3: Build the STAR Schema(s)

After the source legacy query is validated, NOW is when you can build the formal FACTS and DIMENSIONS for a STAR schema. This is the meat of data modeling.

Also—I know what you’re going to say. Data modeling isn’t a one size fits all approach. Why not One Big Table? Maybe that makes sense in some cases, but let me tell you that the Kimball dimension model is tried, true, and fits the use case when you’re reporting telehealth data in a BI tool.

Leverage Claude to help you make a definite consideration, but I’ve found it always points me back to a dimensional model when we’re working with Power BI.

I literally prompt Claude to “Think like a combination of Ralph Kimball, Bill Inmon, and Joe Reis for constructing this data model” before I get into it. It’s been mind blowing at helping me make grain considerations and FACT table creations for my clients.

Don’t rely entirely on it. A successful data modeling experience using AI depends as much on you, the data practitioner. Turns out that years of experience are the key to making a robust data model, allowing me to challenge Claude when it suggests creating a dimension table that actually represents a fact. I give that feedback to Claude and it continues to be a great thinking partner during this critical exercise.

Step 4: Reproduce the Validated Legacy Numbers Using Your New FACT and DIMENSION Tables

If you took the proper care to model grain and logic, your “GOLD” (if using a medallion architecture) layer tables should produce the same results as the legacy query—except with far fewer lines of code and joins.

Once numbers tie out, congrats! You can take this query and build in the BI tool of your client’s choice. For us, it’s Power BI.

I then assign a ticket to my Power BI Engineer and he builds that Gold query in Power BI and validates the visualization against the legacy dashboard.

There’s always a consideration here as to how much logic you want built in the backend Gold query itself vs. Power BI DAX and the semantic model. Often times, our clients prefer the logic be baked directly into the data warehouse tables since healthcare data is used in far more places than just Power BI.

Healthcare data demands versatility, so if key logic is dependent on the BI tool, it restricts where else we can use this data. Food for thought as you consider these options and patterns with your clients.

The Non-Negotiable: Constant Communication

Perhaps the biggest key to success is constant communication. We typically have weekly updates to cover progress made and where we’re at against the timeline set. If I see deliverables slipping, I make that known right away.

Ping your stakeholders more than once a week in my opinion. A progress update every few days establishes continued trust and allows for pivots and iterations sooner.

For example, at one of my telehealth clients we uncovered the need to have all major logic in the FACT and DIMENSION tables themselves, rather than in Power BI DAX. This could only have been uncovered in our routine weekly update meeting, making these points known in collaborative conversations with the CTO. Otherwise, we would’ve spent a whole lot more time modeling the custom logic in DAX rather than the data warehouse SQL itself.

The Bottom Line

There you have it. My direct experiences migrating healthcare and healthtech companies to a cloud-native OLAP data platform with robust data models and management in place. I make this sound so streamlined. Trust me, it isn’t. And it’s taken me years to move at the pace we go now.

However, if you can take away managing expectations and constantly communicating with your stakeholders throughout, the key to successful migrations always comes back to the relationship you have with your clients.

Just stay transparent, stay consistent, and ALWAYS FOLLOW THROUGH—and the data migration will fall into place.

I hope this piece relieves a little stress for you. I know writing it served as a good reminder for even myself.

Until next time, see you in the next issue of Rooftop Insights. Thank you!

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 eBook here.

This issue is raw and transparent. No polished case study. Just my honest thinking on paper about an identity shift I’m actively navigating — and one I suspect many of you are too.

Almost a decade in data. Business intelligence, analytics, reporting, data transformation. That’s all I’ve ever known.

And for most of that time, the offer was clear: help companies model, govern and manage their data so they can make better decisions, move faster and grow with confidence.

That offer still exists. But the market is forcing a reckoning.

The Two Clients I’m Serving — And Why They’re Completely Different

Not every company is ready for data warehousing. I’ve written about this many times. But let me lay it out plainly here.

Option 1 — The Data Transformation Client

Mid-sized to enterprise organizations. Scale-ups where data is at the core of their product. Multiple source systems. Real complexity. Departments that don’t agree on what “net revenue” means. Leadership that understands — at least intellectually — why metrics clarity and data governance matter.

These clients need a data warehouse. They need dimensional modeling. They need a single source of truth that powers consistent, trustworthy decisions at every level of the organization.

Gartner says 60% of AI projects unsupported by AI-ready data will be abandoned. That stat is a gift for anyone selling Option 1. It’s the clearest argument I have for why data transformation isn’t optional — it’s the foundation everything else is built on.

Option 2 — The Quick Win Client

Smaller companies. Roofing firms. E-commerce businesses. Companies running on spreadsheets and brute force manual processes with tribal knowledge baked into every formula. I’ve seen it firsthand more times than I can count — businesses doing multiple millions in revenue held together by Excel workbooks that nobody fully understands.

These companies don’t need a data warehouse. They need automation. They need one report that answers the one question closest to their value chain. They need ROI — now.

And here’s the hard truth: selling them Option 1 doesn’t work. I’ve tried. It doesn’t resonate. They don’t have IT leadership. They don’t have a long-term data vision. They just want ROI NOW.

Where AI Is Forcing the Identity Shift

This is where it gets uncomfortable.

Option 2 clients don’t just want automation anymore. In the Age of AI, they expect you to bring an AI workflow into it. They expect you to do something that feels like magic — stitch together their data, drop an intelligent layer on top of it, and produce insight they’ve never had before.

And honestly? I don’t disagree with that expectation. We have the tools and capabilities to do very incredible things.

The problem is my identity.

I’ve spent nearly a decade positioning myself as a data consultant. A data transformation expert. Someone who builds data warehouses, governs metrics and architects platforms.

Ergest Xheblati — one of the most tenured data architects I know and a mentor I lean on heavily — called me out on this directly in a recent coaching session. My issue isn’t technical capability. It’s that I’m still building the confidence to be a business solutions consultant as much as I am a data consultant.

That hit hard. Because he’s right.

Joe Reis’s Substack article from last week Saturday also ignited a fire under me with this shift. I talk about in the below LinkedIn post.

In the Age of AI, data professionals/consultants are really transitioning to business solutions architects/consultants.

Data is merely just the vehicle in which we deliver impact, but it’s far from the whole show.

We’ve always known this intellectually. Data does not sell. The ROI actions we take on behalf of the data is what sells.

Now it’s time to actually get in the mindset to sell business solutions. Not a data warehouse.

The Deal Structure Nuances Nobody Talks About

Here’s something I’m still figuring out transparently.

Option 1 clients are higher ticket. Larger projects. Longer timelines. Deeper strategic influence. But they’re also harder to close — they come from deep relationships and referrals, and the sales cycle is long.

Option 2 clients have shorter sales cycles. The value is more immediately apparent. You can sell directly to a CEO from the first conversation. Get in. Map their value chain. Build the automation. Prove the ROI. Leave.

But here’s the tension: without a value-based pricing strategy, Option 2 engagements can undercut your margins significantly. You’re delivering real ROI — but if you’re pricing hourly, you may be leaving most of that value on the table.

I don’t have this fully figured out yet. I’m experimenting. But I think the answer lives somewhere in scoping tightly, guaranteeing a specific ROI outcome, and pricing against the value of that outcome — not the hours it takes to deliver it.

What This Means Going Forward

I’m not abandoning Option 1. The data transformation work is where I’m most comfortable, most credible, and frankly most energized.

But I’m no longer ignoring the market signal that’s been knocking on my door.

The Business Solutions Architect identity is the evolution. It doesn’t replace the data expertise — it elevates it. It means leading with the business problem, not the technical solution. It means selling the outcome first and letting the methodology follow.

That’s the shift. And I’m in it.

Are you feeling this same inflection point as a data consultant or full-time data professional? I’d genuinely love to hear where you’re at.

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, business intelligence and the business of data consulting.

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

Check out The Healthcare Growth Cycle Podcast on Spotify and YouTube.

Also — check out our free Healthcare Analytics Playbook eBook here.

This one is for every consultant, datapreneur and entrepreneur grinding through a sales cycle that feels like it’s going nowhere. Read this before you give up.

As a consultant, you’re typically an outsider. Closing the deal is one thing. Earning genuine trust, respect and collaboration from a brand new client team is a whole different challenge.

I’ve been through engagements where the entire first phase felt like an audition. The pressure is high. The surface-level insecurities of corporate America creep back in. You’re worried about what they think of you. It makes it harder to just execute.

That changed with this kickoff.

The 7-Month Grind Nobody Sees

This was a nearly 7-month sales cycle. Consistent follow up. Local event attendance. Ongoing rapport building with the CTO over months before a single dollar was exchanged.

At the time, it was grueling. I had my sights set on closing the deal and often overlooked what was quietly happening in the background — a real relationship was being forged.

Here’s what I’ve come to believe: when deals take a long time to close, it’s often for a good reason.

Now, if it’s a value-based issue — the prospect simply doesn’t see the value your offer brings — that’s a different story. Walk away or re-evaluate. But in B2B consulting, logistical bottlenecks are often the real culprit keeping the cycle spinning. If they’ve said yes in principle but are held up for other reasons, do not give up.

The marathon sales cycle actually strengthened our relationship, even though I couldn’t feel it while it was happening. I only had my sights set on closing the deal — and totally overlooked the incredible foundation being built during that grueling process.

What Happens When You Walk In Already Trusted

When we kicked off the Data Foundation Sprint — documenting database objects, mapping source-to-destination data lineage, sitting in executive and senior engineering meetings, building the foundations of a data catalog — something was immediately different.

The relationship I had built with the CTO over those 7 months was real. On kickoff calls and technical deep dives, everything flowed naturally.

No second guessing. No hesitancy. No sales barrier dynamics lingering in the room.

The moment that crystallized it — our kickoff call. When I introduced my engineer and architect, the CTO wasn’t sizing us up or running us through a mental checklist. He was genuinely honored to have us on board. Not the transactional energy you feel walking into a new enterprise engagement. Something rarer. A level of trust and excitement that you can’t manufacture — it can only be earned over time.

That’s what 7 months of showing up built.

And it extended far beyond the CTO. We quickly discovered that this client operates on a completely flat organizational structure. No egos. No management gymnastics. If we needed access from the CEO, he was a ping away on Slack. Engineers opened up the codebase without question. Everyone — from the most senior executive to the most junior engineer — is rowing toward the same mission.

That’s rare.

In mid to large enterprise engagements, hierarchy and political tension are natural. Things move slower. There’s more to navigate. With an early-stage healthtech startup where everyone has equity and the next funding round is on the horizon, you get a beautiful organizational harmony that is genuinely hard to find.

Why You Can’t Spot This in Discovery

Here’s the honest truth — you can’t fully see this culture during the sales process.

Prospects are still on guard during discovery. Naturally. It’s hard to fully open the doors to what your internal culture looks like before a contract is signed. I don’t blame them. I’m the same way in their shoes.

You won’t know until you’re in.

What I will say is this — the relationship you build before the contract is signed is the single biggest predictor of how collaborative the engagement will feel once you kick off. By the time we ramped up, we had been “the talk of their internal town” for quite some time. Everyone was excited and ready to fire on all cylinders from day one.

That would not have happened had the sales process been rushed.

The Real Cheat Code Nobody Talks About

For aspiring consultants and datapreneurs just starting out — hear this.

You cannot always control the speed of a sales cycle. There are tactics and techniques to help move things along, but sometimes there are true logistical blockers outside your control.

Use that time wisely.

Keep adding value. Keep building the relationship. Keep showing up — at local events, in their inbox, in their world. By the time the deal closes, you’re working off a foundation of genuine trust, connection and alignment.

That makes the consulting engagement 100X more enjoyable.

And when you find a client that pairs a pre-built relationship with a flat, mission-driven culture?

Recognize it for the gift it is. And sprint.

Because this is what separates consultants who grind forever from consultants who build empires. Not tactics. Not cold outreach sequences. Not a slicker pitch deck.

Relationships that compound.

Start building yours today.

Are you an aspiring consultant or datapreneur trying to navigate your first sales cycles, land high-ticket clients and build a consulting business that actually scales?

I offer 1:1 datapreneur coaching sessions at $200 USD per session. No fluff. No theory. Just real talk from someone who’s been in the trenches building Steinert Analytics from zero.

Book a discovery call with me here — let’s build your empire.

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 healthcare.

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

Check out The Healthcare Growth Cycle Podcast on Spotify and YouTube.

Also — check out our free Healthcare Analytics Playbook eBook here.

Core sales processes are working, but manually tie back to Google Sheets. The workflows set up in their accounting and CRM systems are gapped and incorrect.

Information isn’t always entered completely in the source system itself, or else it’s entered inconsistently. The thread that ties everything together are these Google Sheets (manually hard coding values regarding customer information and billing). The company’s overreliance on these robust spreadsheets is its weak point. A result of scaling at lightspeed.

Stay High Level (Or Get Lost in the Weeds)

Anyways, I mention all this because I went into that conversation being told we’d discuss churn. However, I wanted to stay at a higher level to start. I’ve learned to never assume. I started asking the CFO about his objectives for 2026.

What resulted was a brain dump of information about all his data quality problems between the CRM and financial accounting software for 45 minutes straight.

Even 2 years ago, I’d have folded on this call.

The amount of side tangents that happen during these calls makes it extremely difficult to know what question to ask next. Not to mention, it dilutes focus on which problem to even solve. There are 1,000 problems.

One moment you’re trying to talk about 2026 objectives, the next minute you’re talking about the horrible data mapping process that sits in the Power BI semantic model which makes it difficult to accurately report who has churned.

Three minutes later the entire conversation flips from churn counts to a different metric. Maybe it’s Customer Acquisition Cost (CAC) or Customer Lifetime Value (CLTV), even just a basic Total Active Customers count.

I’d appreciate you to comment below if you have experienced this situation before. I think it’s a foundational experience for any data leader in the trenches.

So what do we do? I’ve put together a few steps combined with a little framework to help in these blurry situations.

The Discovery Framework: Your Flashlight in a Cave Full of Bats

1. Business Objective - What are you trying to achieve?

Like I said in the beginning, starting at a high level lets executive leadership open up from a visionary lens. It’s a low pressure way to get the conversation started without sounding robotic and remaining genuine.

2. KPI - How do we measure success against the objective?

This is critical for narrowing in on a specific problem. Why you might ask? Here’s what I’ve learned over the years. Executives don’t really know what they need. They’ll list off 1-3 objectives and then 50 KPIs to track.

The key lesson…

Always bring them back to one KPI at a time. If an executive’s blabber is a cave filled with bats and monsters, narrowing in on one KPI at a time is the light at the end of the cave. It guides you.

3. Data Needed - What data do we currently have?

Which source systems pertain to this objective and KPI? Will we have to combine data together to see the full picture? Start thinking about that architecturally.

4. Current Pain/Gap - What’s broken that prevents you from achieving this?

For more mature organizations that have a digital process, it might be a slight tweak to their Hubspot and TypeForm process.

For less mature organizations, it might be an entire overhaul of their sales process and system workflows (like in the case of my experience last week).

If it’s an entire overhaul, question if they’re even ready for data solutions at this point of their journey. Don’t be afraid to explain they’re not ready and walk away.

5. Step Forward - What’s the actual fix?

Garbage in garbage out. If you’re gauging that it’s completely broken at the source, offer to work with them to rearchitect those processes completely.

Align these rearchitected processes to a Business Data Model. That offers clarity and alignment on data definitions and process structure without the technical complexities of building a logical and physical data model right away. They’re not ready for that yet.

You can explain to them that it’s critical for a data professional to help with these foundational pieces from the start so by the time the data is generated properly, everyone has full context and alignment.

This is about bridging that gap from being an IT data engineer to being a strategic partner.

If it’s not totally broken at the source, it could be a nice opportunity to build a data solution that helps them track CAC and how to keep costs down. Maybe it just demands a few tweaks to their current TypeForm fields to track customer acquisition more accurately.

With either of these, go back to your data lab and map out a timeline of steps for implementation and send it over to them.

The Secret Weapon: Come With an Agenda

Shout out to a recent article by . She pointed out the importance of coming to data meetings with an agenda, and it sparked a reminder at just how critical this is. Not only does it help guide the conversation, but it helps you be prepared in front of highly time-sensitive executives. Trust me, they appreciate this.

Here’s an example agenda:

I. Goals/Objectives for 2026

• Why Churn and CAC as priority?

• What decisions do these drive?

II. Metric Definitions

• Churn definition

• CAC definition

• How do you want these reported? (i.e. grouped by customer cohort, time/date, etc.)

III. How are these metrics currently tracked?

• Source(s)

• Who owns the process today?

IV. What are the difficulties/limitations of the process?

• What questions can’t you answer today?

V. Are the current state metrics trusted?

• How are metrics reconciled if different?

VI. Scope & Path Forward

• Deliverable

• Next steps

The Uncomfortable Truth

Hopefully this helps in your journey honing quality data discovery that helps you lead the discussion! None of these things feel natural initially. It will be uncomfortable, it will feel ambiguous, and you’ll make mistakes.

Just know that focusing on a single KPI as your north star often helps eliminate the noise, allowing focus and clarity in what the real issue and potential solution is.

Thanks for reading Rooftop Insights! Subscribe for free to receive new posts and support my work.

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.

On the business development front, the first two weeks of 2026 kicked off with a bang the size of a tank mortar. Reflecting back, I learned one of the greatest lessons of my career thus far on the people side of data leadership.

My intent for this issue is to focus on client dynamics and stakeholder management. I’m always learning as a principal consultant - and the last two weeks proved to be a test for the ages. If you follow my LinkedIn, a lot of my content has been hinting at what this article will cover.

However, I’m keeping this issue free flowing. No LinkedIn-esque post structure. Just my thoughts on paper about a client stakeholder issue that mandated 40 hours of non-work time problem solving, brainstorming, coaching and execution.

Although I can’t share nitty gritty details or get super specific, I’m going to walk you through this situation and all its learnings for data leaders managing up to the C-suite. I genuinely believe these learnings are what separate the good data leaders from the great ones. The extra effort it takes to acquire this knowledge can’t be found in a book. It demands a long career of establishing networks with the right data mentors and most tenured data architects on the planet with a willingness to fall on your face before rising up.

The Crisis: When Technical Executives Don’t See the Problem You’re Solving

One of the main reasons this situation is unique is because the C-suite is technical. They know Business Intelligence development. I consider them self-service BI power users. When you’re the leader of a healthcare company, especially in the mid-market, pairing BI skills with that knowledge makes you incredibly precise and influential to the rest of the organization.

However, this self-service BI wasn’t pulling from a strong data foundation. All reports are directly hitting their on-premise transactional database. No standard source of truth. No data governance. Just ad hoc queries and metric calculations that can vary from one report to the next.

This creates chaos. Exactly why the IT leaders brought us in - to solve the problem of metric clarity, company alignment and to get off a high maintenance on premise database.

However…here’s where I screwed up.

I assumed the C-suite also agreed metric clarity across the organization was an issue. News Flash: They did not.

It took me an entire year to realize this, but I never thought to align with the C-suite directly. I shifted from my data leader/consulting mindset to throwing all my trust in the organization’s hierarchical structure to resolve the misalignment.

Steinert Analytics delivered a ton of great work, but was it agreed upon and valued by the C-suite? Not as much. They couldn’t see and feel it.

So as the 2026 budget discussions happened, the Steinert Analytics line item was put into question by the C-suite. This sparked a conversation about whether or not we would stay on for the 2026 fiscal year.

Obviously an extremely stressful situation. And one that mandated deep preparation for navigating this.

The 40-Hour War Room: How Elite Mentorship Transforms Data Leadership

I credit a few mentors to my preparation for handling this. The biggest shout out undoubtedly goes to . He’s one of the most tenured data architects on the planet. (Check out his incredible Substack)

His knowledge on the people-side of data management and leadership is unrivaled, and I’m extremely grateful to have him in my corner for navigating situations like this.

I alluded to a lot of this in my LinkedIn post featuring Ergest below.

Back to the misalignment: the C-suite never thought that metrics clarity was a problem. When starting this conversation, you need to ask the top-most stakeholder what their objectives are.

Given it’s the beginning of 2026, the timing is perfect for this catalyst question.

From there, ask how they’re measuring success against those objectives. This narrows in on a select few KPIs.

It allows you to then explain what it will take to accurately build the reporting for those KPIs.

Notice, I never went into a defensive mode - pitching all of the data products and data models we had built to date. This would have fallen on deaf ears to the C-suite, because we never involved them in the builds of these deliverables. Although we built some foundational infrastructure and high priority data reporting automations, it was never FULLY aligned with the needs of the C-suite. Moreso the needs of middle managers and VPs.

Now, because I failed to ask the C-suite what their objectives are long ago, I had some ground to recover.

I put together one slide highlighting my Learnings and Changes going forward. This showcased my miss on not getting the C-suite’s objectives aligned out of the gate as the consultant. Instead we operated like a dashboard factory and I highlighted that.

Then I explained what changes we’ll make to this working partnership moving forward. This shows a proactive response that eliminates a sense of rumination and dwelling that doesn’t get us anywhere. Instead, it moves the needle immediately.

The Framework That Saved Everything: Crystallizing Our True Value

Ergest helped crystallize my engagement structure with clients. Due to this situation, the misaligned C-suite forced me to clarify every aspect of our value as a consulting agency.

Offer 1 is Metrics Clarity and Organizational Alignment by implementing Data Management. Let’s baseline a company’s Data & AI Foundation through metric definitions, standardization and the build of a data warehouse.

Offer 2 is producing a specific data project based off a key objective, their respective KPIs and a data product to support answering those questions. It’s a much smaller scope than the longer term Metrics Clarity and Organization Alignment data transformation.

When presenting to the C-suite, since they didn’t view Offer 1 as an issue, the alternative option to present was Offer 2. This allows flexibility when your core offer isn’t received well by a client.

Honestly, this exercise went far beyond this situation. It’s now helping me navigate the value Steinert Analytics can bring to all our healthcare clients. Depending on the environment and their needs, these packages allow us to be dynamic and flexible to fill a multitude of client needs.

The Unexpected Twist: When All Your Prep Hits a Wall

After 40 hours of afterhours prep, I was ready to consult and lead this situation to a healthy resolution.

However, the meeting ended up being switched to internal only. There was nothing I could do in this situation except trust my champion stakeholders and give the situation to the Universe (in my case God).

The outcome was positive. Our champion stakeholders ended up doing a fantastic job supporting our case and ensuring the relevance and need of Steinert Analytics for 2026.

Naturally, I was bummed that I didn’t get to speak my thoughts and consultation to the C-suite. After all that prep work, it was an anti-climatic build up for my nerves. However, the learnings and skill-up from all of this are extremely profound.

I hope you took something away from my learnings above. These skills are what truly separate data professionals, and it’s something AI can’t even come close to replacing.

Furthermore, the outcome of this reinforced the critical importance of established trust, transparency, and commitment to your client. Without those pillars, the relationship crumbles. It was our transparency and execution that built the foundation to withstand political C-suite headwinds when it comes to budget.

We’ve provided this client an incredible experience working with us. I look forward to moving forward with a strategic partnership first approach, and always tying back value to the leadership’s objectives. Routine check-ins from now on will be pushed by me.

What a MASSIVE learning to start 2026, and I can’t wait to hold this one close to my heart as we venture into many new client opportunities in healthcare!

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!

Check out The Healthcare Growth Cycle Podcast on Spotify and YouTube.

Also - check out our free Healthcare Analytics Playbook eBook here.

The low-code data pipeline solutions we use with this client are buggy (to say the least). Truthfully, there’s no foolproof way to guarantee these pipelines run 100% of the time. Things break, so we built a fallback solution to ensure that updated data can still be accessed if the tool goes down.

We didn’t just build a fallback solution though. There was no charge to the client for any of that time. Furthermore, we delivered it within a week of beginning the sprint. This truly delighted our client, and brings up an important practice when working with them: always strive to stay transparent and overdeliver.

In the last issue of 2025, I wanted to take the opportunity to highlight the ways we’ve stood out as a data consulting firm—real experiences, no fluff. Selfishly, this is a showcase for Steinert Analytics as well.

Does this fully apply to data team leaders? Not from a consulting angle. However, there are lessons to be taken away when interfacing with business stakeholders as a data team. Ask yourself if you align to these practices when working through data projects.

I’d love to hear your feedback as well!

Just Follow Through

It’s not only with promised delivery. Follow through with the little things as well.

If we say we’ll update a Jira ticket with details each day, we do.

When a VP leans on us to coordinate a meeting, we do that timely.

Even non-professional things like lunch or dinner with our client—we show up on time!

The small commitments build trust just as much as the big ones. Consistency in the minor details demonstrates reliability when it really matters.

When Things Go Wrong

We stay transparent. Always communicate bottlenecks.

Focus on the solution path forward if an issue arises.

Leverage resources to resolve the issue (ie. Microsoft support contacts).

Provide status updates as we’re working on a fix.

When pipelines break or data goes stale, hiding from the problem never helps. Our clients appreciate knowing what’s happening and seeing us actively work toward resolution. Own the mistakes. Communicate the plan. Execute the fix.

Building the Relationship

Find time for casual conversation and humor.

Don’t make every interaction 100% business. Take time to get personal. Talk about the weekend. Add humor where appropriate. (I love sending funny gif reactions to comments in our Teams thread).

Stay practically optimistic. No one wants to hear negativity from a data team or consultant.

The technical work is table stakes. The relationship is what makes you memorable. We’re solving complex problems together—there’s room for humanity in that process.

Show Up Prepared

Outside of daily standups, have an agenda for working session meetings (business data modeling is a good example).

If a data governance meeting, ensure you have all metric logic documented and in front of you. Quick references go a long way instead of having to pull open your IDE to remember the logic.

Review meeting notes beforehand and come ready to contribute. Wasted time in meetings erodes trust faster than almost anything else.

Review Progress Frequently

We typically review progress in our sprint retros with clients bi-weekly. What’s going well? What’s going badly? What can we improve? What do we keep doing?

Have one-on-one conversations quarterly with main stakeholders. Ask for feedback to improve.

Regular retrospectives aren’t just project management ceremony—they’re opportunities to course-correct before small issues become big problems. And they show clients you genuinely care about improving.

Seek New Opportunities to Add Value

Baseline reporting and AI foundations for our clients is the core, but not enough. What more can we do with the data? What insights can we unlock?

Study the business through stakeholder interviews and external resources (ie. healthcare podcasts, domain-specific newsletters/articles).

Always be one step ahead on the long-term vision and roadmap you’re on with clients.

The best consultants don’t just execute the SOW—they proactively identify opportunities the client hasn’t even thought of yet. That’s how you become indispensable.

Thanks for a Wonderful 2025

I know this issue is less conventional than many of my other issues. I hope these callouts inspire you to level up the value delivered consistently as a data leader or consultant in 2026.

Truthfully, I’m beginning to shift my focus from weekly newsletters here towards my bi-weekly podcast—The Healthcare Growth Cycle Podcast—in 2026.

I’ll still target to launch 1-2 monthly newsletters on Substack next year, but it’s not as much of a focus. The goal is producing and delivering content to 10X Steinert Analytics. Substack is a brilliant medium for community building and top-of-funnel credibility for me, but I’m finding the mediums where I’m able to foster intentional relationships one-on-one with potential clients is different (ie. podcasting, events).

It’s been an absolute pleasure growing this newsletter to 220 subscribers this year. Your following and engagement means more than you know, and I can’t wait to continue delivering insights via the podcast, LinkedIn posting, and a few new articles here next year!

So thank you to this community for an EPIC 2025! I wish you the best New Year and rest of your Holidays!

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 eBook course here.

At Steinert Analytics, we specialize in building data infrastructure and governance programs for mid-market and scale-up healthcare orgs to drive data trust, literacy, and capability that increases profit and benefits patient outcomes.

As data leaders, it’s easy to fall into the trap thinking everyone needs robust data infrastructure yesterday. With the demand placed on data teams to deliver reporting and insights, we see and understand the value a data warehouse drives daily.

However, not all companies will immediately benefit from such an implementation.

The most critical question we ask: Is the prospect we’re talking to even ready for a data warehouse & strategy to begin with?

You’d be surprised at the lack of maturity of some healthcare organizations. Filled with manual processes and hard-coded spreadsheets, a data warehouse out of the gate does not always make sense.

In this issue, I want to cover a few signs that a company will actually benefit from a data warehouse.

4 Signs a Company is Ready for Data Warehousing

Sign 1: There’s More Than One Source System

Does the company have a system of record (i.e., CRM, billing & accounting, EHR)? If it’s only one, most of the value in data and reporting can be found in that system’s native analytics capabilities.

Obviously, it depends on the vendor, but I’d always encourage an immature company like this to squeeze as much value out of their native analytics solution tied to their source system.

The con of this approach? If multiple users are exporting data from the source and manipulating it in their own way, metric definitions can become twisted. There is no governance.

However, typically companies that only have one source system are small (in my experience). The juice isn’t worth the squeeze to try and implement an enterprise-grade data architecture and governance strategy. It costs far too much and isn’t completely necessary.

If there is more than one source system (i.e., having a CRM and accounting software), now we’re getting somewhere. Often, companies need data pulled in from both the CRM and accounting software to accurately track revenue.

The CRM could have a varying definition of revenue compared to the accounting software. This is where modeling and conforming the data together in a single combined table is super useful.

Furthermore, if you want to understand the full picture of a customer’s journey to land on an accurate Customer Lifetime Value metric, it’s necessary to track when a customer was acquired via a given marketing campaign (CRM data) and the actual amount of revenue from that customer (financial system data).

Sign 2: The Data Infrastructure Can’t Keep Up With the Company’s Scale

Situations like this commonly arise when companies have a legacy on-prem system. Typically a SQL Server database powering their “data lake” (more like a data swamp, haha!).

It might be anywhere from 250GB to 1TB worth of data. In healthcare, this typically contains EHR, call center, and financial general ledger data (think NetSuite). There might be 50 to 100 stored procedures that kick off jobs to load report tables that are a hack show of a data model at best. Scattered queries, metric logics, and inconsistent join patterns make it hard to determine what is correct.

Metric sprawl and no data governance at its finest.

Loading these jobs—hundreds of millions of rows—puts strain on the database. Often jobs get stuck and fail.

One client we saw had to implement a SAS backplane in order to increase memory enough to keep limping along their on-prem database while we built their data warehouse in Microsoft Fabric.

Sign 3: Your Operational Workflows Are Digitally Established and You Want to Realize Deeper Insights From Them

Don’t put the cart before the horse. I spent an entire year trying to force data infrastructure into the roofing and home services industry without truly understanding their problems (hence my pivot into healthcare).

The early lesson learned there was exactly this point. Companies need to be further along the AI maturity lifecycle before they need data infrastructure. If you slap a data solution on top of a broken digital system, it’ll produce garbage. “Garbage in, garbage out” as they always say.

This comes down to identifying processes and workflows using their source systems. What’s broken? What’s inconsistent?

For example: How does a sales rep correctly add a lead into the CRM? Is this done consistently every time? Is every field needed to understand a lead, opportunity, or customer accurate and complete, or is only part of the picture available?

This all drastically impacts the quality of the data we have to work with in a data solution. If that quality is poor, DO NOT waste time building a data warehouse yet. They aren’t ready.

I’ve seen similar situations in healthcare. Broken processes that lead to poor data quality in the CRM and financial software.

Focus on fixing those problems first. Worry about the data infrastructure once those are in place.

A great exercise to get stakeholder process alignment is a Business Data Model (BDM). I’ve done this for companies in all types of industries. There’s a write-up about the value a BDM provided a client of ours in the roofing industry last year (link).

Sign 4: Your Company Is Made Up of Multiple Departments That Function Separately From Each Other

I’m pulling this one from Bill Inmon’s bucket of knowledge. I vividly remember him mentioning this on The Show podcast a while back (link). It stuck with me.

Point 4 is my own synthesized statement, but Bill dove into what a data warehouse really is (see a paraphrase below):

It’s a repository of corporate or enterprise data. Marketing, finance, accounting, and management departments that need to see a plethora of data. This data lives in separate applications and needs to integrate with each other.

My thought is: Confirm signs 1 and 4 and there’s a GREAT chance a data warehouse is needed at your company. Notice Bill’s focus on corporate/enterprise. Maybe not as relevant for smaller companies, but extremely valuable in data-heavy industries and companies with multiple source systems all being used by different departments.

Healthcare/healthtech is FULL of use cases for a data warehouse. The sheer amount of source systems generating data is overwhelming (at least for me). Niche EHRs, financial systems, telehealth usage, clinical data, insurance/claims. The list goes on. Pair that with the vast amount of departments doing different workflows with these systems, the picture starts painting itself for company-wide data integration and conformity with a warehouse.

The Bottom Line

There you have it. 4 signs a company is ready for data warehousing (with a focus on healthcare companies). I hope this helps paint a clearer picture for you.

I’ve been in so many situations where people wanted to build a data warehouse to “see the data better.” However, they failed to consider these critical aspects that signal it’ll actually be valuable.

Data warehousing is valuable, but it depends on the company’s maturity, technical sophistication, and questions they’re trying to answer from their data.

Always keep these in mind as you enter into a company looking to enable them with data & insights.

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 eBook here.

That’s how long a single report migration dragged on because we dove straight into development without asking the right questions first. And it was completely avoidable.

I realize this newsletter needs to provide value to healthcare data leaders in the mid-market and scale-ups. As a consultant, I often share perspectives from client projects—the wins and the failures. After my recent post about delivering ROI over maintaining perfect best practices, I’ve reflected on how this consultant mindset might differ from yours.

As a full-time employee, you likely have deeper patience and investment with the business to ensure data infrastructure is built right from the start. Though honestly, that’s becoming less common in 2025—AI has raised the bar even higher for data leaders to deliver value quickly, whether you’re a consultant or full-time.

In my opinion, good data consultants are viewed by execs as extremely efficient experts who can assess, diagnose, build, and solve pain points quickly. The expectation of speed forces consultants to take shortcuts in the immediate term to deliver the ROI they promised in the sales offer.

All of that to say: I don’t want to give the impression that I’m failing to place myself in your shoes. I owe it to my audience to relate EXACTLY to healthcare data leaders, and I feel that I’ve neglected the full-time perspective in past issues.

So with this issue, I’m focused on providing project management tactics to ensure your data implementation projects start on the right foot. I want to walk you through one specific example of a brownfield data migration project—a single report—that went sideways for a month due to poor project management.

The Reality: Legacy Chaos Is Your Starting Point

In my experience, the healthcare mid-market is covered with brownfield data infrastructure and countless problems to solve. Legacy code written by a DBA who left two years ago. All data sitting in on-premise SQL Server—more or less a data swamp with massive report tables and stored procedures built for single reports and use cases.

It’s tempting to dive into development, mirroring legacy logic like-for-like (or a refactored version) in the new environment.

This creates massive issues.

You don’t have context for why a query filters on three different procedure codes. Date filtering logic uses a specific time range—why limited to the last 4 months? Additional fields in the SELECT force unnecessary tables and joins that might not actually be needed for the new report.

All of this is problematic because it demands enormous energy and time to reverse engineer, but you don’t have full context for the historical logic’s business reasoning OR the migration’s current business needs.

Pretty soon you’re spending massive time bringing in every field and piece of logic from legacy into the new cloud environment without fully understanding what and why you’re building. Scope creep arises, complexity ensues, and your stakeholders begin to wonder why things are taking so long.

This is obviously a huge issue, but trust me—it happens to developers constantly.

The Solution: Three Steps Before You Code

If your team operates in Agile (I recommend it), look to your Scrum master, project manager, or business analyst to obtain business context for a given report build. Whoever is interfacing with the business and gathering requirements is who you should work closely with.

Next, follow these steps.

Step 1: Confirm Your Understanding of the Report’s Intent

What question is the business trying to answer?

Far too often, we get into development without full knowledge of a given metric or report’s context and intent. Ensure the project manager or business analyst understands the details from a business perspective. Ask strategic questions and try to reveal the details of the report’s business implications.

Is the legacy logic actually correct? Why are specific logic pieces present in the existing report?

If requirements seem generic and you’re met with a lack of awareness on how the report is used, what certain metrics mean, and why they’re calculated a certain way—this is an indicator that more discovery work is needed with the business.

Do not start building until that clarity and confirmation is there. Otherwise you may go down a query rabbit hole that is flat out wrong. I’ve been there.

Step 2: Conduct an Inventory Analysis

Take a look at the legacy code and confirm which fields and tables are actually needed for the new build with the project manager. I typically use Google Sheets to accomplish this. My columns are usually: Field Name, Table or Object Name, Need (Y/N), and Notes.

List out every field from legacy and decide if you actually need it. Also look at new requirements and see what may need to be added. Document it all here.

This narrows what a developer will have to code in the new environment.

Step 3: Begin Development with Clarity

Once the business context is understood and the inventory analysis is completed, you’re ready to develop. Now you can begin building out the Fact and Dimension tables and perform data modeling/OBT without blindly coding or wasting time.

The Bottom Line

The number one takeaway from this issue is the inventory analysis. I think requirements gathering and discovery are table stakes, but process and documentation aren’t talked about enough in Agile data teams.

Again, this assumes a brownfield implementation or data migration. I don’t want you to make the mistake I made of going in and trying to mirror the logic and fields of a legacy query.

Deeply consider what is actually needed for a report in the new environment and new state. Lots of times, legacy logic is just flat out wrong—unnecessary fields, tables, and filter logic that create complexity.

Cut through the noise by syncing with your project manager, the business, and documenting what’s actually needed. The report and its code will set you up for strategic, impactful, and focused development that answers business questions.

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 eBook here.

In your first week, you get a lay of the land and realize there are 50 legacy Power BI reports directly connected to the database. The database contains source data mainly from their EHR. There are a few other sources such as call center data and their financial general ledger (probably NetSuite).

You explore and sift through hundreds of stored procedures and agent jobs used to load their data in batch pipelines.

During this process, you uncover Net Revenue SQL logic defined in 3 different ways across two stored procedures and one Power BI DAX formula.

You dig through shared OneDrive folders hoping to find (at a minimum) a stale data dictionary or data glossary - but you find nothing.

Pretty soon you’re on a call with the VP of Revenue Cycle and CEO asking how the company defines Net Revenue.

The VP of Revenue Cycle says deductions include write-offs.

The CEO says deductions do not include write-offs.

A big debate starts on call. You sit there and mediate the discussion while they hash out the “why” for each respective logic. Neither stakeholder is necessarily wrong, but viewing a KPI from a different context can create slight logic differences.

This exact scenario is a result of no central data governance.

This matters GREATLY because it causes strategic misalignment, which erodes company-wide trust in the data. A lack of trust creates poor or no decisions that limits the profitability of healthcare companies every day.

Why Decentralized Governance Doesn’t Work in Healthcare

In 2019 (right when I got into data), data mesh was surfacing as a go-to enterprise architecture for data management.

Snowflake.com defines data mesh as:

In a data mesh, teams actively manage the data within their specific business domains. These teams also build and maintain pipelines that deliver data products to consumers throughout the organization.

Reading that, one can rightfully assume strong governance standards are needed for this approach to work.

News flash: unless you’re a highly data mature organization with lots of investment in your data ecosystem, the data mesh does not work. No mid-market healthcare company has enough investment dollars to throw at the data mesh. And even still, investment dollars don’t guarantee a good outcome.

The regulatory complexity, complex EHR and insurance claim data, and highly sensitive nature of PHI data makes data mesh a failed architecture in healthcare. I can see the positive intentions of data mesh - aka giving control to the users closest to the data. But the reality is, it creates far more complexity than it does value.

Getting a Veteran Senior Data Architect’s Take on Centralization

Last week I had coffee with a fantastic senior/lead data architect at a large insurance company in Columbus, Ohio (my hometown). That conversation inspired the writing of this issue - it was filled with passionate and energetic war stories about our experiences in the space.

To have someone who has been in industry since the early days of data to now, I felt like I was talking to one of the godfathers of data engineering like Bill Inmon or Ralph Kimball. A truly knowledgeable and business-first architect, I left that conversation filled with fire to continue executing for our clients.

His arguments against decentralization were formed through learned experiences. The approach he’s taken at his insurance company is centralization. They’ve experienced a ton of success from that.

The data team owns all of the data. The key partnership is between the data architects to the business stakeholders.

This lead architect is responsible for the data dictionary, glossaries, and all metadata management. He’s spent years building an in-house solution to handle all of this comprehensively.

Any new metric or dimension that needs defined is first documented with comprehensive data lineage right in the code notes. That is then loaded into the data dictionary/metadata explorer he built.

The business definition is then brought before business stakeholders and explained in plain English by the architects. Whatever is agreed on in that meeting is then updated in the data glossary. They’ve been leveraging this process for a long time, and it has worked VERY well.

The glossary can be consumed via a UI. This has resulted in a mature data organization, trusted metrics, and faster decision-making to help their customers.

It’s worth calling out that this insurance company had the budget to build their own solution. Lots of healthcare companies don’t have the time or budget to do that! Buying a solution of the shelf for data governance and metadata is completely fine.

Let’s break the above into 3 pillars:

1. Technical expertise lives where it should (data team understands the data deeply)

2. Strategic partnership with business (data architects bridge the gap)

3. Governance assets that scale (data dictionaries, documented definitions, accessible metadata (built or bought) )

These three pillars work together as a system. The data team’s technical depth ensures governance decisions are sound. The partnership model ensures those decisions actually reflect business needs. And the governance assets ensure the work compounds over time rather than getting lost in someone’s head or a forgotten Confluence page.

Your Next Steps

So what does this mean for you?

If you’re seeing the same symptoms at your organization - multiple definitions for the same metric, stakeholders arguing about what “net revenue” means, data dictionaries that don’t exist or haven’t been touched in years - you have a governance problem. And it’s not going to fix itself.

Here are the red flags that tell you it’s time to centralize governance:

You need centralized governance if:

• Stakeholders are defining metrics themselves without technical oversight

• You have 3+ definitions for the same KPI floating around

• Business users are building their own logic in Excel or Power BI DAX calculated fields

• Nobody can agree on what the “source of truth” is

• Your data team spends more time reconciling conflicting numbers than building new capabilities

Where to start:

1. Audit your current state - Document every place a critical metric is defined (stored procedures, DAX formulas, Python scripts, Excel macros). You need to know the extent of the problem.

2. Centralize ownership to the data team - Make it clear: the data team owns governance. Not the business. Not IT. The data team.

3. Build your first data dictionary - Start with your top 10 most critical metrics. Document the business definition and the technical logic. Get stakeholder alignment. Load it into an accessible tool or UI.

4. Create the partnership model - Pair your data architects with product managers (if budget allows) who can translate between technical and business language. This is your bridge. Otherwise lean on data architects to communicate directly to the business like this insurance company I discussed.

The conversation you need to have with leadership isn’t about control. It’s about clarity.

It’s about ensuring that when the CFO asks “what’s our net revenue?” and the VP of Revenue Cycle asks the same question, they get the same answer. Because right now? They’re not. And that’s costing you more than you realize in bad decisions, eroded trust, and strategic misalignment.

The Columbus architect I spoke with didn’t build a mature data organization overnight. It took 20 years of discipline, iteration, and commitment to centralizing governance where it belongs - with the people who understand the data on a technical level.

But you don’t need 20 years. You just need to start.

Christian Steinert is the founder of Steinert Analytics, helping healthcare & roofing 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.

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

In this issue, I’m focusing on how to truly walk the walk as a consultant. I think this piece is therapeutic for my own psyche, and selfishly, why I’m diving into it on this week’s Rooftop Insights issue.

It’s easy to talk about best practices in data. After 4 years of establishing my brand as a true data management expert, all of my content promotes the build of robust data modeling, minimal tech debt creation, and building data platforms correctly the first time.

Proper data management feels so effortless when writing content for LinkedIn or Substack.

Start with the problem. Talk to end users. Understand what questions they’re trying to answer. Build a data solution that helps them answer that question (even if it’s just one or two to start). Reinforce taking action on these insights.

I get a hit of dopamine when I align my content with these best practices, highlighting what we did well at XYZ clients that led to success using these frameworks (it’s true!), and trashing every data team that violates these practices.

Poor practices that easily arise in a real-world working environment are:

1. Building what a stakeholder asks for

2. Querying directly off the raw transactional tables

3. Lifting and shifting legacy SQL logic into the cloud

4. Throwing 30 metrics at a stakeholder without qualifying their necessity

2+ years full time in my own data consulting practice has taught me a massive lesson. Best practices are sexy to talk about, but the speed needed to show value ASAP creates obstacles towards achieving them fully.

Data management best practices are the North Star, existing as a goal to ALWAYS keep your sights on, but typically not practical in the initial phases of development at clients.

Why Best Practices Take a Back Seat (And Why That’s Okay)

Why, might you ask?

Investors and the c-suite executives don’t care. They need value NOW.

In a truly data-first organization, c-suite and executive buy-in is the ultimate solution to an “order-taking data culture”. It’s also the solution to extended timelines for building with best practices.

People talk about buy-in at the top as one of the most important aspects of successful data teams.

Is this always realistic though? In my near decade of experience in analytics, hell no.

CEOs report to investors. You’re dealing with incredibly talented and accomplished individuals. This comes with a hefty amount of ego and pride.

These executives have gotten to where they are due to operating with extreme efficiency, cutting the fat and executing only the pieces that move a business 10X. They’re also extremely aware of the latest ways of working.

In my opinion, AI tooling is more hype than reality, but it absolutely does accelerate our efficiency. In the world of data management, c-suite execs are over-promised by AI vendors on efficiency gains, but do you think they care to learn about why that is? No.

If they hire a data team, they need to see results immediately. All of this combines to make our job incredibly hard, with massive expectations.

In the same context, as a data consultant our goal is to show value ASAP. That’s part of our offer’s ROI guarantee at Steinert Analytics.

Otherwise, what’s the point of hiring a 5-6 figure data consultant for a 4-8 week project “sprint”?

In 2025, we don’t have 3-6 months of runway before showing value. Value must be shown at hyper speed. And to do that, you have to deliver incrementally and iteratively.

This requires ditching perfection. In my eyes, delivering perfection as a data engineer is aligning to best practices while considering the business need.

When you’re up against the clock, it’s a Return on Investment race that results from the pressures of your clients/stakeholders’ needs and the promise you made to sell your impressive offer.

Today’s State of Working in Healthcare Data for the Mid-Market

Let me give you some insight into a mid-sized healthcare company’s data ecosystem in the United States.

They’re typically brownfield. We begin an engagement by documenting all databases, tables, fields, source systems, data flows, existing reports, data lineage and data pipeline operations. This builds the foundation of a data catalogue they never had.

They’re querying directly off their transactional database (typically SQL Server). Sometimes that’s even hosted on-prem (my goodness!).

There is little to no documentation of anything. We’re unraveling thousands of lines of SQL code that sits in 400 stored procedures and views written by a DBA no longer at the company.

These stored procedure logics have never gone through due diligence. They’re just being assumed as the correct source of truth regardless of data validation / code quality.

They have 30-50 Power BI reports that are directly connected to the transactional database. This is mainly querying EHR data.

There may be 3 versions of the same Power BI report in two separate workspaces. Stakeholders with influence are picking and choosing which reports are considered “source of truth”.

You may have one or two high level stakeholders that have built their own version of a Power BI report and claim that’s the source of truth for a given set of metrics. Other users follow along due to the influence of these top level stakeholders.

There’s also plenty of Excel reports that are being manually updated daily by pulling from a few of these legacy Power BI reports and native EHR UI reporting.

As the consultant, it’s our responsibility to identify one critical report we can take from a manual workflow into full automation. This baselines our offer with a hard ROI based off time to dollar savings in labor cost.

We’ve found this use case is common enough to confidently propose the solution to them, while providing extremely hard evidence of an ROI we can guarantee quickly.

The Trust-Building Paradox: Match Legacy First, Then Improve

When we enter the build phase, it’d be ideal to start from scratch. However, the reality is these mid-sized healthcare companies treat their legacy reports as the source of truth.

If you’re going to gain trust early, you don’t have the luxury of redefining the data model into a new logic that produces slightly different numbers in your new and shiny data warehouse. Often, you’re stuck building so numbers match legacy as a baseline.

Once you’ve proven that in a quick POC phase, trust builds. Then and only then can you start challenging the legacy logic vs. your new, best practice data model that sits in the data warehouse. From there, conversations between you and these influential stakeholders start happening.

It forces these stakeholders to critically think about how metric logics are defined. You’d be shocked at the lack of clarity that is uncovered in these conversations. You as the data person begin showing them why their legacy logic is incorrect, but you only get to do that by proving you can validate your new build to their legacy first.

How to Deliver Value Immediately While Thinking Longer Term

I often hear that you need to build what satisfies their requirements in the immediate while simultaneously building your new and improved solution for the long term.

While I agree with this in theory, in practice while data consulting it’s a whole hell of a lot harder. You don’t have 40+ hours per week to dedicate to one particular client.

Maybe it’s on me to get more efficient, but if you’re capped at 15-20 hours per week you have to prioritize delivering value that can be seen and showcased - at least early on.

This is why you must over-communicate to your clients! If you’re delivering value but know it’s violating best practices for the long term health of a company’s data, flag it to them.

A great set of questions that helps me baseline “the value:tech debt ratio” is this:

What value is this delivering to our stakeholders?

ie. saves them $40,000 per year in labor costs

What’s the opportunity cost of this approach?

Maybe slightly more subjective, but here’s the deal. If you build spaghetti legacy logic to automate a manual report quickly, long term this takes away from stakeholders being able to use the same dataset for other decision making.

You’re going to be limited on detail and other information. This will require end users to submit requests to the data team.

They’re going to ask the data team to add a field and that ends up consistently burning 5-10 hours per week of an analytics engineer’s time to add that field into the nightmare of spaghetti code.

No documentation will be produced, and no one will truly understand the logic of this hairy spaghetti query used to power this automated report.

Whereas if you’d have taken the time to build a best practice data model, the stakeholders could have gotten what they needed right away (with proper training). Analysts and engineers wouldn’t be stuck adding an additional field to a table and burning more valuable labor hours.

Overcommunicate and Carve Out Time

With all that said, overcommunicate tech debt, their limitations and drawbacks of the deliverables to satisfy quick value creation and ROI guarantees. This helps to set expectations with them.

Encourage the team to carve out time in established Jira tickets/statements of work for the more robust data modeling and future state of the data warehouse.

As long as you are delivering value that establishes trust, overcommunicating to level set expectations, and illustrating the outcomes of a more robust data warehouse build, stakeholders will be much more understanding of where you spend your time.

I hate to say this, but it’s really all a balance.

A balance of delivering ROI that establishes trust. A balance of overcommunicating where we are still falling short. And guiding them on the action steps and plan to improve so we can ensure we’re building the most robust data foundation for these healthcare companies in the Age of AI.

Healthy Long Term Partnerships

What I’m describing are really just attributes of good project management and reliable consultants.

Deliver quick wins that establish trust.

Stay transparent about the pros and cons of what we’re doing.

Create an action plan to keep moving towards a positive outcome while ensuring everyone is still getting value while we’re doing it.

Sounds easy enough? Hah! I know, this is extremely challenging.

It’s a process that I think I’ll be learning forever, but let me tell you - sticking to our core values of transparency, egoless candor, continuous learning and work ethic has always shined through for being successful with our clients.

At the end of the day, data transformation consulting is a people & relationship game.

Without transparency, trust and continuous follow-through, the relationship erodes. Sound familiar to a long term relationship of any kind? That’s because it is.

This is a partnership, not a transactional sale. Treat it as such.

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.

This piece comes from the heart. It sits deep in my bones because it’s ultimately our offer at Steinert Analytics.

Since October, tech events have been a heavy focus for me. I’ve written about this in previous issues (specifically the one highlighting Kickstart Ohio 2025—where I met Steve Wozniak and rallied with other entrepreneurs).

We all know the drill—AI is the talk of the town. It seems like no matter where you go, AI is the most popular topic in existence. The United States labor market hasn’t seen this kind of disruption before.

As enterprises invest millions to billions of dollars into AI, naive professionals forget a few critical things as we cling to any job security we think is left.

What dominates the news headlines are market-leading enterprises like Salesforce, Amazon, Target, and Google. We automatically assume AI is taking over all areas of corporate life, but we forget where the bulk of companies are in their AI Maturity Lifecycle.

Most Companies Are Still Running Like It’s Elementary School

Leave it to my consulting experience to give me a first-hand look into how the majority of small to mid-market healthcare companies are running in “the Age of AI.”

I’ve written extensively about this on LinkedIn already.

The majority of these companies are still piecing together metrics from 7 different places and hard-coding the values into an Excel workbook. This gets distributed company-wide and is considered the “source of truth.”

There is barely any automation happening. And even more concerning, the information management discussions that should have happened years ago are only just beginning.

When I say “information management” discussions, I’m talking about defining what a data point means. This could be something as simple as how a healthcare company refers to a customer (aka customer vs. patient), or something a little more nuanced—calculating net revenue.

Do we include or exclude write-offs as part of our net revenue calculation? Which adjustments do we take off our Charge Amount to get our true “net”?

For those not in the data management space, you’d be SHOCKED at the number of companies that don’t truly define these metrics out of the gate.

I’m speaking from 8 years of experience in the space, working with every company profile from SMB to F200 enterprises.

Operations calculates it one way.

Finance another.

Marketing yet another.

All similar, but slight variations that make anywhere from a couple thousand to millions of dollars in difference.

This matters a shit load when you have a group of investors and a CEO in a board room talking EBITDA and valuations.

Each Metric Needs Alignment and Agreement

It might sound easy to establish these ground rules, but let me tell you—it isn’t.

Why?

Humans have opinions, perspectives, and egos that push back on rules (aka data management) like an African Bull Elephant bulldozing a tree.

Meetings I’ve Experienced

Let’s set a short meeting to get alignment on how we define Cash Goal. Do we look at it from the perspective of all cash collected in the last 2 months (60 days)? Or the last 7 days?

Sometimes it takes a company until the end of each month to collect on accounts receivable. There can be a mad dash at the end of a month to get invoices paid by a payor or private payor.

Therefore, if we’re measuring the efficiency of a company to collect physical cash from its sales, one perspective is that it might not be the most accurate view to consider monthly timeframes when the end of the month is a push for paid invoices anyways. Even if that’s industry standard.

You should consider cash collected each week to get a better picture for just how fast a company collects cash in some perspectives.

Both make sense, but differences in perspective, opinions, and egos make this seemingly straightforward conversation last over an hour.

A VP of Finance holds steady on the industry standard metric. A CEO holds firm on the metric that will actually indicate long-term cash flow efficiency.

See how this can get extremely complicated now?

That’s what we data management professionals facilitate and guide a business in doing. And it’s a whole lot more than just building the correct SQL code.

How Steinert Analytics Alleviates This Gap

I’m not going to pitch our entire offer. But I will speak from our experiences and the benefits our small to mid-sized healthcare clients have.

We kick off an engagement by documenting your entire data ecosystem. This typically isn’t leveraging some expensive and fancy data governance tool. In fact, the data foundation sprint entails populating a robust data catalogue in Google Sheets.

It’s cost-effective and puts the onus on us consultants to genuinely populate and update this living and breathing asset for your organization. We give it the attention and care it deserves, without breaking your bank.

In doing that, it surfaces lots of legacy logic (if brownfield). What a company calls Net Revenue we may discover that it’s defined in 3 different ways across 5 reports.

We document that and save it for the day we inevitably begin work as your healthcare organization’s fractional data engineering team of choice.

These steps give us the awareness we need to ask the right questions. Where we see differences, we also see opportunities to deploy data management exercises with your decision makers.

This involves calling out these inconsistencies as questions and orchestrating meetings that address discrepancies in definition. Ultimately, as painful and productive as these conversations are, we get your organization on a track of unparalleled trust in your data.

Whatever we build mirrors the people, processes, and technologies that support your healthcare organization’s long-term growth.

Correct logic.

Consistent definition.

Trusted data.

Robust insights and AI models that drive profit and generate revenue.

The Bottom Line

Without the unsexy and foundational work data management & engineering professionals do, all the hype around AI will fall short for your organization.

And unfortunately, that’s where the majority of companies are at right now.

Start with the unsexy stuff. Get your definitions aligned. Build trust in your data. Then—and only then—will AI actually move the needle for you.

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.

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.

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, , 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.

After wrapping up Part 1, I went back to our client projects to pull examples of revenue generation ROI. And you know what? This boils too many oceans to write about in a concise and easy to follow way.

This isn’t a result of poor implementation. Rather, the data maturity of the healthcare clients we generally work with are very early on in their data lifecycle journey.

Standardizing metrics and automating reports in a centralized data warehouse is exactly what our clients are in need of. The revenue growth piece is an entirely different statement of work, demanding complex data analysis and methodologies vs. the foundational data engineering we’ve been delivering this year.

So we’re pivoting.

Instead of forcing a revenue generation story, we’re going straight to what actually matters when you’re early in your data maturity journey: how to communicate the ROI you CAN prove to the people who control your budget.

Because here’s what I’ve learned working with healthcare organizations: Cost savings is your best opening move. It’s concrete. It’s defensible. Nobody can argue with “we’re spending X hours on this, here’s what those hours cost.”

Revenue generation comes later—once you’ve built trust, proven you can deliver, and have the infrastructure to actually measure impact. But first, you need to get the initial project approved.

Today, I’m showing you how to take the time savings ROI from Part 1 (that $83K over 5 years, 160% ROI) and translate it into six different languages for six different executive personas.

And instead of dragging this into a third part about “how to present your deck,” we’re keeping this as a tight two-part series. Part 1: Calculate it. Part 2: Communicate it. That’s the playbook.

Let’s get into it.

Quick Recap: The Time Savings ROI from Part 1

Before we dive into stakeholder communication, let’s quickly recap what we calculated last week:

The Problem:
A VP of Revenue Cycle spending 90 minutes every day manually pulling data from multiple Power BI reports and native EHR exports, then hard-coding numbers into Excel.

The Numbers:

• 375 hours per year of manual work (1.5 hours × 250 working days)

• $27,045 in annual labor costs (375 hours × $72.12/hour)

• $26,500 first-year investment ($18K development + $8.5K technology costs)

• $18,545 net annual savings after year one

• 11.6 months to break even

• $83,225 net benefit over 5 years (160% ROI)

That’s the foundation. Now let’s talk about how to sell it.

Why Cost Savings First?

Before we get into the personas, let me make the case for why cost savings should be your lead story—especially if you’re working with organizations early in their data maturity lifecycle.

1. It’s immediately quantifiable
You can time manual processes today. You can calculate labor costs today. No predictive models. No attribution debates.

2. It requires minimal trust
You’re not asking leadership to believe you can transform their business. You’re just asking them to believe you can eliminate manual work. That’s a much smaller leap.

3. It creates the foundation for future investments
Once you prove you can deliver a 160% ROI on automation, the next conversation about predictive analytics or revenue optimization gets a lot easier.

4. It’s defensible under scrutiny
When the CFO asks “how do you know this will work?” you can point to documented time tracking, industry benchmarks, and conservative assumptions. You’re not speculating—you’re calculating.

Revenue generation ROI? That comes later. Once you have the infrastructure. Once you have clean data. Once you’ve built trust by delivering on your first promise.

For now, focus on what you can prove.

The Framework: Same Numbers, Different Emphasis

Here’s the universal truth about ROI: Every executive cares about it, but they evaluate it through completely different lenses based on their role, responsibilities, and what keeps them up at night.

The $83K in time savings stays the same. The 160% ROI stays the same. The 11.6-month payback stays the same.

What changes is which part of the story you lead with and what you emphasize.

Let’s break down six key personas you’ll pitch to as a data leader.

Persona 1: Director/VP of Analytics

What they care about:

• Team capacity and burnout

• Data quality and consistency

• Proving the value of their department

• Getting budget for future initiatives

What keeps them up at night:
“My team is drowning in report requests. We’re order-takers, not strategic partners. And every time budget discussions come up, we’re seen as a cost center.”

How to Pitch the $83K ROI

Lead with: “Your team gets 375 hours back per year”

Emphasize: Eliminating soul-crushing manual work improves retention and morale

Frame it as: “This frees your team to work on strategic initiatives that showcase analytics’ value”

The win: Position this as proof of concept for larger data investments

The Conversation

“This automation saves 375 hours annually of manual data entry—that’s nearly two months of full-time work. That’s not just cost savings. That’s your senior analyst’s time freed up to build the predictive models you’ve been wanting to tackle. That’s capacity to move from reactive reporting to proactive insights.

And here’s why this matters for your budget conversations: This is proof that investing in data infrastructure pays off. When you go ask for budget for the next project, you can point to this and say ‘We delivered a 160% ROI on the last initiative. Here’s what we want to tackle next.’

The $83K savings pays for itself in 11.6 months. But the real return is positioning your team as strategic enablers, not report factories.”

Questions They’ll Ask

“Will this reduce headcount?”
→ No. This reallocates talent to higher value work. We’re not eliminating the role—we’re eliminating the busywork that prevents them from doing the strategic work they were hired for.

“What if the person who knows the manual process leaves?”
→ That’s actually the biggest risk of NOT automating. Right now, you have key person risk. The automation includes documentation and removes that single point of failure.

“How long until we see results?”
→ Time savings are immediate—they start the day the automation goes live. The 11.6-month payback period accounts for the initial investment. After that, it’s pure value creation.

Persona 2: Director/VP of IT

What they care about:

• System stability and uptime

• Security and compliance

• Reducing technical debt

• Minimizing manual touchpoints that create risk

What keeps them up at night:
“Every manual process is a security incident waiting to happen. We’re one audit away from a finding. And I’m tired of being the bottleneck for every data request.”

How to Pitch the $83K ROI

Lead with: “This eliminates 375 hours of manual system access annually”

Emphasize: Reduced risk of human error, security incidents, and audit findings

Frame it as: “Moving from 250 manual data pulls per year to zero reduces your attack surface”

The win: Infrastructure investment that reduces operational risk

The Conversation

“Every manual data pull is a potential security incident. It’s a potential error. It’s a potential audit finding. And right now, we’re doing 250 of them per year—every single workday someone is manually accessing systems, pulling data, copying it into Excel.

This automation eliminates 375 hours of manual system access per year. The $83K in savings is great, but the real value to IT is reducing risk and freeing up cycles currently spent troubleshooting ‘why doesn’t my report match?’ issues.

You get consistent, auditable data pipelines with proper access controls. You get documented processes instead of tribal knowledge. And you get 11.6 months to break even on an investment that dramatically reduces your operational risk.”

Questions They’ll Ask

“What’s the security model?”
→ Role-based access control, encryption at rest and in transit, full audit logging. We’re following HIPAA-compliant cloud architecture patterns with documented security controls.

“Does this add complexity to our stack?”
→ It’s cloud-native using managed services, which actually reduces complexity. No new servers to patch. No new infrastructure to maintain. We’re leveraging Azure services you’re already using with the addition of Microsoft Fabric which directly integrates.

“Who owns maintenance?”
→ Clearly defined SLAs with documented runbooks. We’ll train your team or provide ongoing support—your choice. But the architecture is designed to be low-touch.

Persona 3: VP of Revenue Cycle / VP of Operations

What they care about:

• Operational efficiency

• Meeting departmental KPIs

• Team productivity

• Having reliable data to make decisions

What keeps them up at night:
“I need my team focused on reducing A/R days and improving collections. Instead, they’re spending hours every day just compiling the reports that tell us where we stand.”

How to Pitch the $83K ROI

Lead with: “Your VP gets 90 minutes back every single day”

Emphasize: Faster access to accurate data enables better decision-making

Frame it as: “Instead of compiling reports, your team analyzes them”

The win: Operational capacity without adding headcount

The Conversation

“Your VP of Revenue Cycle spends 90 minutes every day manually compiling this report. That’s 375 hours per year—over nine full workweeks—that they’re not spending on reducing A/R days, improving denial management, or optimizing collections.

The automation pays for itself in 11.6 months. After that, it’s pure capacity creation. Your VP gets their mornings back. Instead of pulling data until 10:30 AM, they’re analyzing it at 8:00 AM and taking action by 9:00 AM.

And here’s the strategic benefit: as your patient volume grows, this doesn’t require adding another analyst. The manual process would. You’re creating operational leverage—doing more with the same team.”

Questions They’ll Ask

“Will this disrupt our current workflows?”
→ We’ll phase the implementation to minimize disruption. Run the automated and manual processes in parallel for 30 days. Nothing changes until you’re confident the numbers match.

“What if the numbers don’t match what we’re used to?”
→ That’s why we build in a validation period. We’ll document any differences and make sure you understand why. Often, the automated version is actually more accurate because it’s consistent.

“Can we customize this as our needs change?”
→ Yes. It’s built with modular, documented logic. As your reporting needs evolve, we can adjust without rebuilding from scratch.

Persona 4: CFO

What they care about:

• Cash flow and working capital

• ROI and payback period

• Budget efficiency

• Risk management

What keeps them up at night:
“Every dollar we spend needs to generate a return. I need proof this works before we invest. And I need to know the ongoing costs, not just the up-front price tag.”

How to Pitch the $83K ROI

Lead with: “160% ROI over five years with an 11.6-month payback period”

Emphasize: Hard dollar savings, not soft benefits

Frame it as: “Year one investment: $26.5K. Years 2-5: $18.5K annual net savings.”

The win: Quantifiable return that improves operational efficiency

The Conversation

“We’re proposing a $26,500 first-year investment that generates $83,225 in labor cost savings over five years. That’s a 160% ROI with an 11.6-month payback period.

Here’s the breakdown: Year one, we invest $18,000 in development and $8,500 in technology costs. We save $27,045 in annual labor costs. Net first-year benefit: $2,045. Years 2-5: we continue saving $27,045 annually with only $8,500 in ongoing technology costs. Net annual savings: $18,545.

The math is straightforward: we’re buying back 375 hours per year at $72/hour through automation that scales. Conservative assumptions. Documented time tracking. No hand-waving.”

Questions They’ll Ask

“What are the ongoing costs?”
→ $8,500 annually for cloud infrastructure and Power BI licensing. That’s it. No hidden fees. No surprise maintenance costs.

“What if volumes grow?”
→ The automated solution scales with minor incremental costs. The manual process would require adding FTEs. As volume grows, the ROI gets better, not worse.

“How confident are we in these numbers?”
→ The time tracking is documented—we literally timed the manual process. The labor costs are based on actual salary data. And we’re using conservative assumptions on implementation time. If anything, we’re understating the benefit.

Persona 5: COO

What they care about:

• Operational scalability

• Cross-departmental efficiency

• Process improvement

• Enabling growth without proportional cost increases

What keeps them up at night:
“We’re adding volume but our costs are growing linearly. Every time we grow, we need more people. How do we scale without just throwing bodies at problems?”

How to Pitch the $83K ROI

Lead with: “This creates a scalable foundation that grows with the business”

Emphasize: Manual processes don’t scale; automated infrastructure does

Frame it as: “As patient volume grows, this doesn’t require adding analysts”

The win: Operational leverage and future-proofing

The Conversation

“Right now, this automation saves 375 hours and $83K over five years. That’s the immediate return. But here’s the strategic value for operations:

As your patient volume grows 20-30% over the next few years, the manual process would require adding 1-2 FTEs to keep up. The automated solution scales without incremental labor costs. You get operational leverage—your capacity grows without your costs growing proportionally.

This isn’t just about saving money on one report. It’s about building a scalable operational foundation. It’s proof that we can systematically identify inefficiency, automate it, and create capacity for growth. And it’s a model we can replicate across other departments.”

Questions They’ll Ask

“How does this fit into our broader operational strategy?”
→ This is the foundation for systematic process improvement. We identify high-value, repeatable processes and automate them. This is the first domino—it proves the model works.

“Can this approach be replicated in other departments?”
→ Absolutely. The framework is repeatable: document the manual process, calculate the time/cost, build the automation, measure the impact. Finance, clinical operations, HR—anywhere there’s manual reporting, this model applies.

“What’s the change management plan?”
→ Phased rollout with parallel processes during transition. Training and documentation. Clear communication about what’s changing and why. We’re not just building technology—we’re managing the change process and documenting everything.

Persona 6: President/CEO

What they care about:

• Strategic positioning and competitive advantage

• Organizational capability building

• Culture and employee satisfaction

• Long-term value creation

What keeps them up at night:
“Are we building an organization that can compete in five years? Are we attracting and retaining the right talent? Are we making decisions based on data or gut feel?”

How to Pitch the $83K ROI

Lead with: “This is the foundation for becoming a data-driven organization”

Emphasize: Building institutional capability, not just solving one problem

Frame it as: “First step in transforming how we use data to compete”

The win: Cultural shift toward efficiency, innovation and definition alignment

The Conversation

“This specific automation saves $83K over five years with a 160% ROI. That’s a solid financial return. But let me tell you the bigger story:

This is how we transform from gut-feel decision-making to data-driven operations. Right now, your VP of Revenue Cycle spends 90 minutes every day on manual data entry. That’s not a revenue cycle problem—it’s a symptom of an organization that hasn’t invested in the infrastructure to leverage data effectively.

This automation is proof we can identify inefficiency, quantify it, and systematically eliminate it. It demonstrates to your team that we’re serious about using technology to align the business with the data. And it creates the foundation for the more strategic initiatives—predictive analytics, operational optimization, growth enablement—that you need to compete long-term.

The 11.6-month payback proves this pencils out financially. But the real return is building the muscle to do this repeatedly across the organization.”

Questions They’ll Ask

“How does this align with our 3-5 year strategy?”
→ This is the foundation for the data infrastructure you’ll need to execute on growth and strategic initiatives. You can’t do predictive analytics without clean, automated data pipelines. This is step one.

“What’s the cultural impact?”
→ It demonstrates commitment to innovation and efficiency. It shows the team you’re investing in tools that make their jobs better, not just squeezing more work out of them. And it positions data as a strategic asset, not just an afterthought.

“What’s next after this?”
→ We’ve identified three additional high-ROI automation opportunities using this same framework. Once we prove this model works, we can scale it systematically across the organization. This is the pilot that unlocks the roadmap.

The Pattern: What Changes, What Stays the Same

Let me make this crystal clear:

What Stays the Same Across All Personas

• The core numbers: $83K savings, 160% ROI, 11.6-month payback

• The math: 375 hours × $72.12/hour

• The conservative approach: Documented assumptions, transparent calculations

• The proof: Time tracking, industry benchmarks, defensible estimates

What Changes

• The opening line: What you lead with in the first 30 seconds

• The emphasis: Efficiency vs. risk vs. scalability vs. strategy

• The framing: Tactical win vs. strategic capability

• The objections you anticipate: Budget vs. disruption vs. attribution

Master this translation, and you’ll stop defending budgets. You’ll start getting handed them.

Your Cheat Sheet: Quick Reference Guide

Here’s your one-page reference for tailoring your pitch:

The Multi-Stakeholder Meeting: When They’re All in the Room

Often, you’re not pitching to one persona—you’re pitching to multiple executives at once. Here’s how to navigate it:

Opening (30 seconds)

Start with the universal truth that everyone cares about:

“We’re proposing a $26,500 investment in automated reporting that generates $83,225 in savings over five years—a 160% ROI with an 11.6-month payback period.”

Then Layer Based on Who’s Present

If the CFO is in the room: Dive into the financial details first. Show the year-by-year breakdown. Emphasize the conservative assumptions.

If the COO is in the room: Pivot to scalability next. Talk about operational leverage and how this creates capacity for growth.

If the CEO is in the room: Connect to strategic vision last. Frame this as the foundation for becoming a data-driven organization.

If IT is in the room: Address security and maintenance concerns proactively. Don’t wait for them to ask.

Close with the Universal Truth

“This pays for itself in under a year. After that, it’s pure value creation. And it’s a proven model we can replicate across other high-impact areas.”

Common Objections and How to Handle Them

Regardless of who you’re pitching to, you’ll face similar objections. Here’s how to handle them without sounding defensive:

“We don’t have budget right now”

Don’t say: “But this is really important!”

Do say: “The 11.6-month payback means this effectively funds itself. And we can phase the implementation to minimize up-front costs if needed. What does your budget timeline look like?”

“Our people like the manual process / They’re comfortable with Excel”

Don’t say: “They’re wasting time!”

Do say: “I hear you. And we’re not taking away their ability to use Excel. We’re just eliminating the 375 hours per year they spend copying and pasting data into it. What if instead of spending 90 minutes compiling the report, they spent that time analyzing it?”

“What if it breaks? What if the automation fails?”

Don’t say: “It won’t break, don’t worry!”

Do say: “Great question. That’s why we’ll run the automated and manual processes in parallel for 30 days. Nothing changes until you’re confident. Plus, we’ll provide documented runbooks and clear SLAs for ongoing support.”

“We tried automation before and it failed”

Don’t say: “This time will be different, trust me!”

Do say: “Tell me more about what happened.” [Listen carefully.] “Here’s how we’re specifically addressing that: [detailed mitigation plan based on what they tell you].”

“Can we start smaller? This feels like a big investment”

Don’t say: “No, we need to do it all at once!”

Do say: “Absolutely. We can phase this. Start with one report, prove the ROI, then expand. Keep in mind that smaller scope means proportionally smaller savings, but if you want to pilot it first, we can structure it that way. What would a pilot look like to you?”

“How do we know this will actually save 375 hours?”

Don’t say: “Just trust the math!”

Do say: “We documented the current process by talking with the stakeholders that lead this process. We’re using conservative assumptions—if anything, we’re understating the benefit. But we can build in checkpoints to measure actual time savings if you want validation.”

The One Thing You Must Do Before Any Pitch

Before you walk into any meeting, answer this question:

“Who in this room has veto power, and what’s their biggest fear?”

Because that person—whether it’s the CFO worried about budget, the COO worried about change management, or the IT director worried about complexity—is the one whose objection will kill your project.

Tailor your pitch to address their fear first. Lead with what matters most to them. Then layer in the benefits for everyone else.

Don’t bury the objection. Address it head-on in your opening.

If the CFO has veto power: Lead with ROI and payback period.
If IT has veto power: Lead with risk reduction and minimal maintenance.
If Operations has veto power: Lead with minimal disruption and parallel processes.

Wrapping Up: The Two-Part Framework

Over these two weeks, I’ve given you the complete playbook for proving data ROI in healthcare:

Part 1: Calculate It

• Time manual processes

• Convert time to labor costs

• Factor in implementation costs

• Calculate net savings and payback period

• Project long-term ROI

Part 2: Communicate It

• Identify your audience

• Lead with what they care about most

• Emphasize the benefits relevant to their role

• Anticipate and address their specific objections

• Frame the same ROI six different ways

The reality: You’ll get better at both of these with practice. Your first ROI calculation will take hours. Your tenth will take 20 minutes. Your first stakeholder pitch will feel awkward. Your twentieth will feel natural.

But the framework doesn’t change. Time savings is your foundation. Clear communication is your delivery mechanism. Conservative assumptions are your credibility.

Stick to these principles, and you’ll build trust. Build trust, and you’ll get budget. Get budget, and you’ll build the infrastructure that eventually does unlock revenue generation.

We started this series by saying “money talks.” That’s still true. But the language money speaks changes depending on who’s listening.

Learn to translate, and you’ll never struggle to prove your value again.

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.

Last week, I promised we’d dive into Part 2 of our ROI series—building the complete business case and calculating total value creation. However, between Kickstart Ohio and other conferences this week, I didn’t carve out writing time until Sunday afternoon. Rather than rush through something as important as ROI frameworks, I’m shifting that to next week so I can give it the attention it deserves. Today’s issue focuses on something equally valuable: the lessons learned from being in the trenches with fellow entrepreneurs this week.

This week’s issue is not on data strategy, engineering, and healthcare. My goal is to capture the passion, connection, and productivity we had at the Kickstart Ohio 2025 entrepreneurship & technology event hosted at Ohio Wesleyan University this past week.

I’m diving into 3 key takeaways as a data entrepreneur attending what I consider to be the best technology event in Ohio this year. But first, a little background into the conference itself…

This year was the conference’s first go in the Columbus area. It was cool being part of something new. What helped was that the headline speaker was Steve Wozniak, the Co-Founder of Apple. Naturally, there was a lot of hype leading up to this event throughout the Columbus tech community.

Per the website (kickstartohio.com), the event’s goal was to capture the innovation, entrepreneurship, and community growth in Ohio. I felt that it did all of these things, but in a way that was intentional, intimate and approachable. Shout out to Ohio Wesleyan University for the great venue to balance networking, working sessions and doing client work in between.

With that being said, here are my 3 key takeaways as the founder of a high growth data consulting agency specialized in healthcare.

1. Number of attendees does not determine conference quality—the people present do.

With respect to industry, I’ve been to some of the largest conferences in the world. The National Restaurant Association Show 2024 in Chicago and RoofCon 2024 in Orlando. Filled with mainstream vendors and a large turnout, it felt hard to experience quality time with the presenters and leaders at these conferences.

Kickstart Ohio was much different. I think this being the first one helped in that regard. Each session was filled with maybe 20-30 people (besides Wozniak’s fireside chat). This made it easier to ask questions in the crowd. Furthermore, you felt strongly connected to the people around you.

The same faces were there each day, creating a circular energy that was felt each time you saw each other. It’s almost like we were in the same cohort, but instead of academic classes, we were rallying around all of our entrepreneurial characteristics and uniqueness.

I know for a fact I’ve made some connections that will go well beyond this conference. I even explored some deeply personal growth development conversations with other entrepreneurs.

We as entrepreneurs are often our own therapists, so getting to chat about our strengths and weaknesses, being vulnerable, and staying authentic, drives more self-awareness for our own lives and enhances those around us. It was a beautiful harmony of growth felt on both sides of the conversation. You also realize you’re not alone as a business owner—and that goes a long way.

2. Tag team the conference with mentors and people that push you.

Events are a huge source of lead generation. Attending with a mentor or people you routinely network with gets you into more conversations. Instead of having to brute force your way into every conversation, the introductions that are made if you have a mentor or connection “slingshot” you into a conversation are invaluable.

It creates immediate rapport and allows you to introduce yourself seamlessly. You find yourself talking to more people that you may not have gone up to without this dynamic. Furthermore, it makes the experience more enjoyable because you establish “your tribe” within the sea of other tech professionals and entrepreneurs.

3. Hearing a legend’s story reminds you why you started.

Steve Wozniak’s fireside chat was the highlight of the conference, and not for the reasons you might expect. Yes, he co-founded Apple. Yes, he revolutionized personal computing. But what struck me most wasn’t his accomplishments—it was his clarity about who he is and what drives him.

Three things stood out from his conversation:

First, Wozniak knows exactly who he is. That self-awareness allowed him to do his best work. He wasn’t trying to be Steve Jobs. He wasn’t trying to be a CEO or a business mogul. He was an engineer who loved solving problems, and he leaned fully into that identity. There’s power in knowing your lane and owning it completely.

Second, his humility was disarming. Here’s someone who changed the world, and he carried himself like your favorite uncle at a family gathering. He was generous with his time, genuinely interested in the people around him, and approachable in a way that made you forget you were talking to a tech legend. It reminded me that ego is optional—even at the highest levels of success.

Third, and most importantly, money has never been his priority. Wozniak built technology because he genuinely loves solving problems for people. The financial success was a byproduct, not the goal. In a room full of entrepreneurs thinking about growth, funding, and exits, this was a powerful reset. It brought me back to why I started my business in the first place—not to chase a number, but to solve real problems for healthcare organizations using data.

Sitting in that room, listening to Woz talk about building the Apple I and II not for profit but for the joy of creation, I felt a reconnection to my own “why.” We get so caught up in the hustle—the client deliverables, the revenue targets, the next milestone—that we forget the spark that started it all.

Sometimes you need to hear from someone who fundamentally changed an industry to remember: the best work comes from loving what you do and staying true to who you are.

The Energy You Take With You

Conferences aren’t just about the sessions you attend or the business cards you collect. They’re about the energy you absorb and carry forward.

Kickstart Ohio reminded me that entrepreneurship doesn’t have to be a lonely grind. There’s a community of people building, struggling, winning, and learning right alongside you. The intimate setting, the recurring faces, the vulnerable conversations, and yes, the wisdom from a legend who helped birth the personal computer era—it all compounds into something bigger than any single takeaway.

I’m heading back to client work this week with a clearer sense of purpose, deeper relationships, and a reminder that the best technology comes from people who genuinely care about solving problems.

If you’re an entrepreneur in Ohio, mark your calendar for Kickstart Ohio 2026. I’ll see you there.

📬 COMING NEXT WEEK: PART 2

Building the Business Case - From Costs to Value Creation

Next week, we move beyond time savings to calculate total value and present it to different stakeholders. We’ll walk through the complete ROI formula and explore value beyond time savings—faster decision-making, reduced turnover costs, and scalability benefits. Plus, I’ll show you how to frame ROI differently for your CFO vs. COO vs. VP of Operations.

Christian Steinert is the founder of Steinert Analytics, helping healthcare & roofing 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.

When beginning a data initiative, what is the objective of your company/client?

Where are they in the data maturity lifecycle?

What was the initial pain that brought you on board to help?

How is data being used/going to be used as a growth driver for the company?

What is a solution that speaks to a significant problem that ties directly to the company’s value chain?

These are all foundational questions to ask. When speaking to executive leadership, money talks. The deeper I’ve gotten into data strategy consulting at Steinert Analytics, the more I’ve needed to understand the financial ROI of what we’re doing.

Without hard numbers, the intangible benefits of data WILL NOT resonate with leadership. Those are layered on as icing after you bake the cake. The cake is your ability to calculate and articulate the financial value of what data unlocks for your organization.

In this three part mini series, for the next three weeks I’m taking you through our process for calculating the financial ROI of a given data solution. We’re going to keep the focus on one data product/deliverable. My goal is to keep this straight-forward and actionable for you. I’m pulling from my experience as a healthcare-focused Chief Data Strategist & Consultant. There’s no bull shitting here.

I’ll be giving you the inside details on what I’ve done and how it’s been received so far. I’m open to further discussion, feedback and improvements as we’re all data leaders trying to tackle this most difficult hurdle: Proving our value as a team.

Back to the Questions & Background Context

I opened with those five foundational questions. Why? Because high value data solutions always start with questions. As the strategic enabler of a business, the data leader needs to focus on solving a stakeholder’s problems.

I’ll share my responses on each of these and detail what I’ve seen with our clients at Steinert Analytics.

1. When beginning a data initiative, what is the objective of your company/client?

Is the company greenfield, or do they already have an existing reporting ecosystem (brownfield)? This is critical to understand. If the company isn’t currently doing reporting, why is that? Maybe it’s a smaller company that is satisfied with their current analytics mechanisms. For example, a small residential roofing company probably doesn’t need a fully scaled reporting practice. If you’re a data consultant, these might not be the best prospects for you. However, if it’s a $100M+ revenue medical company, you likely have far more people and departments that generate (a lot of) data - from multiple sources.

One of the biggest issues I’ve seen for an immature data lifecycle company is inconsistent values for the same metric across reports/departments. This is a big pain point for our ideal customer at Steinert Analytics.

2. Where are they in the data maturity lifecycle?

Similar to my above response, the maturity of their data practice will determine how you’re able to help them.

For an immature org, baselining their descriptive (what happened, when did it happen) reporting with consistent, quality data is a critical pain point.

A more mature data organization is looking to get enriching insights from their data. Instead of just descriptive and diagnostic reporting that helps make accurate, cost-effective decisions, they’re wanting to leverage data as a growth driver.

Can we predict what marketing campaigns will grow sales by 10% in Q4 2025 by looking at our historical customer data?

Are we able to leverage historical patient data in a HIPAA compliant way that enables the prediction of certain diseases for a particular patient profile?

You go from using data to run your company efficiently, thus saving money - to pulling data’s levers as a strategic growth driver for your business that grows customers and enhances the product/service experience.

3. What was the initial pain that brought you on board to help?

Always go back to this. It helps to see how your organization’s needs have evolved. The original issue is usually surface level. The more conversations you have unveils a new elephant in the room.

For example, when I started with one of our largest clients we were trying to alleviate the burden of their on premise data infrastructure by migrating to the cloud. Although that was important to limit IT labor hours, the real need surfaced much later. After our Proof of Concept phase, we got an inside perspective that the company’s entire financial reporting practice runs on manual processes.

Pulling from ten different legacy Power BI reports (directly hitting the EHR) and native EHR exports right in the UI, a centralized Excel spreadsheet was the source of truth. Hard coding numbers manually into the spreadsheet from all these sources, with no level of automation or standardized definition around each metric’s logic. There was no timing consistency on when the metrics would be updated daily.

4. How is data being used/going to be used as a growth driver for the company?

Keep your sights on this. I’d say the majority of our clients are too immature for discussions around data as a growth driver. It’s currently all about cost savings, efficiency and risk aversion, especially in the conservative healthcare industry.

It’s good to pepper this perspective in as icing on the cake you’ve baked early on in a company’s data maturity journey.

5. What is a solution that speaks to a significant problem that ties directly to the company’s value chain?

Pulling from an elite data architect and someone I admire, Ergest Xheblati’s playbook, always start with data solutions closest to a company’s value chain. That is, build data solutions that tie directly in with how the company makes money.

Why? This is the fastest way to gain traction with a CEO and how the data solution you’re building aids the company in managing their cash flow and profit (especially big in healthcare revenue cycle management!).

Start with Time Savings

Like I said, this article is designed to be specific and straight-forward. Sticking with the automation of a daily revenue cycle financial report, how do you begin to quantify this?

Start with time to dollars saved.

For one of our healthcare clients, we automated their daily revenue cycle management reporting. Before our solution, the VP of Revenue Cycle spent 90 minutes every single day manually pulling data from multiple Power BI reports and native EHR exports, then hard-coding numbers into a centralized Excel spreadsheet.

Ninety minutes. Every. Single. Day.

Dollar numbers are for this use case’s examples only. We cannot disclose actual dollar figures of our clients. But it’s ballparked well.

Pro Tip: Use an LLM of your choice for the below steps. I use Claude Pro’s Sonnet 4.5.

Here’s how we calculated the financial impact:

Step 1: Quantify the Time Investment

First, document the current state with precision:

Daily time spent: 1.5 hours

Working days per year: 250 days (accounting for holidays, PTO, weekends)

Total annual hours spent on this task: 375 hours

That’s over nine full workweeks spent on manual data entry and report compilation.

Step 2: Convert Time to Dollar Cost

Next, calculate what that time actually costs the organization. For our client’s VP of Revenue Cycle:

Annual working hours: 2,080 hours

VP salary converted to hourly rate: $72.12/hour

Annual labor cost of manual reporting: 375 hours × $72.12 = $27,045

That’s $27,045 per year spent on a process that could be automated. And this is just one person. If you have multiple team members touching this process, the cost multiplies quickly.

Step 3: Factor in Your Implementation Costs

Now here’s where consultants often get squeamish - you need to be honest about what this will cost to build:

Initial Investment:

• Development time: $18,000 (6 weeks from our consulting package)

• Annual technology costs: $8,500 (cloud infrastructure, Power BI licenses, API costs)

• Total first-year investment: $26,500

Yes, the first year you’re in the red. And that’s okay. This is where you need to walk leadership through the payback timeline.

Step 4: Calculate Net Annual Savings

After year one, here’s what the financial picture looks like:

Annual labor savings: $27,045

Annual technology costs: $8,500

Net annual savings: $18,545

Step 5: Determine Payback Period

This is the number executives care about most - when do we break even?

Payback period = Initial development cost ÷ Net annual savings
Payback period = $18,000 ÷ $18,545 = 0.97 years (roughly 11.6 months)

After less than a year, you’ve recovered your initial investment. Every year after that is pure value creation.

Step 6: Project Long-Term ROI

Don’t stop at year two. Show them the five-year picture:

5-Year Financial Projection:

• Total investment: $52,000 ($18,000 initial + $34,000 in ongoing tech costs over 4 years)

• Total labor savings: $135,225 (5 years of VP time saved)

• Net 5-year benefit: $83,225

• 5-Year ROI: 160%

The Reality Check

Here’s what this calculation doesn’t capture, but you should mention to leadership:

Capacity Created: That VP now has 375 hours per year to focus on strategic revenue cycle initiatives instead of manual data entry. What’s the value of their expertise applied to reducing days in A/R or improving denial management? That’s opportunity cost recovered.

Error Reduction: Manual processes introduce errors. Every mistake in financial reporting requires correction time and can lead to poor decision-making. Automation eliminates the human error factor.

Scalability: As the organization grows, the manual process would require more FTEs. The automated solution scales without additional labor costs.

Employee Satisfaction: Nobody got into healthcare leadership to spend 90 minutes every day copying and pasting numbers into Excel. Reducing soul-crushing manual work improves retention and morale.

But remember - lead with the hard numbers. The intangible benefits are the icing, not the cake.

Wrapping Up Part 1

The foundation of any ROI calculation for data products starts with documenting what’s broken and what it costs right now. Time tracking is your best friend here. Before you automate anything, before you build anything, you need to establish your baseline metrics:

1. How many hours per week/month/year are being spent on this process?

2. What is the fully-loaded cost of those hours?

3. What will it cost to build and maintain the solution?

4. How long until we break even?

5. What’s the long-term financial benefit?

For our healthcare client, we could walk into the CFO’s office and say: “We’re going to spend $26,500 in year one to save you $27,045 annually in labor costs. You’ll break even in 11.6 months, and over five years you’ll see a net benefit of $83,225 with a 160% ROI. Plus, your VP of Revenue Cycle gets 375 hours back per year to focus on strategic initiatives that actually drive revenue.”

That’s a conversation executives understand.

📬 COMING NEXT WEEK: PART 2

Building the Business Case - From Costs to Value Creation

Next week, we move beyond time savings to calculate total value and present it to different stakeholders. We’ll walk through the complete ROI formula and explore value beyond time savings—faster decision-making, reduced turnover costs, and scalability benefits. Plus, I’ll show you how to frame ROI differently for your CFO vs. COO vs. VP of Operations.

Until then, start documenting your baseline metrics. Time those manual processes. Calculate those hourly costs. Build your foundation.

The math doesn’t lie, and neither should we.

Christian Steinert is the founder of Steinert Analytics, helping healthcare & roofing 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.

It was 8 AM on Tuesday, and I had just run a stored procedure that builds the historical financial snapshot ledger for one of our healthcare clients. I crafted a basic SELECT statement and queried the table to check data for 10/7/2025.

Two of our key metrics returned 0.

Not low. Not slightly off. Zero.

My stomach dropped a bit. These metrics are critical for daily executive reporting, and leadership relies on them to make operational decisions. I immediately went into troubleshooting mode.

Could it be the source system? I queried the source directly—data returned perfectly.

Could it be our end tables? I checked our Microsoft Fabric Warehouse table—nothing. Empty results.

Was it a timing issue? Maybe the data hadn’t fully landed yet? I sat there for two minutes, puzzled and scratching my head, watching the clock tick and hoping rows would magically appear.

Then an idea dawned on me. Let’s check the raw lakehouse table.

I queried our bronze layer in the Fabric Lakehouse...and sure enough, complete data. Every single row, sitting there perfectly intact.

Oh boy. Now we had a real mystery.

Finding the Fault Line

I systematically moved through our data architecture, querying each layer. When I hit our middle staging table and ran some basic count analysis, I found it: data was missing. Boom—I’d identified where the fall-off began.

For context, Steinert Analytics operates Microsoft Fabric aligned to a medallion architecture, which I’ve mentioned in previous issues:

• Bronze Layer (Lakehouse): Raw source tables land here with minimal transformation

• Silver Layer (Warehouse): Light transformation and cleanup—our validated staging area

• Gold Layer (Warehouse): Curated tables for reporting that end users interact with

Something was breaking between our bronze layer in the Lakehouse and our silver/gold layers in the Warehouse. And it wasn’t just a few rows. For our larger tables—those with over a million records—we were seeing a fall-off of hundreds to thousands of rows.

For a healthcare analytics consultancy where accuracy isn’t just important but potentially impacts patient care decisions and financial reporting, this was unacceptable.

Community to the Rescue

Similar to the failed Copy Job pipeline story I shared a few weeks ago, I turned to the r/MicrosoftFabric subreddit community. And once again, they came through.

What I wasn’t aware of—and what Microsoft doesn’t make immediately obvious in their documentation—is that there’s a metadata refresh delay between the Fabric Lakehouse and Fabric Warehouse when loading data.

This delay was causing hundreds to thousands of rows to fall off in our Warehouse silver and gold tables. Not because the data wasn’t there, but because the Warehouse couldn’t “see” it yet.

Obviously a HUGE ISSUE. It meant our gold tables would be delayed in updates, giving leadership untimely or incomplete information on a daily basis. In healthcare, where daily census numbers, financial metrics, and operational KPIs drive real-time decisions, this kind of data lag isn’t just inconvenient—it’s potentially dangerous.

The fix? Implement a forced metadata refresh before loading Lakehouse bronze tables into the Warehouse silver and gold layers.

Let me walk you through the technical details of what’s happening and how we solved it.

The Technical Deep Dive: Understanding Metadata Refresh Delays in Microsoft Fabric

When working with Microsoft Fabric’s lakehouse-to-warehouse architecture, there’s a critical but often overlooked aspect of how data synchronization works: the SQL Analytics Endpoint metadata refresh mechanism.

What’s Actually Happening Behind the Scenes

In Microsoft Fabric, when you load data into a lakehouse, you’re writing files to Delta tables in OneLake. However, the SQL Analytics Endpoint—which provides the warehouse-like querying capability—doesn’t immediately “see” these new files.

According to Microsoft’s documentation, the SQL Analytics Endpoint maintains its own metadata layer that represents the structure and content of your lakehouse tables. Think of it like an index in a book: the content exists, but if the index isn’t updated, you can’t find what you’re looking for.

This metadata layer needs to be explicitly refreshed to recognize new data files that have been added to your Delta tables. Without this refresh, your warehouse queries are essentially looking at a stale snapshot of your data—even though the actual data exists in the lakehouse.

For tables with millions of rows where hundreds or thousands of new records are being added daily, this metadata lag creates a significant data integrity issue. Your bronze layer has complete data, but your silver and gold layers are querying against outdated metadata that doesn’t include the latest file additions.

Why Microsoft Designed It This Way

The metadata refresh mechanism exists for performance optimization. According to Microsoft’s documentation on SQL Analytics Endpoint performance, continuously scanning for new files in large datasets would create significant overhead on the system.

Instead, Fabric uses a pull-based refresh model where metadata updates are triggered either automatically on a schedule or manually via API call. This design trade-off prioritizes query performance over real-time data visibility.

For many analytics workloads—like monthly reporting or historical analysis—this makes perfect sense. But for operational reporting with daily data pipelines where timeliness matters, it creates the exact problem we encountered.

The Solution: Forced Metadata Refresh via Web Activity

The fix involves explicitly calling the Fabric REST API to trigger a metadata refresh before your stored procedures run. This ensures that the SQL Analytics Endpoint has the most current view of your lakehouse data before any transformation or loading occurs.

Here’s how we implemented it in our Data Factory pipelines (shoutout to kmritch on Reddit):

Step 1: Add a Web Activity
Insert a Web Activity into your pipeline before any warehouse operations. This becomes your “metadata refresh checkpoint.”

Step 2: Configure Connection Settings

• Base URI: https://api.fabric.microsoft.com/

• Token Audience URI: https://api.fabric.microsoft.com/

• Authentication: Organizational Account

Step 3: Configure Web Activity Parameters

• Relative URL: v1/workspaces/{WORKSPACEID}/sqlEndpoints/{SQLANALYTICSENDPOINTID}/refreshMetadata

• Method: POST

• Body: {”timeout”:{”timeUnit”:”Seconds”,”value”:”60”}}

• Headers:

  • Name: Content-type

  • Value: application/json

The timeout parameter is important—it tells Fabric how long to wait for the metadata refresh to complete. For our larger tables, 60 seconds proved sufficient, but you may need to adjust based on your data volumes. In testing, we found that tables with 5+ million rows occasionally needed 90 seconds during heavy load periods.

Implementation Considerations

After implementing this solution across all our pipelines, we immediately saw 100% data completeness in our silver and gold tables. However, there are a few considerations worth noting:

Pipeline Duration: Adding the metadata refresh step adds 30-60 seconds to each pipeline run. For our daily batch processes, this is completely acceptable. For real-time or high-frequency pipelines, you’ll need to weigh the latency cost against data completeness requirements.

API Rate Limits: Microsoft Fabric uses throttling to maintain optimal performance and reliability, limiting the number of API calls within a time window per user. When you exceed these limits, Fabric returns an HTTP status code 429 (Too many requests) with a Retry-After header indicating how long to wait before making a new request. If you’re running many concurrent pipelines, you may need to implement retry logic or stagger your pipeline executions to avoid hitting these limits. While Microsoft doesn’t publish specific rate limits for the metadata refresh endpoint, monitoring for 429 responses and implementing appropriate retry logic is a best practice.

Monitoring: I recommend adding logging around the metadata refresh call to track when it completes and capture any failures. This is an area I’m still developing in our infrastructure—we haven’t fully implemented centralized monitoring for these API calls yet. However, given the criticality of data completeness for our healthcare clients, building out proper observability around these metadata refresh operations is next on my roadmap. At minimum, consider adding error handling in your Web Activity that logs failures so you can investigate when pipelines don’t behave as expected.

Cost Implications: While the API call itself is free, the additional pipeline runtime does add minor compute costs. For us, the cost increase was negligible compared to the value of data accuracy.

The Bigger Picture: Lessons for Data Architecture

This issue highlights a fundamental principle in modern data architectures: understanding the consistency model of your platform.

Microsoft Fabric’s lakehouse and warehouse components aren’t operating under strong consistency—there’s an eventual consistency model with the SQL Analytics Endpoint metadata. If you assume immediate consistency (like you might with a traditional database), you’ll run into exactly the problem we experienced.

Key Takeaways for Healthcare Data Consultants

1. Platform Knowledge is Non-Negotiable
You can’t just assume cloud platforms work like on-premises systems. Each has its own quirks, consistency models, and optimization trade-offs. Reading documentation thoroughly—even the boring API reference docs—pays dividends.

2. Test at Scale
This issue only manifested with our larger tables. In development with smaller datasets, everything looked fine. Always test your pipelines with production-scale data volumes before go-live.

3. Community is Your Secret Weapon
The r/MicrosoftFabric community diagnosed this issue in hours. Building relationships with other practitioners in your technology stack accelerates problem-solving exponentially.

4. Implement Defensive Data Engineering
The metadata refresh API call should now be a standard component of any Fabric pipeline that moves data from lakehouse to warehouse. It’s not optional if you need data completeness guarantees—it’s a best practice.

5. Build Monitoring Into Your Roadmap

We don’t yet have automated row count reconciliation checks between our bronze, silver, and gold layers—but this issue made it clear we need them. Manual spot-checking caught this problem, but that’s not scalable or reliable. Building automated data quality checks that alert us when counts don’t match within expected tolerances is a priority for our next phase of infrastructure development. Don’t wait for users to find data issues—invest in monitoring before problems compound.

Where We Are Now

The good news? Once you know about this quirk, the fix is straightforward and reliable. Our pipelines have been running flawlessly since implementation, and we’re confident that our leadership team is getting timely, complete data every single day. You can copy and reuse that same Web activity in all your Fabric Data Factory flows now, too.

More importantly, we’ve documented this solution internally and created a pipeline template that includes the metadata refresh step by default. New projects don’t have to rediscover this issue—we’ve baked the solution into our standard practices.

That’s the hallmark of mature data engineering: learning from issues, documenting solutions, and systematically eliminating entire classes of problems from your future work.

Your Turn

Are you running Microsoft Fabric in production? Have you encountered this metadata refresh issue? I’d love to hear about other Fabric quirks you’ve discovered and how you’ve solved them.

And if you’re experiencing unexplained data completeness issues in your Fabric warehouse, now you know where to look first.

See you next week.

Quick Links:

• Microsoft Fabric SQL Endpoint Metadata Refresh API

• SQL Analytics Endpoint Performance Documentation

• My Reddit Thread on This Issue

Christian Steinert is the founder of Steinert Analytics, helping healthcare & roofing 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.

Not because I’m bad at data consulting—but because I was terrible at understanding cash flow.

Having optimized inflows and outflows of cash is extremely hard to achieve in the early years. Trust me, I know this because I’ve been running my six-figure agency for 3.5 years (2+ years full time) and it’s been a roller coaster.

As a data consulting agency founder, you feel the vision. If you’re serious and have your foot on the gas, you see the movement. However, the progress towards your goals often does not feel real.

Why?

Restricted and delayed cash flow.

If you’re looking to truly start and scale a sustainable data consulting agency in 2025, thinking that this industry and growth moves fast is far from reality. The fabricated reels and glamorized lifestyles of entrepreneurs on Instagram aren’t what it actually looks and feels like.

Last week I shared something vulnerable on LinkedIn about sales cycles, and many have reached out saying they’ve felt this too (post below). The post resonated because it was real—90-day waits, procurement delays, watching bills pile up while contracts sit unsigned. Today I want to pull back the curtain even further.

I want to take you through a detailed dive into my experiences and mindset transformation after over 2 years of riding the entrepreneurship wave and living out these learnings.

Data professionals are naturally risk-averse. My former identity as a data analyst defaulted to the statistical probabilities, logical reasoning and math behind the chance of success. More often than not, I limited myself and what I thought was possible to achieve.

I’ve had to battle the inner voices inside of my head that told me I couldn’t live my true vision in data consulting. I had to overhaul how I think about finances and money, as holding onto my financial upbringing that was so hard-wired into me was slowing me down.

Hopefully my authentic story is able to ignite a spark in you, and give you a little more awareness into maneuvering the consulting battlefield. Maybe this helps you determine if you want to step foot in this wild arena.

Lastly—I’m not saying I have all of this figured out yet. I recognize I’ve only been in this game for about 4 years. My journey is truly just beginning, but I’ve also weathered some storms where most have quit. I owe it to you, my audience, to share these learnings.

The Infatuation Stage

I remember the day I submitted my two week notice to my employer vividly. I was a senior analytics engineer at a Fortune 200 commercial real estate firm. I had just been promoted. From the outside looking in, I had it made.

There were thousands who would’ve given anything to fill the position I held. Serving as the lead data architect of an $80B assets under management data pipeline was no small feat, and I just kissed it all goodbye.

As soon as I hit send, I felt a massive rush of adrenaline. I just jumped off a cliff, and had begun the journey of free falling. I exchanged some warm words with my manager. We both became emotional on a call, but parted ways on incredibly great terms.

I stormed around my apartment for 2 hours cranking the song Blind Fold by Young Dolph (yeah, I enjoy some pretty hardcore rap at the gym or after milestones in business) on repeat.

As I paced my apartment, I envisioned myself cold calling, emailing and meeting executives at events that would lead to closed deals within a few hours to a week…MAX.

My expectation of the sales side of consulting was forged through movies like The Wolf of Wallstreet and Wallstreet movies, as well as having the opportunity to sell cars at 19 years old the summer after my freshman year of college.

I figured, as long as I keep posting LinkedIn content and getting in front of the right people, my customer base would find me.

What I didn’t understand was that I had just entered the arena of Business to Business (B2B) complex sales. This was a whole different level from anything I had sold or content consumed in the past.

Average sales cycles in complex B2B average around 90 days for Steinert Analytics (in my experience and conversations). I’ve heard, speaking with other consultants and competitors, this is a fairly standard timeframe, and one I’ve directly observed as I’ve endured these cycles.

If you’re new to data consulting, know that this isn’t a get rich quick play. “Building it and they will come” mentality will blow you right into no man’s land, staring at an empty deposit bank statement month after month.

Be humble, be aware and begin your inbound and outbound lead generation funnels as soon as you can.

The Journey Into Mentorship and Coaching: A 180 Degree Mindset Shift

Ditch a Corporate Money Mindset

Once I had officially put in my two weeks, I worked closely with a business coach who runs a $10M+ annual revenue roofing company.

One of the biggest takeaways from my work with him is that money is just energy. I had been raised to count every dollar, spend little, and save as much as I could.

These are all incredibly important, but running a business requires cash. And if you’re truly going ALL IN, you need to be prepared for the financial mindset shift that comes with swinging risk using large chunks of coin.

I’ve spent multiple five figures on coaching and marketing in the last 2 years. Was this easy for me to get my head around? No. But sticking to the learnings from that mentor, I was highly motivated and inspired, and deep down knew this was the path I always wanted to walk.

Money is just energy. Money is just energy. Money is just energy. If you sit and stare at it in a bank account, you can’t create the momentum needed to achieve the growth you desire.

My mindset around money is now felt in ways I didn’t expect. I can move around thousands of dollars towards investments that don’t have a guaranteed return now. Seeing those numbers flow in and out of the business account has become like second nature to me.

I don’t say this to flex. I say this because it’s reality. You’ll gradually get more comfortable with the idea that you’re throwing energy at your growth, rather than risking a financial loss. Own it!

Business Growth is Personal Growth

The second half of my mentorship growth journey comes from a gentleman that I met at the end of 2024 and have been working with closely this year.

Yes, he’s extremely tactical when it comes to lead generation and engineering sales systems. However, he’s also unlocked a personal transformation within me. This transformation has allowed me to navigate the inevitable lows of data consulting—the ghost clients, the stalled deals, the months where revenue dips—without spiraling.

Rooted in the teachings of Dan Sullivan’s The Strategic Coach (The Gap and the Gain), this mentor has forced me into the mindset of abundance. Always focus on the Gain in every success, failure and problem that arises when running a data consulting firm.

Here’s what that looks like in practice:

Instead of thinking “I only closed two deals this quarter when I wanted four” (the Gap), I started asking “How did I close two enterprise healthcare deals at 29 when I couldn’t have landed one 18 months ago?” (the Gain).

That reframe changed everything.

The joy of entrepreneurship is not the destination. It’s the journey of who you become and the realization that you’ve gotten so far since starting, it’s incredible to be at the place you’re at right now.

This realization creates alignment and self-actualization. Which I’ve felt an incredible amount of this year. He refers to this as “flow”. Bootstrapping a six-figure consulting company at 27 to leading data modernizations and transformations as a fractional chief data strategist at 29…forever grateful to be in this position! I hope everyone gets to experience this level of satisfaction in their work.

Conclusion

If you’re reading this and you’re on the edge—considering leaving corporate or scaling your own consultancy—know this: it’s harder than you think, slower than you expect, and more transformative than you can imagine.

The gap between where you are and where you want to be? That’s not failure. That’s the game.

We’ll continue this next week. I’m going to break down the different seasons of running a data consulting agency—the feast months, the famine months, and how to survive both. It’s not what social media makes it out to be, and I want to share those realities with you in detail.

I hope this opened your eyes to the realities of cash flow and B2B sales cycles, while giving you a taste for the mental shift I’ve had to undergo in the last 2 years. I truly feel like a changed person in the best of ways. It’s just not easy going through it.

See you next week.

Christian Steinert is the founder of Steinert Analytics, helping healthcare & roofing 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.