The Data Hustle — Christopher Gambill

Absolutely. So first of all, thank you for having me on. Super excited to be here. I've been looking forward to it. But so as far as me, I think you did

pretty good recap. I've been in data since 2000. So just short of 26 years now, a lot of that time was spent in telecom companies, worked for a company called US Cellular. I did my own stint in consulting for a few years from 2008 to 2011. By the way, 2008, probably not the right time to start a business based on the environment at that time, but went well for a few years. And then jump back into the corporate world working for AT&T for 14 years, where at the end of that stint, I did work as the director of data and analytics for the cybersecurity org that's now level blue. I kind of helped them through that divestiture piece and had some great

they go through those growth curves. And then I also run my YouTube channel, which is Chris Gamble Data Engineering Strategy, where I focus heavily on really kind of senior level engineering strategy. And then I also have a coaching program where I help data engineers transition or people looking to transition to get into data engineering. Just out of curiosity for the context, when I first started my career, the big boss was big data. That was like the boss where there was repeating. But you get started in the world of data way before that way before Spark distributed. What was like the boss work back when you first got started? Just data like, like literally like my origin story, right? My kind of like superheroes, my origin

story is I actually worked on a customer service help desk and they were giving out these. It was right as kind of SOCKS was getting, you know, Sarbanes SOCKS was getting to be a thing. And they were giving us literally printing out reams of paper every week and giving them to us to review all the adjustments that customer service team was making. And then, and I was like, we're burning a whole forest every week. So I took the initiative to figure out where the data was coming from. I taught myself SQL. I just spun up a local, just a SQL Server, like a SQL Server Express on my local machine and started creating, it was a DTS package even before SSIS,

right? It just creating some pipelines to pull data and pull it in and then created like a VB.net front end. And then I created like a VB.net front end to, for us to actually log our notes and everything. And it was pushing the data back in. And they were like, Oh, you could do these things. You're no longer a help desk person. You are now the data person for the call center. And so we didn't have a whole lot of buzzwords. It was, like I mentioned, there was, we had DTS packages and we had Crystal reporting and we had like Visual Fox Pro was a thing back then, right? And the first buzzword that I really remember kind of getting

into was Hadoop, right? Hadoop and Big Data and MapReduce. And it was, so it was kind of that 2009, 2010-ish before I started seeing those real big buzzwords. Everybody else before then, we were so stuck in on-prem systems that it was anything that you could do to get data all into one place. We didn't even have, you know, a lot of the terminology that we have today. Nowadays, we take something like hype cycles for granted, but it's not always been the case. I mean, I didn't realize this wasn't really the case at that time, at least in this industry. The biggest thing for perspective, when I first started, it was before we had like even Stack Exchange, right? We didn't have

The biggest thing is like one of the pillars of my business

is strategy over syntax, right? And I think that a lot of people fall in love with the tech, and they fall in love with the syntax piece of it. And I think that's the biggest thing is they get caught in these tutorial hell cycles, right? Where there's just, there's so much information out there. And I mean, don't mistake me, I love the code. And I love sitting out, sitting there, and just hammering away and creating notebooks and scripts to pull the data. But so much of our jobs is actually figuring out how we can become true business assets, and kind of moving beyond just that kind of code monkey mentality, and understanding how to make the decisions that we need to make

in order to move the business forward with the data that we're pulling. So essentially, the transition to becoming a more senior data professional is a little bit of falling into the tech and then finding that instinct. It's a, it's an interesting duality. Well, actually, the part of the prologue of our book is a little bit around that, that you somehow, what was it that we agree that you somehow like love the tech and you secretly wish they would just leave you alone to code, but you do understand that it's only valuable if you're there in a human context, putting things into perspective. Exactly the sentiment I'm trying to get across there, for sure. That's awesome.

People still even be going into data engineering nowadays? On my YouTube channel, that's a question that comes up all the time. But yeah, people should still 100% get into data engineering, especially if it's something that you love and you really love. People love the data. I love the data. But AI, anybody that's been in data knows, first of all, that it seems like there's no light at the end of the tunnel to the amount of work out there that needs to be done. And AI isn't going to kill data engineering, right? It's kind of going back to that perspective of I started with DTS packages, and then Juan was talking about big data and Hadoop and MapReduce. And then we had the major

cloud systems come in with Azure and AWS and GCP. And now we've got AI. This is another tool that we're going to use to make us more efficient. But each of those things that came along was supposed to help reduce the need for our roles in business. And none of that, each of those times, the only thing it's done is increase that need. Right? So my perspective is AI isn't killing data engineering. And it's just another tool in our tool belt. The biggest thing, and I would argue that this has always been true, is that person that not only loves the tech, but literally doesn't go outside of their shell, right? The ones that do go out into their corner, and they

code all day long, and they go home, that's where those people are going to start to continue to fade away. But again, I'd argue that that's really always been the case with each of these cycles that have come through. It's funny if you talk about the automation part. If you look at some of the original pieces of capitalism, like Adam Smith, he predicted that by this time, I think even before the year that we're currently in, we would have put in so much automation, everyone is just going to do art and have a lot of free time to themselves. But we're kind of seeing the opposite happen. There's this 996 grind culture, there's this phenomenon called the AI vampire, people are so focused on

putting all this output out there that they're missing sleep. I'm kind of personally seeing that a lot. It's not that there's less work, there's just, we feel it's possible to do more, so then we push even harder. Like, builtically, two things are happening. The first one is, because it's becoming slightly easier to work with AI, companies are more ambitious about what they do in terms of data engineering. There's always been a segment of companies that find the whole idea of getting a dean engineer super daunting, like they cannot hire this person. That's not in our roadmap for now, it's always okay. Right now, I think a lot of those companies are realizing, you know what, it's probably the right time because it's

become a lot easier. So I do agree with you, Chris, I see the demand growing. And I had this conversation the other day with one of my coaching students, but there's this pendulum, right, between kind of to the point of what you're talking about, of more businesses are starting to see the value of having a data engineer, but there's still some businesses that are like, I can't afford it, right? They see that value. But the pendulum has always swung between like, W2 work and consulting, right, and contract work. And to that point, you might, there might be people out there that are like, I can't find a permanent job, but I promise you that there are small businesses and even some like mid market

Where should they look for? What should they do? I was talking about, I've got this coaching program and man, there are all kinds of people out there that have fallen in love with data, right? I have a few people in my program that are PhD students and they got into

kind of doing that grad work and stuff. And they're like, I love the data. I don't care anything about the rest of this. I love doing the analysis and the research and the data and actually creating these reports and stuff. And so, so, you know, those people that maybe I would argue that there is some type of transferable skills in your current role, whatever that looks like, that you get transferred into a data role, right? There is, if you love the data, right? If you've already started thinking about this path, there are things that you've looked at in where you work in your business that you're like, if this was more automated and I could pull the data from here

and here and here and put it all together. And you're probably, somebody is manually doing that and putting it in Excel and doing a bunch of V lookups anyways, right? But take those transferable skills and continue to build on them. Go out and do the research to teach yourself SQL and Python. There are so many resources out there on Udemy and on DataCamp. And even if you want to go back to like the W3 schools website, right? There, even that platform is a fantastic, you know, foundational skill to start kind of playing with and learning some of those skills. I think I lost the thread of what the original question was there. So I apologize. But but yeah. Back to the other, you just

mentioned of transitioning into data. And so the big pieces, a lot of those people, it's incredibly easy to get shiny object syndrome and overwhelmed with all the different things, right? And my advice to people is to pick a lane. And I've recently used this kind of bowling alley analogy of you when I was younger, I had one lane. I only had one lane in my bowling alley. And it was like on premise SQL server. And learning that stack was all I had to worry about. But now, especially somebody coming into it, they see these 50 different lanes. And you have Databricks and you have Snowflake and you have AWS and you have Azure and GCP. And there's so many different things. It's so

easy. And especially with all the different AI tools coming out, so easy to get shiny object syndrome and get distracted. My advice to people is to go out and find five or 10 job postings that you're like, yes, this is the job that I would absolutely fall in love with and figure out what the text decks are common amongst those. And choose that as your lane. Go deep. There's this concept of T skills, right? And go deep in those lanes. And that's where you spend your time actually learning, because those are the things that are going to get you into those roles. And then once you're in the role, then you start to build that practical experience. And you could start to broaden your

different experiences and your knowledge. And you'll start to learn those edge cases and different things like that. Because people that are transitioning into the engineering, right? So. Some people that are in senior engineering roles now that are looking to get into leadership and those coaching calls have a tendency to lean more towards understanding and navigating the political side of things. And how to position your data team and your projects in a way that you're actually getting the funding and the time that you need from your executives for the projects that you need to complete.

Okay, then let's let's focus some of the questions on more the junior side of things. I think the question that it might be a little bit mean, but that it's very important to tackle is what often when you see the curriculum of somebody doing a career transition or somebody that is very new, the first instance is does this person really know if this person is a bit better than AI? What are the things that some people listening that maybe don't have a lot of like annual years of experience can do to actually like look favorable when people ask that question? So the biggest thing that I recommend people do is to go out and break things. Like one of the one of the big things

that I tell people all the time is to break things and figure out how to recover, right? Because to your point, we have AI right now, right? And there is from a syntax kind of going back to that strategy over syntax piece from a syntax standpoint, from a coding standpoint, you could get a lot of stuff out of AI and it'll work fundamentally, potentially. But is it things like idepotency, right? When you rerun that, is it going to just ingest a bunch of duplicates? Is it probably actually what I see a lot from AI recently is that it's just doing an overwrite and literally it's just wiping out all the data that you just ingested and doing it again. So, you

know, actually developing those decision skills, going out and like the Databricks free edition right now is a fantastic resource because you literally don't have to put in a credit card or anything. And you could go out there and practice a lot of these skills. So what I recommend to people always doing is go out, find a resource, find a resource, Udemy or whatever your resource of choice is to actually learn the syntax, but then jump into Databricks. Don't try not to use Gini and actually go out, write the code, create Databricks jobs and practice the orchestration piece, create all your catalogs so that you have things in bronze, silver and gold, and you're doing all the cleaning and stuff, and then break things. And when you get

those errors, actually do the legwork to actually do the troubleshooting. And that's how you're going to develop those, those synapse connections in your brain to actually be able to repeat that process when you get into the real world and then document all those things in your project and all the decision points that you made in your readme file when you put it in GitHub so that when you do pass that to a hiring manager, then they could see, okay, this person actually took the time to make these decisions and they logically can explain why they made those decisions. There are two interesting ideas there. The first one is, there are things that are not that easy to learn from tutorials,

which is like the battles, cars, the edge cases, what to do when things break, for example, at scale. And the second one is, it's still very important to document your line of reasoning to have very polished readmes. And in the past, just having all readme was enough because most people didn't do it properly. But now, with AR, most people will have some sort of readme version. I still think you can put some effort to make it more unique. And that's the thing kind of going back to what you're saying that I have people do is those, I call them decision points, right? So each decision point really documenting why you made the decision, what your pros and cons are that you weighed.

And those are to your point, those are the things that an AI isn't necessarily going to add to it unless you explicitly ask it to. Differently, don't ask for permissions, ask for forgiveness. There's been that person in there, unfortunately. So yeah, yeah, yeah. Forgiveness written inside of your readme files. Interesting. So okay, that's the first step that will be to have a portfolio with really good readmes. What other things, once again, to going back to a question, what other things can people do if they don't have too much experience to make it tangible that they can do the work? One of the big things that I do is, you know, we talked about the picking five or 10 job postings and figuring out what that tech

stack is, building the portfolio. And when you're the biggest thing when you're building the portfolio, pick the industry that you're going to go into, whether it's healthcare or manufacturing or aeronautics or whatever the case may be, and make your full end-to-end project something that is actually relatable to somebody that's being, that's a hiring manager, right? That's going to be actually interviewing you. Somebody that is going to look at that GitHub repo, that readme file and say, this is a real problem that I'm having today, right? There are so many, there are so many portfolio projects out there that are just those generic COVID, Titanic type datasets that literally when I pick up somebody and that's all they have is Titanic

and COVID-19 or something, I'm like, oh, not again. But if, I mean, think about it, as a hiring manager, you pick up this resume and you read and their portfolio projects, it actually relates to a issue that you just got off the phone having, then you're like, oh, okay, this is interesting, this relates. Aside from those portfolio projects, I'm not a big proponent of diving in too far on certifications, but certifications are a thing, especially for early career engineers and to get past some of the ATS kind of sensors type stuff. But don't over crank on that certification piece, right? Again, pick your lane. If it's Databricks, then do the Databricks data engineering. I would just recommend jumping into the

professional cert. If it's Snowflake, then take a look at those Snow Pro certs. If it's Azure, then go out and grab that fabric cert, but don't over crank on those. And then aside from that, find a mentor, find a coach and network. The biggest thing, I mean, when I was younger, every position that I had, the positions that I had, came from somebody that I knew saying, hey, we'd love for you to work with us or a friend that I had earlier in my career. And even my business now, when I first went back into consulting, my business really came from other leaders that I've worked with in the past that knew me, that knew my work ethic and my

background. We never have this happen, Chris. It's like raise the flag. I guess to put it also back to a wider spectrum of people, whether they're beginners or more advanced or even further, the exercise that I like to do, this is something that we've been putting a lot of work into in the book that we're writing on data consulting, is imagine what is the proverbial top of the mountain.

And the way I was thinking about this is you might at the bottom have someone that focuses on the implementation. It's very good at delivering implementation, but is it really connected to the value and why the business needs it? Maybe if you're a step above that, you're able to connect your work to actual value as what you're describing, right? Like you're able to say, the business has these pains, I'm able to meet that with these tools and technologies. And then maybe one step beyond that would be someone that would be considered

If we're talking about, let's say you're at the start or in the middle or you're near the end, what is that 10, 15, 20 year journey look like in consulting? No, from the consulting standpoint, like first of all, so important not to burn your bridges, right? So easy to do. And to burn your bridges, it's much more difficult in practice, but you never know who you're going to run across 5, 10, 15 years from now. That is in a position that can be like, hey, I loved working with you

things, especially as you're first getting into it throughout, but especially as you're first getting into things on the mistakes that you make, be willing to admit that you don't know something and don't burn your bridges. That second step is kind of making sure that you are learning. I use this analogy that you're learning how to take a hammer and not just hammer that nail into the wall, but you could hammer a nail into the floor, the ceiling as well. So if you could, if to put it in a more practical instance, right? If you learn Python and you learn from using pandas, then you should be able to transition that learning into Spark or polars or, you know, one of the other, one of the other

libraries as well, because from a data frame standpoint, the concept is the same. The only thing that you're changing is the syntax. So being able to continue to develop those skills, continue to learn how to adapt quickly. So that's kind of the second level, learning how to adapt quickly, learning how to integrate what you're doing into the business, being able to continue to build those relationships. Don't be that guy that ends up sitting in a corner coding all day, right? Actually having those conversations and understanding what the business needs are and how what you do relates to that. And then that's how you earn your seat at the table to become that strategic partner, right? Kind of what you're talking about the top

So I mean, for me, I came from a customer service background. So it was probably easier for those that have been in, you know, true face-to-face sales or customer service situations. I mean, when I was 14, I worked at a Taco Bell and a drive-thru, right? So for, you know, early as a teenager, I was dealing with people all the time.

But you learn how to adapt. The biggest thing is that strip out all the buzzwords, strip out all of the technical acronyms. You can't tell a business person that, "Hey, I put your table in the silver layer," and them have any idea what any of those words mean, right? Be able to tell them and come to them and say, "Hey, I was able to get that data from those systems that you're pulling them from manually. I've done some cleaning that we talked about that you have to do manually anyways, and now this is your source and you could pull it into your reports," right? Make it sit with them, talk to them, hear the words and terminology that they use, and then mirror that back to

And they're going to use that terminology just naturally. And sometimes, a lot of times, you

people and figuring out the terminology that they use. So, oh, there is one I came across the other day, and I was like, "That means a different thing to me than it does to you." Oh, my gosh. Something as simple as, like, MOM, right? For months, you know, from a finance perspective, MOM is month over month, right? But from a, like, a manufacturing scenario, it could be, you know, manufacturing of mobile, right? And it's literally the mobile unit that goes into the aircraft. And so, though it's some, finance is bad about it, right? Finance has, like, EOM and MOM and YOY. And so many

of those acronyms are used throughout the same business that those finance people are in for various other things. But that's one of my favorite ones. It's like, MOM is, yeah, manufacturing of mobile. And it literally just meant putting that mobile unit in the aircraft that does the telemetry back to the send over Wi-Fi. Kind of opens up two ideas. The first one is some industries are a bit easier to break into. And if you for whatever reason manage to break into one of the ones that is not so simple, that kind of guarantees that you can stay in the niche that's going to be very appealing. Maybe once again, maybe not for e-commerce, but I do know some companies that would only

hire consultants if they have, like, through an experience in pharma. Yeah. So many pieces to healthcare, especially when it comes from a regulatory standpoint, that they want people that are experienced in all those pieces. Want to learn about that? They should talk to me. I've seen all of it. You also mentioned a funny idea, which is like looking at the stack, like check some bacon, see what tools they're using. I do think like it's isn't that a bit dangerous, because maybe you find tools that are on their way out. Isn't there like an appeal to try to predict like, what are going to be the next big tools and want to be one of the experts first?

So I like that question. First of all, that's fantastic. And it goes back to the strategy over syntax. One, you and I were talking about earlier, we had big data, right? And then we were, there for a while we didn't have data engineers, right? We were just the data guy. And then we were the big data engineers. And then we were the cloud data engineers. And now there's going to be AI data engineers. It's so easy to chase that next shiny thing. And I would argue that your ability to take what you learned from this tool set and tool set, and adapt it to the next one, is really the skill that you need to really hone in on. Because, I mean, think about

it, if you if you learn how to write SQL, or Python, it doesn't matter if you're writing it in VS code, it doesn't matter if you're writing it in SSMS, doesn't matter if you're writing it in DBIVR, right? There's several people out there who use DBIVR, right? It's all the same, right? The syntax might be a little different from PL SQL to T SQL, to when you're writing SQL in Databricks. But you're really doing the same thing, that ability to adapt from to those different tools is really what you have to kind of focus your training on. That transferability to other tools is important. And the reality is that 70% of the businesses out there, and 100%, I just grabbed that

number out of thin air, but in my experience, around 70% is they're not, you know, adopting to those brand new tools. There's still, there's plenty of business out there that are still trying to figure out how to migrate their last 10 SSIS packages into ADF. And ADF is getting ready to go away and just be absorbed into fabric, right? And so there's plenty of work out there, I promise that is still those legacy tools. It's interesting, when I was first starting, I remember I had a lot of conflicts of which tools are easier, which ones are more difficult, which ones pay better, which ones pay worse. Do I pick a tool that I like working with, a tool that the market

wants? How do I know like which tools are going to become obsolete? Because my introduction to the tech world was Ruby. A few months before Node.js kind of like destroyed their market cap. So to me, it was like a more nuanced conversation of which tools do I start choosing? So I'm curious, like, how does that conversation goes when somebody asks you? Like I said, I try to have them identify those kind of top 10 positions. Because somebody that's jumping into Azure and somebody that's trying to jumping into AWS are two very different skill sets, right? You definitely have to, in my opinion, AWS is a higher bar for entry than Azure, right? I would argue that you have to have a

pretty decent kind of software networking and understanding, even being able to get into some Linux when you're spinning up things like EC2 boxes and stuff like that. Being able to do that is a little bit higher bar. So part of it is what's your aptitude to learning those things. Microsoft has always done a good job of kind of having that bar pretty low for entry. But focus on the tools that those industries are using. Because nobody tomorrow is going to jump from, as soon as I say this, they will. But nobody's going to jump from AWS into GCP, right? I mean, they're not going to migrate from AWS to GCP. I've done some big migrations that have gone from Azure

to AWS and AWS back to Azure. But those don't happen real often either. I always say from cloud to cloud is kind of like when there is a fridge that is 10% better than your spine and your fridge doesn't really feel like even if it's objectively true that one of the three clouds is 10, 15% better, it's still almost never worth it to fully ditch the one that you have. That's very true. Which is something we also discuss in our book in a way is on the one hand, there is this very long tail of R&D where we get to places, right? I mean, technology just develops over decades and something like SQL has been developed, I mean, eons ago and it's still powering

everything, right? And then there's still development in that field as we go. And then, you know, in that sort of real sort of slow progressive economy that moves most things around in practice, there's sort of this hype cycle on top of like, Marcus, like, Oh, my God, AI agents, oh, my God, spark, oh, my God, Hadoop. And then, you know, you're kind of stuck between these two places where you see the reality, you know, boots on the ground, which is, we haven't changed much of what we do in practical terms, maybe a little bit here and there, or it takes some time. And then on the other end, there's like this whole parade outside of like, Oh, my God, we've completely

reinvented working as a human species. I will work with your trainees about not falling too much into internet hype when it comes to careers, right? It's a good point, right? Which is, you have to be able to whatever skill set you build, it's not thrown away. I think that's what a lot of people are feeling now, especially, right? Like, you know, there, I see a lot of stuff out there, it says, well, you're not gonna have to focus on implementation at all, like, that skill, it's not relevant, and people feel sort of distressed, like, what have I spent my time learning over these 1015 years, which I think is a ridiculous statement, if you look at how it looks in

practice. But you still need to sort of connect it back to what your stakeholders expecting, or the business or the investor, wherever you're selling to, as you're saying, like, if you're going to go in an industry, and they're 90% Azure, and you come in with all the AWS skills, well, you can sell, it's just going to be more difficult. It's a steeper hill to climb. Yeah. Yeah. Yeah. And being able to adapt between those two is so important, whether you're consulting or just in a job, because you don't know, you don't know when your snowflake shop is going to all of a sudden move to Databricks, or be hybrid, I'm starting to see these hybrid instances, right, where, you know, they're keeping all

Because I often feel like there's when I tell people like you got to, you got to read the publications, maybe the CEO of the business that you're working with is reading, or you got to like at least understand some of the reporting and terminology, you know, they read and shapes their ideas. I can see people are going to roll their eyes and they're saying, that's some buzzwords and stuff. Like I don't want to deal with any of that. Like how do you tell

Because sometimes the distance is huge when you work in certain departments or industries. And for people out there that I really like to keep an eye on and listen to. And like one of the podcasts that I can listen to religiously is the AI Daily Brief. And I love that because he's very practical, right? He is pretty straight up of, yeah, this is how the hype cycle is, but this is really what's going on. And also like what I tell people is to when you see something shiny come along and you really want to learn more about it, you know, you can do it.

And if there's not, then you're the community, right? Then you're the one that's doing all of the testing, all the QA and becoming the person that is the community. And there's some alert to that, right? For some people, but when you're first learning the your career path there, it's probably not the time to be that person. That's fair, right? So it's always a very interesting formula because you kind of should give into your curiosity if something seems interesting. Give it a try, but especially when you're starting, it's good to go a bit safer and then

think of learning and total a little bit like a gamble, only gamble when you can afford to do so. Yeah, yeah. And from a person standpoint, like Scott, oh my gosh, I forgot Scott's last name, but Scott is, his last name starts with an H, but he's really big into iceberg and he's going to kill me that I forgot his last name. But following him and all the things that he's doing, especially like his GitHub repo and stuff, because he puts so much out there. He's an advocate for he works for Databricks, but he's one of the developer advocates for Databricks. And like the stuff that he puts out and the things that he talks about are kind of at that edge of brand new,

but are good things to at least have your on your peripheral of these are the things that I should kind of listen to. But you start to develop your own kind of sense of who to listen to when it comes to that stuff. It's also good to remember, like people have like longer careers. It's not, you don't need to like brute force it to learning the first year all of these things. It's incredibly overwhelming. If you try to learn, look at the tool stacks that are out there and try to learn all the things at once. Like you just run into that analysis paralysis type situation. Just take a year and one day, we'll give you a day extra. That's a shit. Do it.

use this analogy of when I, you know, when I was younger, first getting into things, like, I love the fact that people looked at me like I was the wizard, and I could do all the things. And I 100% was that person, the first, probably five to eight years of my career where I said yes to everything that came my way. And then was incredibly overwhelmed and stressed out. Right. But it's it's easy to say yes, because there is that that reward at the end of looking like the hero looking like the wizard. But learning strategically what to say no to, and what is actually going to advance the business, right, and the crew in your career, instead of just every ass that comes through. That's

how you end up with, you know, power bi workspaces with hundreds of power bi reports that only five are being used. Because the data team said yes to every ass that came through you turn into this Jira factory. But being able to strategically match what you're doing to that business outcome. Did I go completely off the rails on what your question was? Or am I? Okay. So teams teams end up falling into this Jira factory trap, which is a big thing that I do when I come into the business to help them kind of mature out of that piece. And it's because they end up have, you know, they start with one or two data engineers, and maybe an analyst, and

they're just cranking away. And they're literally being pushed to say yes to everything, or the business has gotten so used to them saying yes to everything. Because again, these people feel like you've made them feel like wizards, like they're the heroes of organizations. And figuring out, okay, does this project, there are three things to ask when you get a project request that comes through, right? One, what business question is this actually going to answer at the end of the line, right? Kind of start with the end in mind. And I think I probably have appropriated that from like the seven, you know, the, what are they called the, I don't know, anyways, went off the rails again. But some leadership book that

Or is there somebody is something else that we're already doing that closely relates to this? Right? Do I need to really replicate this in a slightly different way? Or can this other thing be used? And it'd be just be tweaked at the front end in a Power BI report. Some, a lot of times, it's a quite a request will come in. And it's literally a filter that somebody could actually put in a Power BI report or an Excel file that gets the answer that they're looking for.

That yes, it fits now, but three months from now, nobody's ever going to use it again. And so determining those three things when you're

Obviously on YouTube, like we talked about the Chris Gamble data engineering strategy, it's at gamble data engineering.com or

able when you go to YouTube, it's at gamble data engineering. The my website is just gamble data.com. And then my LinkedIn, because there are a million different Christopher gambles out there. And because my LinkedIn is incredibly old, my LinkedIn is actually database management. So when you go to LinkedIn, it's linked in.com slash in, slash database management. So so that's the that's the little easter egg there at the end is I created it in 2008. And database management is what I was kind of labeling what I was doing at the time. We'll leave all the links down below so everybody can find you and thanks again for helping on here. Fantastic. Just time. Thank you for having me.