Christian Steinert's Linkedin Analytics

I've been in the data space for 6.5+ years. Here's the top 10 mistakes I’ve made: - Developed before fully understanding the acceptance criteria and end goal - Took too long to deliver value out of the gate - Built data models without aligning with end-users - Created rigid semantic modeling with no flexibility for data pipeline updates - Failed to speak up about poor data warehousing design plans - Deployed to production without first reviewing with my team - Ignored proper data governance until it was too late - Learned Python before doubling down on SQL and a BI tool - Tried to develop everything asked for instead of breaking the scope down into manageable parts - Assumed trust from a product owner before we had delivered real value If you're not making mistakes, you're not trying anything new. We need them for our growth. Own them, grow from them, and keep pushing forward. LFG 🔥 ♻️ Share this to help someone else in your network. Follow me → Christian Steinert for more on data architecture and BI insights.

Data architecture paralysis? A challenging balance to strike no doubt. It's easy to feel pulled in 4,000 directions when architecting a new data stack. There could be multiple solutions for a given client. A few core considerations 1. What is their long term goal with analytics? If they just plan on keeping things status quo with a few batch loads daily, robust solutions like Databricks may be overkill. 2. What is their team structure? If they only have one or two dedicated team members, get an understanding of their skillsets. Simplify as much as possible to reduce additional set-up, customization, and maintenance. 3. How much data and how complex? This is critical for estimating the RAM you'll need to select when scoping an estimated cost on a given stack. 4. What does their budget look like? Maybe you want to consider a reserved capacity pricing instead of pay as you go. This reduces risk for unexpected strain on their budget that results from computation. Or you're confident in optimization of a specific data warehouse (*cough* Snowflake) and can get their pay as you go spend to a minimum. Keep a few of these higher level pieces in mind when selecting a tech stack. There's no one size fits all solution in data infrastructure. Understand their current state, and architect aligned to their budget and long term goals. Keeping these in mind helps to simplify and moves the needle towards obtaining an ROI with data analytics. What others would you add?

I’ve delivered 10+ critical BI data pipelines over the past 5 years. 5 questions to ask before building a data pipeline: (The 3rd one doesn't get asked enough!) 1. What business outcome will this pipeline support? → Understand the real impact it’s supposed to drive. A pipeline without purpose is just extra complexity. 2. How is data handled today without this pipeline? → Compare the current processes to determine if the pipeline is a necessity or just “nice to have.” 3. What happens if this pipeline isn’t built? → Measure the urgency and importance by gauging the consequences of not having it. 4. Are we optimizing for scalability or speed? → Knowing the trade-offs helps you design better. Speed might sacrifice long-term scalability. 5. Is there a simpler solution? → Sometimes a full pipeline is overkill. Consider if there’s a more straightforward way to achieve the same outcome. The right questions lead to solutions that matter. Avoid building pipelines just for the sake of it. Are there any other questions you'd ask?

In 2025, you're not just a data person as a data person. Companies demand that data people get closer to the business's source workflows. As a consultant, this is especially true. Want to help a company increase sales? Lean into their CRM and help them at the source first.

So many industries are behind... (specifically in home services) 🏠 There's a better solution than Excel. I know, your feel good rows and columns are convenient and cheap. However, managing your core KPIs in a spreadsheet creates unnecessary complexity. Your CEO doesn't want to burn time lining up metrics with row-level details. Leave the spreadsheets to your accountant. Instead, leverage dashboards and visual best practices for executive reports. This allows them to obtain profitable insights faster, reading less and uncovering more. Any roofers interested in seeing a demo of RoofSight, our roofing analytics platform? DM me.

Confession: I was trained to think about analytics wrong. (And you might've been too) The mindset you approach data analytics with will determine how quickly you make an impact. The common mindset that's pushed is "infrastructure first, analytics second." But here’s the problem: You're losing valuable time if you wait until your infrastructure is fully built and your data pipelines are all polished. In the meantime, you're not showing any value to your stakeholders, and trust starts to erode. The trick is being able to show value immediately. You don’t need everything to be perfect from the start. You can get savvy and scrappy with the data you already have. Use: - Ready-made data - Third-party datasets - Out-of-the-box tools Anything that can help you uncover insights right away. For example, you can leverage tools like Google Analytics or Google Search Console to quickly create insightful reports in marketing analytics. You’re not stuck waiting for a complex data infrastructure to be built. Instead, you’re able to immediately deliver value by showing how users are interacting with your client’s website and brand. TLDR: Stop overvaluing infrastructure. Start focusing on actionable insights and show value immediately.

Can a semantic layer be overkill? (This is coming from a Looker developer) Depending on your org's needs and data tooling suite, it might be. Learn when a semantic layer is either necessary or not in issue 5 of Rooftop Insights. Out now. Link in the comments. ⬇️

Conducting a data audit is challenging. Recently, I worked on a data migration audit for a large healthcare company. Here are 3 learnings I experienced... 𝟏. 𝐃𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐢𝐬 𝐤𝐞𝐲 When starting a migration, documenting all objects to include is critical. Not only for project management, but also to baseline your understanding of the environment. 𝟐. 𝐄𝐦𝐛𝐫𝐚𝐜𝐞 𝐅𝐢𝐧𝐎𝐩𝐬 Stealing from Joe Reis's playbook in Fundamentals of Data Engineering, know what the costs are for each data architecture option. Having hard cost estimates is a huge piece when articulating solutions to stakeholders. Spend time dilligently researching and estimating, even if you're not 100% sure what the computation and storage needs are. Explain your rationale to your stakeholder. 𝟑. 𝐊𝐞𝐞𝐩 𝐭𝐡𝐞 𝐏𝐫𝐞𝐬𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐃𝐢𝐬𝐜𝐮𝐬𝐬𝐢𝐨𝐧-𝐛𝐚𝐬𝐞𝐝 Consulting isn't about knowing the answer all the time. Stakeholders appreciate when you're able provide a recommendation, justify it, and keep the conversation going. Mutually come to a path forward. Selecting a modern data architecture is a nuanced, complex, and difficult decision. There is not one right answer. Keep the dialogue going between your stakeholder and other technical people. Consultant to client relationships are more of a partnership than anything else. These steps enabled us to decide on the most cost effective architecture for our client's needs. This should save them ~$120,000 in labor costs annually. What have you learned from conducting data audits?

Is AI taking your job? Last year we were honored to have former Fortune 20 data science exec and CTO of NeuZeit Mike Alvarez on our show. Staying relevant is about using AI in your daily workflows. Don't fear it, adapt!

Here's the problem with AI... (and it's not the hype cycle) Companies will struggle to keep up. How do I know this? Just look to the past. The shift to the cloud created waves. As a consultant in SMB, many are still on-prem. Instead of thinking about AI as an all in one... Use the tools that solve your clients problems. I'm not convinced AI will solve every problem in 10 years. Especially for companies that are slower to adopt. These companies need trustworthy and skilled humans. Not a bunch of AI tools. See the bigger picture. Be a data professional that leaders can trust and watch your value climb. Do you agree or disagree? Comment below. ⬇️

If you want to win with data, forget the tech talk. (this is what I remind myself every morning when I come on here to post) Executives don't care about the technical intricacies of data warehouses or complex models. What they care about is what data can do for them: ✔️ How does it impact their bottom line? ✔️ Can it identify new revenue streams? ✔️ Does it give them a competitive advantage? At the end of the day, it’s about delivering insights that drive growth and profit. Focus on the results, not the infrastructure. That’s what moves the needle. ----- Did you enjoy this content? Hit the follow button on my profile and turn on post notifications to be notified whenever I publish 🔔

Data architecture can sound overwhelming... But it doesn't have to be! These are the essentials you must understand to drive value as a business executive: (Without getting lost in the technical jargon) - 𝗗𝗮𝘁𝗮 𝗽𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀. These ensure data flows smoothly between systems - 𝗗𝗮𝘁𝗮 𝗹𝗮𝗸𝗲𝘀 𝗮𝗻𝗱 𝘄𝗮𝗿𝗲𝗵𝗼𝘂𝘀𝗲𝘀. Think of these as the storage solutions for your structured and unstructured data. - 𝗘𝗧𝗟 𝗽𝗿𝗼𝗰𝗲𝘀𝘀𝗲𝘀. Extract, Transform, Load - this is how you prepare data for actionable insights. Getting these elements to work in harmony is how you can unlock: > Real-time analytics > Improved decisions that are backed by data > Long-term growth What other concepts should I simplify? Let me know in the comments.

Us data professionals were full of s*** 💩... The hype of 2015-2022 made us entitled. High pay, big titles, and flexing the sexiest job of the 21st century. We shot ourselves in the foot, and from 2023 - present we've been paying the consequences... Failed projects with - Wrong data. Slow performance. Missed expectations. Pissed off executives. All this to say, I'm stoked about the shift left wave. Shifting left does not have to be working with source system code tied to data generation. Study the workflows of the departments you serve. Become intimately familiar with their CRM or asset management software and business processes. Test inputs to see what data is generated. Wear a problem solving hat, not just a data problem solving hat. We're recouping for the failures from 2015-2022 by shifting left. You'll start to be seen as a partner to your stakeholders rather than an IT cost center. Now let me go bike off my last 7 years of frustration in the field. 🚲

Data engineers don't help BI. (and this can lead to poor outcomes) In enterprise teams, the divide between data engineering and BI is blurry. I've seen far too often the BI team owning the bulk of data transforms and modeling at the source. No effort is put in to understand the source system and workflows to model data at "the far left" by data engineers. Data engineers are more comfortable configuring Airflow jobs and simply moving the data. This leads to team misalignment and frustrations from management... It slows down progress data teams are trying to make when doing advanced projects. Now don't get me wrong, I don't think data engineers aren't capable. I just think data teams are so bogged down.... Tasks can shift and shape to the capacity of the different areas of a data team when not defined. That's why having a defined, documented and communicated framework for data teams is crucial. Deploy this framework, and watch your data teams improve efficiency, reduce mistakes, duplicative efforts, and teamwork. I detail all of this in issue 7 of my newsletter, Rooftop Insights. This is based entirely off what I've seen in the field. Do you agree? Link below. ⬇️

We've been duped. (and not by the AI hype) I had a great conversation with a fellow data consultant about productization in lagging industries on Thursday. The topic was about the over engineering of data products by data nerds. The obsession to implement, market and sell AI and other fancy features is real. It can feel like the simple data solutions aren't worth productizing. However, after running through my MVP data product in the roofing space... 🏠 The value is evident with simple data solutions in lagging industries. (check the comments for my Substack case study link) At the end of the day, specific people will buy your product if it solves their problems. Furthermore, simple solutions can scale well as data products (think turnkey). What is your take on simple products?

One of the biggest lessons consulting in the data space has taught me? 𝗔𝗱𝗮𝗽𝘁𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗯𝗲𝗮𝘁𝘀 𝗲𝘅𝗽𝗲𝗿𝘁𝗶𝘀𝗲 𝗲𝘃𝗲𝗿𝘆 𝘁𝗶𝗺𝗲. Don't get me wrong, deep industry knowledge is important. But the most valuable skill I’ve developed is the ability to adjust on the fly. Each client is different; what worked in one scenario may not work in the next. Here’s what consulting has reinforced for me: 1️⃣ 𝗦𝘁𝗮𝘆 𝗰𝘂𝗿𝗶𝗼𝘂𝘀 - Asking the right questions often leads to better insights than coming in with pre-set answers. 2️⃣ 𝗦𝘁𝗮𝘆 𝗳𝗹𝗲𝘅𝗶𝗯𝗹𝗲 - No matter how much experience you have, be ready to pivot and adapt based on the client’s unique situation. 3️⃣ 𝗦𝘁𝗮𝘆 𝗵𝘂𝗺𝗯𝗹𝗲 - Every client engagement is a learning opportunity. The best consultants listen as much as they advise. Key takeaway: Consulting is about more than expertise. ... It’s about being a flexible problem-solver. P.S. What’s the most important lesson you’ve learned from your consulting experience?

Overcomplicating data architecture sucks. (especially going from on-prem to cloud) Recently, I've been modernizing a $40M revenue healthcare company's data stack. There are so many components to consider. 💠 Source systems 💠Current data stack 💠Data lake 💠Data lakehouse 💠Data warehouse 💠Semantic layers 💠BI tools Blah blah blah. I'm finding the best data architectures are the simplest when starting from scratch. Overcomplicating becomes easy when multiple minds are selecting the approach. Some like Azure/Fabric, some like Snowflake, some like GCP/BigQuery... It's easy to think you need to mix and match tools to satisfy your team and client's skill familiarity (aka Azure Data Factory (ADF) > Snowflake...like why?). But I've learned it's best to ask the question - what is the simplest to set up and maintain? This leads to an architecture that is cost effective, low maintenance, and able to be used by everyone. Don't just select tools based on your team and client's comfort level. In our ADF > Snowflake example featured below... 𝗜𝘁'𝘀 𝘂𝗻𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝗶𝗹𝘆 𝗰𝗼𝗺𝗽𝗹𝗲𝘅. We originally clung to ADF due to our client's familiarity with Microsoft. We could simplify and use an ETL tool like Keboola or Airbyte instead. How do you approach modern data architecture when building from scratch?

Data architecture trends I'm seeing this year (and no, I'm not including anything AI) 1. Shifting Left All the buzz recently, shifting left is a concept close to my heart. I've had countless experiences not getting enough upstream exposure as a data engineer. This made my job extremely difficult and unimpactful. It's time to own data generation and APIs at the source. Work with stakeholders to understand their workflows. Deep-dive to understand source system code and how it influences the data generated. Data engineers have spent years blaming data quality and yelling "garbage in, garbage out" from the rooftops. Now it's our time to DO something about it. 2. Data Platform Unification With the hype of Microsoft Fabric, I'd be remiss if I didn't include this on the list. Being a Keboola Certified implementation partner, I'm privy to pushing fully managed data platforms onto early data teams. The unification increases data governance, cataloguing, and ease of use, which allows data teams to focus on the tasks that actually drive profit, not rack up costs. 3. Data Observability After thirty plus conversations with IT & Analytics execs, it's clear that slow time to delivery and high TCO are a real issue with the modern data stack. Data observability deserves a lot more attention than it's been getting. It's made me realize the criticality of tools like Orchestra (also a partner) for getting stakeholders insights they can trust quickly and reliably. What do you think? Are there any data architecture trends you'd add to this list as the year continues?

A must-have skill in Google Cloud... (and it's not Vertex AI) Explaining the difference between Looker and Looker Studio to prospects & clients. The unlock is huge. 🤯

My thoughts on full-time vs. consulting. (a few lived experiences) 𝟭. 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻𝗶𝗻𝗴 𝘃𝘀. 𝗣𝗿𝗼𝗯𝗹𝗲𝗺-𝗦𝗼𝗹𝘃𝗶𝗻𝗴 Full-Time - Walk into a company and focus on delivering quality data models and robust dashboards. Lots of solutioning. Consulting - Walk up to a company and question if there is even a need. Then ask about their goals for a given timeframe. Map those goals to their business outcomes. Then ponder which KPIs are needed to track the results from objectives to outcomes. 𝟮. 𝗗𝗮𝘁𝗮 𝗣𝗲𝗿𝘀𝗼𝗻 𝘃𝘀. 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝗶𝗰 𝗣𝗲𝗿𝘀𝗼𝗻 Full-Time - Paid to be an incredible SQL developer and DataViz designer. Ensure the business has the dashboard/report they need to answer their questions. Build fault-tolerant pipelines. Consulting - Paid to be a business operations expert with a peppering of data expertise. Stay close to the source system workflows and help guide the business to a successful process. Then garnish the refined process with beautiful data and insights. Get technically deep when necessary, but keep the business goals and costs top of mind. 𝟯. 𝗣𝗧𝗢 𝘃𝘀 𝗔𝗹𝘄𝗮𝘆𝘀 𝗢𝗻 Full-Time - PTO is incredible. Guilt-free vacation backed with credentials and a big brand. Life is awesome. Consultant - Feels horrible taking a day off. The business slips away if you don't keep the wheel spinning. Constant pressure to work and deliver. The flexibility can be nice, but it comes with a lack thereof in other ways. -- These are just a few thoughts I had on comparing the two. Hopefully they help you decide the path you want to walk. ♻️ Share this to help someone else in your network. Follow me → Christian Steinert for more on data architecture and BI insights.