The Humble Shift From Data Order-Taker to Thought-Leader

The transformative experience I'm going through as a data consultant

The last few weeks, I’ve gotten transparent on the shortcomings of my consulting journey. Whether it’s failing to speak my mind as an authoritative expert or painting the grander vision of analytics as a revenue driver to clients, these are all experiences that are shaping my data consulting journey.

Each waking day I feel and see the progress. I lay all this out on the line for you to feel the fibers and chemical makeup of the tailored experiences we offer our clients. You’re not going to find a more honest, committed and determined group of data professionals to help you on your journey. Data consulting projects are never easy, and the perseverance required is one of the greatest strengths Steinert Analytics possesses.

As the founder of a data consulting agency with a focus on helping healthcare and roofing companies succeed, I want to ensure I’m shipping the most cutting edge content possible within these industries. Right now, I’ve exhausted a lot of our successes in those spaces thus far. So the last few weeks have been pulling from the ins and outs of succeeding as a consultant.

With that said, I’d like to continue that pattern this week. This time focusing on yet another gap where I see myself improving day by day. I’m excited to show you yet another transparent side of my consulting journey. At Steinert Analytics, Unrivaled Transparency is a core value of ours. I’m giving this to you so when you work with us you know exactly who you’re partnering with and what we’re all about. Here we go…

Tunnel Vision to Deadline vs. The 30,000 Foot View

It’s easy to talk about prioritizing the business in data analytics. You hear this all the time on LinkedIn or right here on Substack. I’ve written endless pieces on the real value of analytics being the business outcomes, not the technology and tools.

Here’s what these types of conversations don’t tell you. In day to day life as a data professional, defaulting to business outcomes over robust technology and tooling solutions is freaking hard (at least in my experience). I think professionals who started their career in consulting have more of a natural default to business outcomes. However, for those that spent an extensive number of years in a large corporation, this default may not be as easy.

Now I know, this all depends on the environment. However, I’m going off LIVED EXPERIENCES. When you’re part of an order-taking data team culture (which is unfortunately common), the focus on business outcome isn’t natural.

Instead, you’re told to build something, to an exact spec in the acceptance criteria of a Jira ticket. With little to no real business exposure on how your solution will actually be used. Oh yeah, and you’re required to have it done in an extremely fast turnaround time.

This environment creates a hyper focus on writing code efficiently and delivering to hit a deadline, without fully understanding WHAT this provides the business. Often, this can lead to logic that does not align with the business rules and incorrect data.

With all that said, my leap into consulting was colossal given some of the environments I had previously worked in. In previous environments, the business value wasn’t glorified. The complexity, cleanliness and efficiency of my code output was. The quantity of dashboards I produced and delivered, rather than the impact they had, was the metric I was measured against to keep my job.

Now as I execute as a consultant, defaulting to a business first mindset is often challenging. Often I’ve felt like I need to prove my SQL skills to a client. Therefore, I put so much emphasis on building “good code” that I forget to question what a specific dataset actually represents and what it accomplishes for the business.

Having gone through some failures, where I delivered technically “good code”, but missed some critical logics due to not fully fleshing out the business intent, has stung me. Although the code was efficient and technically modeled the right way, the data output had inconsistent values to what the business expected due to missing intricate business logic in the code. Is that really good code? From a performance standpoint and general modeling, yes. From it actually being correct and useful? No!

I’ve developed a reminder for myself, and I hope this helps you too on your journey to serving your business stakeholders first.

• Don’t go right into building, study the dataset and ask what it represents - Pause and think.

  • Which department is it for?

  • What business event or detail is it capturing?

  • What outcome do they hope to achieve with this data?

  • List out the KPIs they’re after

• Don’t be afraid to seek clarification from the business, and speak your mind as a consultant on your thoughts about it too.

  • This helps kill the “order-taker” mindset adopted from crappy data teams

  • Represents you as a thought-leading partner that’s here to serve the business

  • I’ve written a Substack on this very topic just a few weeks ago

All that said, defaulting to a business outcome-first mindset in day to day data tasks isn’t always natural. Ditch the notion of order taking completely, and start embracing the fun challenge of relating the data modeling and code logic to what decisions the stakeholders will make and how it will impact the business’s bottom line. In turn, this prevents rework, positions you as a leading partner to your clients, and allows you to serve them in the most effective capacity possible.

If you’re interested in working with a genuine group of healthcare data consultants, committed to learning and growing with their clients, feel free to book a call with me here. Otherwise, feel free to reach out to me on LinkedIn.

Until next week, take care. I look forward to hearing your thoughts. :)