#83 Empowering the Modern Data Analyst
17 Apr 2022 · 36 min
Peter Fishman, CEO of Mozart Data, explains how the modern data stack lets organizations become data-driven faster. He argues data must be a cultural belief, not just dashboards, and that analysts need causal thinking and domain expertise. Mozart Data can set up a Snowflake warehouse with transforms and BI in an hour, removing the need for data engineers.
Chapters
Hi, I'm Maggie, VP of Curriculum at datacamp, and I know firsthand how overwhelming it can be to keep up with the rapid changes in data and AI. But staying ahead doesn't have to be hard. That's why our curriculum team has curated the best learning content to help you and your team stay ahead, covering everything from data and AI literacy for busy executives to cutting edge generative AI for developers, and everything in between. Whether you're upskilling yourself or your team, we make learning practical, engaging and flexible. It just works. Power your data and AI transformation journey on datacamp.com.
You're listening to Data Framed, a podcast by Data Camp. In this show, you'll hear all the latest trends and insights in data science. Whether you're just getting started in your data career or you're a data leader looking to scale data driven decisions in your organization, join us for in depth discussion discussions with data and analytics leaders at the forefront of the data revolution. Let's dive right in.
Hello everyone, this is Adele, Data Science educator and evangelist at datacamp. The past few years have seen an incredible addition of new tools and frameworks that empower even the smallest data teams to do more. These tools are often what is referred to as the modern data stack. One aspect of the modern data stack is that it empowers practitioners like data analysts to deliver insights and prove value at a much faster scale. This is why I'm excited to be speaking with Peter Fishman, CEO of Mozart Data. Mozart Data empowers data analysts by providing them with out of the box data warehouses that allow anyone to connect their disparate data sources easily, apply simple transformations and start analyzing data, all without any data engineers. Throughout our conversation we speak about his experience launching Mozart Data, the trials and tribulations most data teams face when trying to hit the ground running. The skills modern data analysts need to have the importance of developing subject matter expertise, analytics roles, and more. If you enjoyed this podcast, make sure to subscribe and rate the show, but only if you enjoyed it. Also, if you're interested in the modern data stack and want to transition your local notebook environment to a cloud based collaborative environment, I highly recommend checking out datacamp Workspace where you'll be able to code in Python and R and use a bunch of templates and datasets to get you started in data science right in the browser. Now let's dive right in. Peter, it's great to have you on the show. I am excited to talk to you about the modern data stack. The skills that define a successful data analyst Today and more. But before, can you give us a bit of a background about yourself and how you ended up where you are today?
Great to be here. I'm Pete Fishman. I'm the co founder and CEO of MozartData. Like many people in the data space, I'm something of a failed academic that transitioned into the world of sort of applying statistical experience and putting that into technology. So I've been working at startups for the last sort of decade plus mostly in data functions, and ultimately decided myself and my friend Dan decided to build basically ourselves as a service. Then we built MozartData, which we called the easiest way to spin up a modern data stack.
That's great. So can you walk us through how these experiences that you've had across industry and academia led you to launch Mozart Data? And can you walk us through the challenges MozartData tries to solve?
There's a long thread there because it does sadly capture many, many, many years, but there is a lot of consistency in the theme. So what has basically happened is that data has become essentially like bigger over time. Not just the sort of buzzword of big data, but basically the computing power ultimately has a lot of downstream effects. Like people can collect more data because they can get more value out of that data. My sort of arc looks really doing very early empirical work in grad school, when obviously statistics have been around for a very, very long time, but the first time where you could really use hundreds of thousands or millions of observations. You know, today doing analysis with millions of observations is not just like trivial, people would eye roll that. But for me, that was kind of the size of the data sets that I was working with during my PhD program, which at the time was almost unthinkably large, sort of exceeding whatever Excel could do. But what ultimately has happened is that you find insight in the data and then companies figure out ways to take advantage of it and then you have to go find that next insight in the data. So I started my career in the sort of Facebook games space where a lot of these companies competed over using data in novel ways. Facebook had billions of users, so as a result, the data sizes and volumes were gigantic and you could make really novel insights. And we started doing a lot of really, really paid very close attention to CACs and LTVs. And the game was to build a virtuous cycle of buying people eyeballs very efficiently and then sort of feeding that into monetizing and getting more people onto your platform and getting a virtuous cycle going. I then saw the opportunity to deploy that into the B2B world. So the sort of defining part of my career was this company, Yammer. At Yammer, we took a lot of the B2C approach to software development and then applied it in the B2B world and the bottom up SaaS world, which didn't really exist at the time. But it calls for a lot of understanding what your users are doing and understanding sort of the attractiveness of the prospects as a function of who's actually using your product. And that required data folks, and not only that data infrastructure. So I built a tool at Yammer called Avocado along with a really great team. Avocado today is really Mozart Data plus Moat analytics and from there, you know, have had a lot of different opportunities to have similar data infrastructure at different companies before ultimately deciding to build it myself.
That's very exciting and I'm excited to unpack this further before though I want to set the stage for the landscape data teams are working in today and the dynamics that really led to the launch of MozartData. As you said, and I completely agree with this notion that data science has become table stakes and no longer a nice to have. So I wanted to start off our chat by first asking how would you define a data driven organization and how can an organization integrate data science as a table stakes practice today?
Sure. So I think most people have a mental image of a data driven organization as one with lots of TVs all over the office. Now there are non existent offices and those TVs have time series of KPIs and people just walking around the building understand what's going on with the company. By observing the time series of the KPI, I set up a strawman, but I very deeply disagree with that. So the first thing I'd say is very few sort of canned ways of looking at the data often provide the necessary insights that you're talking about. A data driven organization is one where data has a very important part at the key sort of decision making tables. That can mean a very senior executive that's a data person. That can mean that data starts every meeting. That can mean that data analysts have access to all sorts of key decision makers or ultimately data becomes the key decision maker more so than the word strategic. I often find that non data driven organizations often talk about strategic investment ones that almost can't be justified in the data. When you start a company when there's zero ideas, zero data, zero people or one of each of those things, you end up really needing to actually be strategic. You actually need to you need to sort of imagine a world that doesn't exist, that cannot be justified by backwards looking, and you need to essentially apply your own direction and thought and beliefs. Now data can inform that. I mean, one of my favorite examples again worked at this Facebook games company called Playdom. We used to sometimes run advertisements on games that were basically half finished. And though you couldn't make like a statistically highly confident conclusion about how effective or successful the game might be, you could get a flavor for how difficult it would be to maybe acquire users. So your belief about that could be tested even before the game existed. So that's not to say at a super early company you have to only go on gut and strategy. But what I think of as a data driven organization is one that you know, data is a first class citizen, but not just that they collect data and they have dashboards and that they look at time series and they can go to bed at night because they know that their company is going up and to the right, but that rather key decisions are informed by data and cuts and dives and summaries and models of the data.
So to double down on your point here, a data driven organization is where data becomes a habit across the decision making lifecycle rather than something to look at.
Absolutely.
So what are the main challenges affecting organizations today who truly want to make the most of their data?
The way that an organization gets to a place where it can be data driven is by not being data driven. So the success that brought you here is not going to be a data driven success. It's going to be a success that's driven by often the founders, but typically sort of beliefs about the world that, you know, couldn't necessarily be justified at the time that end up actually proving out to be true. You typically have this headwind of the thing that brought you here was you weren't data driven. How organizations become data driven tends to be an underlying belief that our organization must be data driven. And not because a venture capitalist has told you to be data driven. Not because the world and the podcasts you listen to tell you to be data driven, but rather because you ultimately truly believe that the signals that the world is giving you is going to be more informative when sort of aggregated and summarized the right way. I teach a class sometimes at Berkeley where I did my PhD and I go back and I put up a bunch of different ads from games that we ran on Facebook and I said, which of these is the most effective? Which is going to get the best clicks? People raise their hands, not indiscriminately, but they have some that they like. And the ones that they like actually tend to be sort of the better ones. But when you show the ad to 100 million people, their opinion is correct, more so than any true experts. And I think what you need to do is maybe develop that muscle over time. Now, that is not to say that if you haven't done that, if you haven't had it beaten into you, that, you know, you really need to be thinking about the data, thinking about the data the right way and using the data, you can still very quickly adopt that. If I go back to my time at Yammer, we had two very strongly opinionated leaders, two co founders, David Sacks and Adam Pizzoni, who have a ton of intuition. They're famously very talented at product and technology and they would have a ton of intuition. And it was in fact that intuition that made Yammer an attractive company for me to join. But early in my career, actually in the first three months of my career, we ran an A B test on the new user flow, which went counter to both of their intuitions. And we did it like almost haphazardly by accident, but it really set my career up for success because the results were very clear and slightly counterintuitive. And you very, very rarely see that in technology. I think even data people like to hype. Oh, you run these experiments and you get these counterintuitive results and then your company becomes better. That happens rarely, but much more often. You get null results off of things that you think are almost certainly going to work, rather than you get counterintuitive, statistically significant results. That's happened to me not a handful of times in my career, but very, very, very few times in my career. And it just happened that it was in an early part of my time at Yammer, which basically changed their whole perspective on how important it was to run A B tests when releasing products. And it became an essential part of the release criteria. And I think ultimately that was a little bit of chance, but a lot of open mindedness of those two folks, both of whom are now investors in Mozart Data. But on top of it, I think it takes like, either it's at your core or you get a very clear lesson and then that's how you become sort of a data driven organization.
That's awesome. And I wish we can dedicate an entire episode just to impact your experience at Yammer and working with people like David Sachs now, of course, a key component of becoming data driven as an Organization is the set of tools and supporting infrastructure that enables faster time to insight. This is what often is referred to as the modern data stack. I'd love it if you can break down what you think is meant by the modern data stack and what are the characteristics that differentiate it from the previous set of tools data teams are used to.
The modern data stack is not really all that modern. The modern data stack is a modernization of existing data tools and data pipeline tools that have been around for a very long amount of time. The branding on it is great because I hear the words all of the time and it is well deserved in some level, which is to say cloud data warehousing has become like ubiquitous in the sort of users of data space. So the first thing I'd say is that there are these powerful columnars that are sort of able to crunch again, giant amounts of data, not the types of, not the data sizes that I was working with 20 years ago, but like real joins on huge data sets. So what that does is that enables you to use data from multiple places. So what? A modern data stack is effectively not too different than what a vlookup in Excel would be, which is to say it's joining data from multiple places. The stack that gets you there is an EL tool, powerful data warehouse, and a T, a transform layer. So a layer to essentially clean up your data. So you have to extract and load data from many different sources and then you have to clean and transform it so ELT the data. So when people talk about the modern data stack, they are talking about elt. But TEA now has a big meaning. Cleaning. Everybody's always known that cleaning is a huge part of what a data person does. My old boss at Microsoft was Ronnie Kohavi, who has a joke, and I don't know if it's his joke, but I know he loves to use it, which is to say 95% of data science is cleaning data and only 5% of data science is complaining about cleaning data. Which is to say he lands the punchline a little bit better than I do. But what he's saying is that actually people think, oh, you know, it's all building these incredible models off of these beautiful data sets that you compete on or are given and in practice, actually, so much of the work is cleaning and making sure the data is right or consistent. And so little of the sort of work that a data person does is real data analysis. And, you know, it's certainly not zero percent. But the joke lands better when you expect the answer to be 5%. But only it turns out it's actually just about complaining is the rest of the time. If I think about sort of what the modern data stack is, is now all of these tools that represent the sort of cleaning layer. And it's not just essentially scheduled tables, it's a variety of different parts of making sure that the data that you are looking at downstream, whether that's in your BI tool most likely is actually has essentially traveled without sort of any problems.
An exciting part of the modern data stack for me is really kind of the emergence of new categories within the data stack. For example, last year we interviewed Bar Moses, CEO of Monte Carlo, and how they're trailblazing the data observability category. What are some of the categories and tools you've seen emerge over the past few years that you've been excited about?
Sure, of course, I'm going to say a managed data pipeline, I think is the coolest category. And I, and I happen to love one particular company in that. However, beyond that, there are a variety of tools that fit a little bit more, what I call like upstream and upmarket into larger companies that have larger data teams that are using their data in a variety of ways. But ultimately, once you have loaded your data into your warehouse, there's a variety of things. There's data observability, there's data cataloging. I kind of remember way back in the day we used to have columns, revenuefinal, the one to use underscore. You really want this one V6, you know, like. And what I think is obviously the ability for larger data teams to come in and understand the world typically quickly, which is you actually, you know, what you find is once you actually have a mature data organization, it might take someone's weeks to come in, or months even to come in and understand the stack. And DJ Patil has a line about his time at LinkedIn, which was so much about being successful as a data scientist at LinkedIn, was about getting a win in your first 90 days. And if it takes you 90 days to get up on the stack, or 89 days, you better like, be amazing. You better be able to find something incredible in one day. Whereas if it takes you a week or a day or an hour to get up on the stack, well, now you have a real chance to be successful at that company. So there's a proliferation of tools that sort of really savvy companies, like a LinkedIn, like a Yammer, you know, all built and used. Obviously Airbnb has built a number of the famous ones and what those tools were about were making data people effective. So you and now a lot of companies have sprouted up in terms of building those toolings that these companies spent countless Airbnb probably spent hundreds of millions of dollars on. Not that it mattered, but they spent countless millions of dollars developing now, making that accessible to companies that don't have the budgets of Airbnb or Facebook or whomever. So I see a lot of sort of development in that space. Obviously other categories that are popping up that are reverse ETL is a really great example of a downstream one that we had built bottom up SaaS World and at subscale. Now having services that will do this or having services that do extract and load I think are really, really important for companies.
Where does Mozart Data fit within the modern data stack and how does it solve some of the challenges we've discussed thus far? And can you walk us through some examples of Mozart Data in action?
Mozart Data basically is an all in one data platform. So what that means is in under an hour you can start connecting multiple data sources, we spin you up a snowflake data warehouse and you can start writing your transforms and connecting a BI tool or reverse ETL tool and start to get insights. So the real sort of magic is that this used to take months and a number of data engineer hires, or you do a lot of vendor assessment and then pick your, you know, potpourri of vendors to do it, or you hire a consultant to do it. Today this can all be done in effectively no time. And by the time you're sort of done with the demo, you could be up and running and querying your data in your favorite BI tool. Really there is this challenge of this speed to insight and Mozart wants to empower not just like very savvy data engineers, but rather everyone in the sort of data landscape to be up and running with this modern data stack, all very quickly, all without being gated by engineering.
What I love about MozartData is how much it empowers data analysts and citizen data analysts to get started quickly with data and provide value quickly without depending on data engineering or infrastructure work. You know you're somewhere someone who's led data teams, worked with a lot of data analysts while developing Mozart data and more. I'd love it if you can break down how you think the data analyst role has evolved over the past few years and where do you see it heading in the future?
Right at the time where the the term data science again like Jeff Hauerbacher and D.J. patel sort of kicked off this term data scientist. And then the incredibly rapid growth in that profession happened. The title data scientist was being applied everywhere in the data space. And the reason was because working as a data scientist basically meant that you got paid a lot more than working as a data analyst. So everybody started co opting the term and then you saw it to represent, you know, you had folks that were doing ML engineering all the way to folks that were maybe just out of college working with data for a first time, all holding this title data scientist. And it sort of represented a vastly different set of skills all encompassed by the same title. And different, it meant a different thing at different companies. Today you see much greater granularity of that. You see people that hold rev ops or biz ops titles, you see folks where their specific expertise is distinguished. So an analytics engineer is someone that's very different from a data engineer. And you know, a data scientist today has a specific role within a company. A data analyst tends to have a specific role. Now we still see a lot of, if you had a Venn diagram of the skill sets, a lot of that would overlap. And I think actually the best, I don't think that one title is there's no greater than sign. I think a lot of the core skill set ends up being the same. Like what makes for like a really great data scientist actually makes for a really great marketing ops analyst, which is to say sort of a deep understanding of, of causal relationships, of inference and like it's a different set of technical skills. It's obviously it's a different role within the company and the organization. You do different things on a day in, day out basis, but the core is still about sort of data thinking and data capabilities rather than specific technical expertise.
I completely agree here, especially since there's a layer of skills that's a certain extent invariant as the role evolves over the time. What do you think are the defining skills data analysts should cultivate to become successful in a modern data team?
Today I'm a little bit biased because I spent a big part of my 20s sort of thinking about really causality. So I did a PhD in economics, I studied behavioral economics. And what was typically true was you would get great data sets that were not generated by experiment. So data sets where something, you know, you measured things over time and you sort of had an understanding of an individual with an ID over time, but you didn't necessarily have what you really wanted, which is to run a scientific experiment, put people in condition A and condition B and then have a hypothesis and see which one wins out when you don't have that, you have to basically do almost statistical tricks. You have to think about, okay, what is something like an experiment. And I think often that this is one of the most underrated skills in data to really think about, you know, what you're trying to do with your data is essentially assign a causal relationship based on the past that you think applies in the future for a number of reasons, right? You think that there was a mechanism that brought it that still exists today. So I think people that have really that deep thinking about like understanding causal relationships and understanding what typically is wrong with data. So the classic example is you say, okay, well, drowning deaths are always up in the months where ice cream consumption is up. And it's like, obviously all novices say, well, that's because in the warm months, people are eating ice cream and they're going to the beach or they're going to the pool. And of course, and they, they realize that that's actually not the causal mechanism. But then they, then you divorce it from that specific joking context and then you bring it into a world where many things are going on and your job depends on, in some sense, the value you bring to the company depends on identifying a relationship that you think moves maybe the company's, whether it's their marketing, their business, their product, their users forward. And then you start abandoning that critical perspective. So in general, what I like is a set of almost dismantling of good work, thinking about all the ways in which a good insight or good work could be flawed. Maybe somebody did a robustness check that sort of proved that it wasn't flawed. But at the very least, when you read it, can you be, you know, or look at the work that was done, can you be skeptical and say, okay, well, maybe it's mostly driven by something that won't necessarily repeat itself. Because a lot of these, when they do replication studies and you know, when I worked at Microsoft, I worked at Bing and Bing, you know, you had the huge luxury of not just millions, not just billions, trillions of observations. And you could keep tests running and get inference from there. So I think inference is the big skill. But then also inference with small data is also a real skill. It's a little confusing because typically you can't make inference with small data. So if you see one observation or n of one or two, literally you can't make a valid statistical inference from that. But really, having a deep thought about mechanism and how you would set it up to actually learn that answer in a space where you're pretty constrained by data, because what you find is, and we found this at Bing, that even when your data size is infinity, you always want to cut it and cut it and cut it and cut it and cut it to a smaller and smaller cohort to make a more and more precise inference. And without fail, you run out of data even when the data seems like the size is infinity. I think two skills to me often are the most underrated. It's the ones that I think people should develop and work on and it's also the ones that we interview for, not just at Mozart, but at a lot of the places that I've worked.
And being able to make these inferences and spot these causal relationships within the data set requires a lot of subject matter expertise. You know, oftentimes what's missed in the discourse around upskilling and breaking into tech is subject matter expertise and domain knowledge, especially to be able to succeed in analytics roles and data roles. Can you comment or expand on the importance of subject matter expertise in a data role and how it has helped you in your career?
Well, just literally this picks up great. Like you mentioned off of the last question, which is if your key insight is thinking about the right mechanism that is driving the causal relationship you're ascribing to your data, then actually understanding what your users are doing and what motivates your users is critical. So again, I worked at Yammer. We were, we were the biggest per capita consumers of our product, you know, as a company. So it's not surprising. Dan and I, my co founder of Mozart Data, he and I 13 years ago started a hot sauce company. We were also the number one consumers of that hot sauce. So subject matter expertise is 100% like a table stakes thinking that you have to bring in order to understand those relationships. Now the flip is sometimes that deeply works against you. So it's not linear up, it's not necessarily just concave as in, as you get more and more subject matter expertise, this first derivative remains positive. You can find that sometimes you are so deep in your world you are missing what the typical user is doing. Actually, a lot of times in past jobs we've had that problem where we are the right tail of usage and expect everybody to understand kind of some of the subtle things that are going on within the tool. And what you find is that people have a surprisingly surface willingness to pay attention. You know, you're the most important thing to you and a lot of times you can build software and to you it's incredible. But to the typical user that isn't willing to make that same investment into learning all of your nuances, it might not be the case. So subject matter expertise first of all is the table stakes to get started. You can't reasonably understand the mechanisms that are driving your user base without understanding your users in the first place. That's why you often see companies like Airbnb and Uber consumer companies, people that work there are just nuts about using those products. Brian Chesky famously stayed in Airbnb for one whole year, didn't have an apartment. And that was a critical part of essentially developing domain experts. You know, yes, it's about empathy for the customer, but also it's also about tuning that domain expertise. And everybody I knew that worked in ride sharing was taking rideshares everywhere. They had to go across the street they'd take a ride share. I think it's developing not just that subject matter expertise, but also the real kind of getting to your users mindset.
So given your experience in startups and working in smaller organizations, how do you instill that subject matter expertise in early stage startups when they don't necessarily have these massive user bases when they make hires, for example?
So I worked at a company called Open Door and Open Door when I was there was largely buying and selling homes in Phoenix and I had no desire to buy or sell. I didn't own a home in Phoenix, but I didn't have a desire to buy a home in Phoenix. Obviously now they're in many, many, many more markets and I didn't have the ability to gain expertise in essentially that buyer's journey because I never went through it. You're not always gifted. The situation that I discussed with the consumer companies where if you're a data scientist at say Facebook, you're dogfooding it all the time. I think the key is one, obviously if you can do that, it is a huge advantage and if you can't, I think you really want to disproportionately invest in talking with, you know, sort of YC tropes which are talk to customers, talk to customers, talk to customers. So I do think that sitting down, observing customers, talking to customers, talking to prospects that rejected you, all of those things are trying to up your, you know, your knowledge. Now the flip is I am now selling a product that defacto I've worked on for 20 years. So you know, your subject matter expertise is not necessarily one that happens the second that you sign your offer letter, your subject matter expertise, hopefully you're leveraging you Know in my case over 40 years of subject matter expertise. But beyond that, you want to be able to really understand your customer, whether that customer is you, whether that's exhaustive research. You shouldn't think of your title as well. My title says data in it, so I've got to be in a back corner doing data. A lot of the term that I like to use is use your feet which is talk to the product or customer facing folks in your organization or if you can talk to customers, that's great.
And flipping the question slightly, if I am a data analyst breaking into a new vertical, whether a at a startup or an enterprise, what is the fastest way for me to develop subject matter expertise?
So I do think adjacent problems can be helpful. I mean I've loved reading Nate Silver for the longest time and I do think sort of reading folks that think about data the right way. I started my career in the NFL as a statistician, not as a player. You know, I had been into sports statistics for my whole life and you know, I think that there were a lot of parallels to the thinking about baseball. Famously had solved a lot of these sort of real problems of figuring out what had tight relationships with performance, what had predictability, et cetera. But that thinking then very deeply motivated and I was excited about, I just had a passion for it. I read up a lot about it and I think if there's an analytics in a space that you love. Now for me that was baseball and football and there's now tons of material. At the time there was just sort of limited amounts of material. But if you can find those people that love writing really savvily in the spaces that you love, I think that you're going to find good analytical thought, questioning breakdown and that's going to apply to whatever discipline that you're going to do. I mean reading Moneyball, my favorite book from Michael Lewis, really is the same type of thinking that I would give early stage startups essentially about it's de facto the same advice YC gives, which is write down the equation of success and then break it into its component parts and then measure those parts and then dive into when one of these pieces is not working cohort and cut and summarize. And that's how you start analytics anywhere. But it certainly was how the a's did it 20 some odd years ago when they were trying to compete with bigger market teams.
That's awesome. And as we close out our conversation, I'd love if we can think about the future for a bit and what you think are some of the trends that are really going to shape how individuals and organizations work with data. I'd love it if you can list some of the trends that you're particularly excited about when it comes to the modern data stack and how it will affect data driven organizations.
I think we touched on one of them, which is the real rise of the citizen data scientist. First of all, you see a bunch of savvy people that write SQL that don't have data titles, you know, biz ops, marketing ops, all of these sort of writing SQL or R or Python or something like that is just not uncommon in roles that were almost exclusively non tech. I think like that is a really exciting moment for anyone in the data space because the data space is now opening up to many, many, many more roles at companies and many, many, many more people have the chops to do something to be a little dangerous with their data. I think this is a great trend for companies trying to solve the data problem for SMBs. And obviously I'm very excited about one of those companies, Mozart Data. The other thing, the other part of the trend that I'm excited about that sort of also relates to Mozart Data is it used to cost you, like hire a couple of data engineers and buy a bunch of expensive infrastructure and you might be out 2, 3, 4, 5 million dollars just to get started on your data journey. Today it's a $6 swipe of a credit card and you're off to the races. Now it's metered and your bills become significant. Your investment in data ultimately becomes significant. But the fact that you can get started for close to nothing is incredible. It is a huge difference. So if you think about the types of companies, those are companies that could really afford a multimillion dollar investment in data so that they could have that advantage. Were the largest companies, you could only get jobs at the biggest companies because those are the companies that had the data teams. Those are the companies that were leveraging the data and could effectively take advantage of their scale in applying those data insights. Today this is becoming table stakes earlier and earlier. So more and more companies like ours, not just ours, but like ours, are really empowering and enabling the SMB to use data infra the types of data tooling that I see more upmarket. In fact, generally I find data stacks to actually be stronger downstream before there's a dozen sources of truth. You know, it's actually kind of a little bit paradoxical, which is actually almost the more constrained your budget, the more likely you are to end up with effectively a tighter data stack.
That's great. And I love that first trend especially. And this is something that we've definitely seen at datacamp with the hybridization of jobs and the emergence of data skills and, you know, traditional roles like finance, marketing, and a lot more. Now, finally, Peter, I had an awesome chat with you today. Do you have any final call to action before we wrap up?
Yeah, obviously rooting for so many people in their data journeys. And we love helping small companies at the start of their data journey get up and running on their data infrastructure all in under an hour without really needing any data engineering support. So if you're interested in that, we'd love to talk to you at mozartdata. So I'm petezartdata.com that's awesome.
Thank you so much, Peter, for coming on the podcast.
You've been listening to Data Framed, a podcast by Data Camp. Keep connected with us by subscribing to the show in your favorite podcast player. Please give us a rating, leave a comment and share episodes you love that helps us keep delivering insights into all things data. Thanks for listening. Until next time.
More from Richie
#359 My Best Friend is AI with Valerie Tiberius, Professor of Philosophy at University of Minnesota
#358 How AI Agents Will Work While You Sleep | Ruslan Salakhutdinov, Professor at Carnegie Mellon
#356 The Forecast for Time Series Forecasts with Rami Krispin, Senior Manager of Data Science at Apple
#355 AI's Impact on Databases with Shireesh Thota, CVP of Databases at Microsoft
#354 Beyond BI: Decision Intelligence with Graphs with Jamie Hutton, CTO at Quantexa
#352 AI Agents at Work: What Actually Breaks (and How to Fix It) with Danielle Crop, EVP Digital Strategy & Alliances at WNS
#351 Will World Models Bring us AGI? with Eric Xing, President & Professor at MBZUAI
#350 How to Make Hard Choices in AI with Atay Kozlovski, Researcher at the University of Zurich
#349 From AI Governance to AI Enablement with Stijn Christiaens, CEO at Collibra