In this second episode of season 2, host Jesse Anderson and Tavia Gilbert take a listen back through Jesse’s favorite moments from Season 1 of the Data Dream Team series. But this is more than your average clip show — Jesse offers his own fresh ideas and actionable insights for each guests’ wisdom.
Mentioned in this episode:
Welcome to the Soda Podcast. We're talking about the Data Dream Team with Jesse Anderson. There's a new approach needed to align how the organization, the team, the people are structured and organized around data. New roles, shifted accountability, breaking silos, and forging new channels of collaboration. The lineup of guests is fantastic. We're excited for everyone to listen, learn, and like. Without further ado, here's your host, Jesse Anderson.
I'm Tavia Gilbert, executive producer of the Data Dream Team podcast. And today, we are kicking off season two with a retrospective of season one of the Data Dream Team series. Here to help me with that is our Dream Team series host Jesse Anderson, data engineer, creative engineer, and managing director of Big Data Institute. Jesse is also the author of Data Teams: A Unified Management Model For Successful Data Focused Teams. Jesse, welcome back. We are really excited to be starting season two, and it's so great to be with you to kick off this series.
I'm excited too. I couldn't be happier to do this. We get to think back and we get to look back at what happened in our previous season, talk about that, play some clips. It's kind of funny. Have you ever watched an episode where it's a clip show?
Yeah.
You then wonder, why are they doing a clip show? And now I understand why you do a clip show. You get to talk about, you get to see what you did previously, and the fans love it. So we'll take out some nuggets that people can really go back and say, oh, maybe they didn't catch that. Maybe they didn't see that. And we'll go back and talk through them.
Great. The highlights of all the good that you did before and all the good that is to come! I like it! We invited you to highlight some of your favorite moments from season one. And today we're going to listen back to those moments together, and I'll be really curious to hear why exactly you chose those moments to reflect on and what your takeaways were.
So let's get started! Our first clip is from your interview with Paco Nathan, also known as the Evil Mad Scientist. So there's a really good story there. Jesse, how do you know Paco? How did you become acquainted?
I've known Paco for a long time. In fact, you may not know this, but Paco Nathan is the person who really inspired me to go on this journey of looking at management for data teams. He did some of the original work on that. And with his permission, I both took his work and expanded upon it.
Let's take a listen to that first clip.
Paco: I do tend to like smaller teams, and I do tend to like people who wear multiple hats. People who have some background in business, but also background in math, but also a lot of coding. I really, really don't like titles. I sort of eschew titles, and I really don't like specialized roles, highly specialized roles. I mean, I can see it in a large enterprise, of course there's a need for some, but when I'm running a data team, I want people to be a bit more open to pairing with experts in other fields.
So I tend to like having a small team that has expertise at the systems level, as well as serious software engineering expertise, as well as the analytics and the math that's driving it. And of course, staying close in with the people who have the domain expertise in the business. And that does lead to a lot more hands on, but I just feel like that's the proper way. And I see results from it. And the other thing too is, I've really used almost a graduate seminar approach. There's a lot of argument about - Do we use a service bureau model? Do we use hub and spoke, or do we use embedded teams? How do we deploy the data experts in an organization? And I've been engaged in some of these arguments for large organizations where they're grappling with it. Facebook and Google and others.
And my view is, I really like having almost a graduate seminar approach where the different data science teams get together maybe once a week for lunch, people put their ideas or what they're facing as challenges up on the board, other people comment or shoot it down or whatever, and maybe you can have stakeholders coming in, but they have a non-speaking role. It's kind of a safe place for the data people to sort through issues. Just like in a graduate seminar. And I found that that works really well in industry.
So talking about working on smaller teams, where there is not so much of a rigid designation between roles, where people are more open to being a Jack or Jill of all trades. That was such an interesting clip, Jesse. What resonates about that with you?
I think there's two important points that Paco makes. And one is, as you mentioned, being the small team, the Jack or Jill of all trades, but also that whole graduate seminar style of it. So let's talk about both, and we'll kind of tease out why I chose this. The first one is this small team. Now, if you've ever read, I think it's Donald Knuth who did that, where he talked about how when we expand our teams, we expand exponentially. We expand the number of connections between our team exponentially.
So as you make that increase in your team, realize you're not getting a linear increase in that productivity. So if you have, let's say, a 20 person team, adding that 21st person is not an increase in a linear fashion of that extra person. That is raising that person to the power of the number of connections within the team that they need to make. So their productivity may be 20%, maybe 50%. It depends on how the team is structured, how much overhead there is. Maybe you're lucky and you get 70%.
So what I've always thought of is, by having smaller teams, we may actually have an overall more productive team simply because there is less overhead to that team. Less communication overhead, more context. So what I've always thought of, or my dream has always been is, if I wanted to create my best data team, it would actually be a pretty small team in comparison. And we would actually be more of a tiger team, a more general purpose team, as Paco talks about. And that general purpose team would actually be able to go through and do several different things all at once. There would be more cross training, more akin if you would use the alpha teams in the U. S. military, where I like to say, if you look at the alpha teams within special forces, the person who's, let's say, the sniper on the team, isn't the fact that they're the best shot - and they generally are the best shot - but every other person on that same team could do the same thing. It's just that that sniper is just a little bit better there. So this is an important distinction where if we have the right team we have a very highly cross trained team with lots of Jack of/Jill of all trades.
Now switching on to the seminar style, I think that's another important part of how do we get through and talk as a group about problems? And I think it's important where Paco talks about people getting together and talking, but there also may be other people there with non-speaking roles. They're more listening, and it's the team talking through the problem, really talking through what they want to do, why they want to do it, suggestions. I think it's a good way of, how do we talk about a problem without a finger pointing, without a lot of problems, and going from there?
And obviously having our clip show start with the Evil Mad Scientist is not a bad start at all. So I also like that very much.
Paco is very evil. You gotta watch out for him.
Okay. Well, I definitely wanna go back and listen to that whole episode then, because I want the backstory on that, so I'm sure I'm not alone. The second clip we have is from an episode with Jordan Morrow, "The Godfather of Data Literacy," another great title. I like that, too. How did you become acquainted?
I met Jordan for the first time on the podcast, and I found his message of data literacy to be super interesting, because I'm usually on the other side of that saying, how do we become far more technically literate? But he was on the other side of that, talking to the business side about how did they become literate as well as the less technical data analysts on becoming far more data literate.
This clip features Jordan defining what it means to be “data driven.” So let's hear the clip that you chose.
Jordan: And so here we had all these companies wanting to be data driven, but the pandemic opened up their eyes to say, we are so far away from where we need to be. And that caused problems, especially in the early stages of the pandemic. And that's why you saw, in my opinion, why you saw that term, “data driven,” is now one of the biggest hype terms in the world of data and analytics. You had all these organizations who thought they were there only to find out they're not even close, and now they're trying to catch up.
And the reality of it is, over the next five to 10 years, those companies that become more data driven, I believe we're gonna see that they're the ones who succeed. And the ones who can't become data driven are gonna become like the Blockbusters, right? And these other companies that get stepped over from this opportunity to use data effectively to make all these decisions.
Jesse, do you agree with Jordan there about the overuse of the term “data driven”?
Oh yeah. I completely agree. I see it all the time. So I think there's two parts to what Jordan was talking about, and that is, a management overuse of data driven and this pulling away from companies that truly are data driven. So let's talk about both those parts. What I often find is that management is disconnected, especially executive management, especially board level, from what is actually happening.
So there may be a board mandate that says, rah rah rah, we're going to be data driven, but they'll say that, but won't either provide the resources, won't provide the time, won't actually do what it needs to be data driven. So that board mandate may have been around for five years, and now, as Jordan was saying, now Covid comes around, and now feet to the fire, we need to be data driven. We need to be making data augmented decisions. And so the board says, oh good. We've been data driven for all this time. We're ready to do this. Now, okay, you data scientists, you analysts, go do some data driven things, figure out what's happening. And then what happens is they circle around and say, oh, well, we don't have this. And we don't have that. And although you said that, we aren't able to do this. So I think it's an important distinction where the chickens have come home to roost, Bobby Boucher. And we're saying, hey, we weren't actually able to do this. It was management saying we wanted to do it. It was a placation. It was buzz words, definitely.
So now the reason that the management and boards were doing this all this time is that there's going to be a very specific pulling away that, as Jordan said, there's the Blockbuster there. The Blockbuster equivalent of there's companies who maybe have the data, maybe are walking around saying they're data driven at conferences and such, and up on their website, to their board, to their shareholders, but you will see it in their numbers that there will be a very specific pulling away and a differentiation, a key differentiation, between the companies that actually do this right, do this well, correctly, and those that don't.
And that won't just be a lot of talk from their boards and their shareholder meetings. These are actual numbers. Revenues will go up, cost savings, those sorts of things. And we saw this especially in Covid era, that the companies that were able to look at the data were able to see changes. And I can't stress this enough. There are changes that are happening right now. I think that they were happening a little bit before Covid, and now they're being even more cemented and accelerated by Covid. Changes in consumer buying habits, consumer changes that, by being data driven, you can actually see, oh, there was this change. Now this change is really happening.
And the companies that are operating on, let's say, even five years ago of perceptions, what they thought was happening, that's changed already. 10 years ago, even more so. So we really have to be data driven, not just saying we're data driven, but giving the results, giving the people, putting the effort in.
Interesting. So a huge difference between talking about it and substantively actualizing that in your enterprise. That was a great clip. So, I was a big LEGO fan when I was a kid. In fact, I wanted to spend some time during Covid playing LEGO. Never did it, but we have the next guest, the Chief Data Officer at LEGO, Orlando Machado. How did you become acquainted with Orlando?
I also met Orlando for the first time on the podcast. I've, of course, been a fan of LEGO since I was an eight year old little boy. And in fact, if you look on the YouTube channel, you can see that I still play with LEGO. In fact, I've shown how distributed systems work with LEGO.
Oh, wow. Perfect.
Yes. So it brought a smile to my heart being able to talk about LEGO and deal with somebody who is dealing with data at LEGO.
Love that. You have a clip from your interview with him. So let's take a listen to that.
Orlando: I think encouraging people to experience the brand in the way that customers experience the brand is always extremely important, whether that's shopping on our website, whether that's shopping with a partner, or whether that's actually playing with products. So it's fantastic that we can, within the LEGO group, encourage people to play with our products as part of their job. And it's a huge perk for everybody working here, but there's a serious side of it as well, because I think, without trying to understand how real people engage with you, I think you've got very little chance of trying to come up with real customer-centric innovation.
Jesse: It's interesting you mention that, because I'm experiencing that with a client right now. Nobody’s went through the customer journey. They're not really dogfooding. So let's say I'm a CDO, let's say I'm a manager at a company where it isn't as cool or fun to play with as LEGO. How do we get that customer focus or people excited about going through that customer journey?
Orlando: I think the tone needs to be set from the top. I think there is no substitute for senior members of staff, the CEO, the executive team, role modeling, that behavior of really trying to obsess about the customer experience. And also don't forget, the customer can mean many different things. We can be in a business to business context where the customer might be another company, a partner, but always trying to obsess about the way that other people experience your product, your brand, your service has to be role modeled from the top.
It's perfect that the CDO of a brand that literally requires its customers to be hands on is reminding us in this great clip you chose for the need for the whole team, top down, to really engage with that customer experience. I love that term of obsession, obsessing over the customer experience. So what made you choose this particular clip to look back on?
I think it's important for data teams to be quite obsessed, quite obsessed with that whole customer journey, where you may think, well, I'm a data scientist, I'm a data engineer, I'm an operations person. What can I do for that journey? What does it matter? Why do I even care about this customer journey? And I would say, no, you're actually really core to this customer journey. And you could say that certain parts of the data team needs even more of that customer journey and understanding and that obsession.
I would go so far as to say a data scientist who doesn't understand that customer journey is not doing you very much good, because if they don't understand that customer journey, their analytic, or maybe their discovery is faulty because they don't know the various steps that are part of that customer journey. They don't understand that mindset during the customer journey. So it's really key. Data engineers, likewise. It's very important that they understand that customer journey, perhaps not to that level that a data scientist knows that, but if they're designing some sort of software, they'll need to understand that. Or on the ops team, very similar. What is the pain of our customer, or during a customer journey, if that system's down? This is where that operational excellence really takes place and really gives us that benefit.
So it's really key that we as data teams think about this and obsess over this. But it comes from above, and I completely agree with Orlando on this. I can talk to a team, a mid-level team, mid-level management, individual contributors about this all I want, but in the back of their mind, they're thinking, okay, well, the CEO has never bought our product, has never played with our product, or is so far removed, what does it matter? So it's really important that the customer focus, the customer obsession with our journey starts at the top. And that will trickle down where everybody at every level is talking about, what is that customer journey?
And I would go so far as, you heard me ask that question of saying, hey, sometimes we don't work at some place that's as cool as LEGO or as tactile as LEGO. What do we do then? Well, we still need to endeavor to have looked at that customer journey. I know I personally do that as much as I can. For example, at one of my clients, I went to their warehouse. That was part of the last mile of that customer journey. The customer has placed their order in that case, but where does it ship from? How does that ship? What does that warehouse experience actually look like? Because if we put the best site together, the best product together, whatever, but we don't get that from point A to point B, point B being the customer, we've got a problem. So it's an obsession all the way through, of what are we doing? How are we getting the best possible customer experience?
I love that you went to the warehouse. Going the extra mile. Let's move on to your interview with Zhamak Dehghani who founded the concept of Data Mesh. How did Zhamak come to be on the program?
I had been reading even more about Data Mesh, and what I really wanted to do was create a space where we could try to remove some of the fluff, some of the marketing spin on this, and really have an in-depth discussion, not just from a technical perspective, but I really found Zhamak's consideration of the techno socio part of it - the socio part being people - I found that really interesting. So I wanted to give her that space to be able to talk about it and to talk about the people's side as well.
Let's listen to this clip.
Zhamak: Of course, technology is an enabler, but it's just a means to an end. Ultimately, the purpose of the technology is empowerment of the people in the organization, and the top of that hierarchy is getting value for our customers, our partners, optimizing our products for their experiences. So, I think we have to have a bit of a top down view of the situation, not so much this bottom up view. The bottom up to technology is, technology driven decision making is a very bottom up approach in terms of, yes, we need these enablers, but for what purpose? And people, you know, are a big part of the ecosystem of the organization.
She's really getting to the heart of things, isn't she, when she says that business is about people, it's not about technology. Ultimately it's always about human beings.
It is. I've talked to many people and especially, it's a speech I've given to many data teams, and I've said, okay, you're focused on technology. Spark, Kafka, whatever you wanna call it. Pulsar, whatever technology we have at hand. But have you ever seen a technology actually make it into the S-1 filing? The S-1 filing being, for U. S. Publicly traded companies, that's the filing that says, here's our revenue. Have you ever seen that? They give an update on the company in that. Have you ever seen a technology called out and say, "I'd like to throw it back to Spark that enabled me to." You don't see these things. You don't see the data team called out. You don't see these technologies called out. So this is what's key.
We, as technologists, may be thinking, oh, I love that Kafka, and I love that Pulsar, and I love that Spark. Yeah, that's us. But as Zhamak is saying, even though she founded this concept of Data Mesh, it's about business value. It is key that we have business value from these technologies. It's people doing cool things, people being enabled, but people being enabled creates business value. This is a key thing.
People who are listening to this, managers who are listening to this, oftentimes they'll put a technology in place and say, okay, we're done. This happened a lot with Hadoop clusters back in the day. Set up that Hadoop cluster, wash my hands of this, I am done, we are going to create massive amounts of business value, thank you very much.
Mission accomplished.
Yeah. Mission accomplished, right. Banner right behind them. And you know what happened? Exactly what you might be thinking. It didn't go anywhere, because they focused on the technology. They had no plan for business value. They had no plan for people. They were completely missing the people. Or they had the people, but the wrong people.
So this is, I completely agree with Zhamak on this one, we have to create business value, have to create this, you have to have the right people. And I did email Zhamak. We may have her for a second round, and I'm so excited about that, because it will be a great time to talk even more about Data Mesh.
Now let's listen back to the interview that you did with author and Netflix data engineer, Holden Karau. How do you know Holden?
I met Holden when she was at Databricks. Very first time I met her, she was guest speaking at a class I was teaching, and I think it was from that moment on, we basically stayed friends. So I've known Holden, she's met my family, and I really enjoy being around Holden. Not just because of her frankness, but she is one of the more genuine people that I know. So, hi, Holden!
Big fans of Holden. Now let's listen back and get the reaction to your question: whether she thinks smaller companies should just copy what the big tech companies are doing with their data. I'm really interested to hear her response to this question.
Holden: Oh God, please. For the love of your operations team, for the love of your budget, for the love of just like good engineering practices, do not copy what Google is doing just because they're doing it. Like, I love bigtable, don't get me wrong. It is an amazing tool. And it is the wrong solution for almost everyone besides Google. Right?
I think there's some great practices worth copying, and like, code reviews and there's certainly some cultural elements that I want to copy from my different employers that I try and remember and bring with me. But frankly, you are probably not at the scale of Google data wise, right? And if you are, that's cool. But you're probably not there, right? And you probably don't wanna structure yourself in the same way. You don't need to have multi-DC failover if you can take the occasional downtime, right?
I really appreciate how frank she's willing to be there. And I hope that in season two, we'll hear from more engineers with diverse backgrounds and types of companies they've worked for, because listening to that interview, Holden clearly brings a great deal of experience with both best practices and obviously some worst practices. So tell me why that clip stood out to you.
Well, frank is how I would describe Holden. She is one of the people that I enjoy who doesn't hold back, whether you're talking privately or she's being recorded. Boy, she will let you know what she thinks. And I really appreciate that about Holden. And this actually came from a conversation she and I had a while ago, but I obviously didn't have it recorded.
And here is the situation that happens: a manager will be in a conference, and one of the big tech companies is there presenting and saying, okay, here's a slide, and here's our architecture. And said manager takes a picture and says, I want this. And that is the start of a major, major problem.
And I wanted somebody who's actually been there, who's worked at Google, she's worked at Apple, she's worked at these various places, to be able to say, hey, no, this isn't what you want to do. I somewhat disagree with her on the whole bigtable. I think, depending on the size of your data, it's a great product. But you don't just say, oh, that's how Google did that, I'm gonna copy that. So that's definitely not what you want to do. What you want to do is to have people - hey, we're talking about people again. Harkens back to the last question or the last clip we just did - I talked about this with many other places, with many other people, Holden included. You wanna have a talk about technology. We'll actually spend more of our time talking about people.
So maybe if you're sitting there thinking and listening to this podcast, thinking, well, what do I do? How do I prevent myself from just copying Google? What do I do? You have the right people. So, you get the right people in the right seats and the right team with the right skills, and they will help you create the technology, and they will help you create the architecture, and they will keep you from just blindly copying Google.
And I like the point that Holden made; there are things that you want to copy from Google, but it takes the right person with the right knowledge to be able to say, oh, that's the right thing then. That's the thing that you actually want to copy, and that's the thing you want to do.
I love that. Inspired by, maybe, rather than dictated by. Next, we hear from Harvinder Atwal, author and chief data scientist at Moneysupermarket Group. How do you know Harvinder?
I first met Harvinder doing some of the research for my book, and it was interesting because he wrote not quite the same book, but I would say the two books are very complimentary, where he was talking about out, how do we do data ops? I was talking about it more from the management point of view.
So I think it was Chris Berg who originally put us in touch with each other, and Harvinder and I got on very well. We've met in person. He was kind enough to be the technical editor for Data Team. So I really appreciate all of Harvinder's support and work, and he was happy to do the podcast as well.
Hmm. That's great. So let's listen to this clip.
Harvinder: So the summary there is: try lots of different approaches to how you structure teams. The truth is, there's no perfect way, but the one I've kind of settled on for our organization is you have domain-oriented teams, longstanding there's a function, but they do, those teams and those functional specialists do need to be tied together, so that you are ensuring the best practice is spread across all those teams.
Jesse, does his insight there match your experience with Data Dream Teams?
It does. I completely agree with his domain oriented teams. One of the more interesting insights I had with writing the Data Teams book was not just confirming some of my own preconceived notions, but also seeing some new trends that I started to see as a result of talking to people like Harvinder and others. And that was around, what is the highest and best usage of our teams and our people? Or how do data teams achieve their highest value or highest output? And it's around these domain-driven teams.
So our teams aligned so that they're a whole group, a whole unit, able to, from soup to nuts, everything that is part of a data product. And I think that that harkens back to some of Zhamak's Data Mesh parts as well, where, how do we create teams that are aligned around a data product? And I think it's this way: we have all of the people that we need in that team so that there isn't this organizational friction to go across teams.
So what will happen is - and once again, I should say, this is an advanced part. This is not here, let's start and let's go from zero to a hundred, and we're going to do this right straightaway. This is a friction that you'll have later on as you get more advanced. This is the manifestation that you are making progress there.
And so the manifestation there is, your biggest hindrance to doing what you need to do is not "This person doesn't understand this. We're lacking this part of infrastructure." Your friction is going across teams and having competing resources and competing things that they're trying to do. So that's a difference there. And that's what Harvinder is talking about. So, completely agree and have completely seen that in the real world as well.
Yeah. Great clip. Now let's tune in to Gwen Shapira, former engineering leader at Confluent, and she's now I understand doing a stealth startup. How are you acquainted with Gwen?
Gwen Shapira and I first met when we were at Cloudera. In fact, I still remember the day that we met. I was in Cloudera's headquarters. I worked remotely, but I was there for a meeting, and I poked my head up, and I was in an area where my team was, the training team was. And I wasn't expecting her to be there, and so I was chatting with her, and I poked my head up and said, "Gwen, is that you on the other side of this?" So we just happened to be sitting on the other side of this group of desks. And we've been great friends ever since. She's definitely one of the people I really miss. I miss working with her on a daily basis, and I do hope to work with her again someday.
And she offers her perspective about what leadership of people who are building large data systems looks like day to day.
Gwen: On a daily basis, it obviously means that you need to have really good people. And good people can be from all levels of experience. You need some people who are very experienced, been there, done that, saw all the problems, know what not to do, know which pitfalls to avoid. And then you really need some general people with just a lot of energy, a lot of drive, who want to learn how to do amazing things. So you kind of need this very balanced team.
And the thing about large systems is that they're complex by nature, and you really don't want to make them more complex than needed. And I do think that teams need some guidance around it, and it doesn't necessarily have to be from me.
I appreciate any insight ever about the ability to delegate. That's valuable for all of us. What was your takeaway there, Jesse?
I think there's two parts to what Gwen was talking about. And oddly enough, we have a theme of people. If that wasn't clear to everybody, hey, it's really key to have the right people. You've heard it from several of our guests already. And the other part was where do our junior people fit in there? So let's start with our people. Can't stress this enough. If you don't have the right people, as Gwen was talking about, it's really, really key.
You really won't get very far without the right people. So if you're a manager and you're listening to this podcast and you're thinking, I don't know if we have the right people - that may be your inkling, that you don't have the right people, just just saying - but if you are thinking about, oh, I want to start, you have to start with the right people. So I'll share this as an experience. When I go to consult with a company, the first thing I'm looking at is the people.
And what I worry the most about is when I come in and there's people problems within the company rather than technical or process problems. And those people-problems are by far the most difficult to deal with, because those problems started years ago. And it's going to take more than just either finding new homes for those people or something like that to solve this. These are much more difficult to solve. So really think upfront about your people.
And then she brings up another interesting point about where do our juniors fit into our data teams? Personally, when I was talking about my ideal team with Paco's clip, I was talking about, I want those tiger teams. I want those alpha teams. And the issue with alpha teams is they're mostly senior people, quite honestly. So then you have this whole issue of, you have this group of senior people who've been there, who've done that. And they may be either locked in their thinking, or they may not want to do the less desirable jobs, to put it nicely.
Some of what we have to do in data is just quite frankly, slogging through something, something that's nails on chalkboard, something that's stupid, something that you hate doing. And you know what is really nice to have is somebody who's eager to do that stuff, because they've never cut themselves that way. And so you've got your eager faced intern or your junior person.
I still believe that we skew seniors for data teams, simply because especially on the data engineering side, you're going to need mostly senior people in my opinion still. But you will still need some of those junior people to help even out your team.
Yeah, absolutely. And finally, our fearless leader, Maarten Masschelein, Soda Data's CEO. How did you become acquainted with Maarten?
I met Maarten for the very first time at the podcast. That particular episode was relatively ill-fated. Maarten had just had Covid, and he was a trooper for doing that.
It's devotion. Let's take a listen here.
Maarten: Ultimately, when you have data products, data products are fundamental to becoming data driven and to doing data driven or data-informed decision making, as well as automating with data. We increasingly automate with data. We build recommendations, right? For example, if you're an e-commerce company, you're pushing recommendations, well, that's an automation with data. And that creates revenue, right? So it's top line.
Given that, what observability does, it makes sure that you know about problems in that data before anyone else does. SRE, Site Reliability Engineering, we do exactly the same in software, ultimately. So this principle of making sure you can get ahead of problems, that will cause a downstream issue, whether that is, I cannot make a decision, which happens. I've been in that situation, actually, very recently. One of our data products failed, and I couldn't make a call. It was not the worst, but still it was, annoying to say the least. All the way to the worst type of problems or data issues, which is, you make a decision on faulty data.
So observability is all about helping you get ahead of problems, handling them in an easy way or smooth way before they do any downstream problems. Which, if you do that, if you adopt those principles, you actually spend a lot less time operationally - doing the day to day, being reactive, all of that increasingly will go away, and you'll be able to focus on building the new things that regenerate business value. So that is how I would describe it in a couple of minutes.
So observability is key. What was your main takeaway from that, Jesse?
I completely agree on the observability part. I think there's two other parts. So let me reiterate the three keys I see: observability, automation, and data products. So let's kind of rewind back to when Maarten was first talking, that is, he started with data products. They're key for being data-driven, is about what he said.
So rewinding back to a previous clip when we were talking about that whole being data-driven, well, if you are telling you are being data driven and you don't have data products to back that up, that's the chicken and egg sort of thing is, I can't do any of this cool ML, any of this cool whatever until I have a data product to start with. So that's really key. So if you're telling me you're data-driven and I walk in and say, "Show me your data products," and you don't have said-data products, then I know you're lying or you're misinformed. So, really key there.
So we start with that data product. Once we get that in place, then we start to automate that. And when we automate that, we're saying a person is not going to manually be taking this out of an Excel spreadsheet, for example. This is data. Data is going to come in automatically. Let's say it's a dashboard, let's say it's a data product. The data for that data product is going to come in automatically. Key, you know, big, bold. If we were reading this.
Red blinking lights here.
Automatically, this is the part of a data product. We do not have people pressing buttons to bring in things, data products are created automatically. So we get to this point and I think this is Maarten's not just overall point there, but also the whole point of something like Soda Data is, okay, so we get this data product and we automate it. And we get to the point where this is just so key, so incredibly crucial for a business. This is what data-driven means, that if that data product goes down or starts having bad data, we get these just massive ramifications elsewhere. This is how we know we're data-driven.
So what we need to do is we need to prevent that from happening. And that's what observability does. Observability gives us the ability to say our data is correct. All that effort we put into making that data product, all the effort we put into the automation is actually working correctly, because our data observability tool says it is working well. So this is key. This is really key. If we're going to put all this effort into this, that last mile of data observability from companies such as Soda is key. That gives us that peace of mind, knowing, yes, this is working right. The data coming out is correct. We can rely on this.
Jesse, I have a question for you. Tell me what you're most excited about. What are you looking forward to on the Data Dream Team podcast?
I'm excited about a few things, honestly. I'm excited for my message getting out even more, so more and more people are listening to this podcast. That's really what I was setting out to do. I'm excited for the product value, going up even more. Hopefully you all can hear that we've upgraded various things. I've upgraded my microphone, I've upgraded this. We've got you as the executive producer and your team behind you. We're gonna be putting out even better content. So I'm excited for that. I'm also really excited for the guests we have coming up. We're not playing it safe on the guests. We're gonna have some very interesting guests. Hopefully some of them will be controversial in what they say and what they think. So I'm excited, and I really am looking forward to seeing what happens, getting this message out. Let's really talk. And let's really say, here is what management needs to know.
Well, we're excited to be working with you too. That's a great note to end on. I love it. Jesse, this has been so fascinating to look back at season one, to hear these voices, and reacquaint ourselves with the wisdom that you facilitated for listeners last year. We're excited to begin a new season, and we're so appreciative that you're with us today.
Listeners, we hope that you have enjoyed this look back on season one. You can find all the episodes we listened to today linked in our show notes, and you can obviously always subscribe to our feed and find all the episodes there. We'll also link to Jesse's book and website in the show notes as well.
Next week, we'll be back with a fresh episode. And this season, we're going to bring you two Data Dream Team episodes each month, featuring conversations with a stellar cast of leading data practitioners, experts, and data glitterati. Each episode will cover in depth topics for data teams and data management.
You can join the conversation in our community on Slack. That's soda/community.slack.com and visit dreamteam.soda.io for additional content, books and interviews on building and enabling data teams.
