Our season finale welcomes Soda’s CEO and co-founder, Maarten Masschelein, to the guest seat to take a look back at the first Data Dream Team series. Jesse and Maarten will share a few of their favorite takeaways, lessons learned and how they apply them, and of course what makes a data dream team.
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.
My guest today is Maarten Masschelein. Maarten, would you mind introducing yourself a little bit more?
Sure thing. Let's start where it all began for me. I grew up in an entrepreneurial family. The benefit of that was that I got very early access to computers. So in my life, there's this kind of pre-computer era and this post-computer era, and I was about seven or eight years old at the time. So, and that really was for me almost at a point of no return, because as from that age I spent loads of time on computers. At university I decided to go deeper into software, into data. And during my first work experience, I kind of complimented that and learned a lot more about the people and process. So, bit more of the software skills, which you hardly learn at school. So that's a bit of my past and Soda is where I can bring all of this stuff together.
As a company we're offering software to modern data teams so that they can better manage their data. And a big part of what we do in our vision is all about the democratization of tools. So we wanna make sure that everyone that uses data can be involved in understanding if that data is actually correct, reliable and fit for purpose. So we have a team that's kind of on our way to almost 40 employees now, and we're very happy to work together with some of the most amazing kinds of brands out there to help improve their data management processes.
And we couldn’t have done this without our partnership, so thank you so much Maarten and Soda. So the thing that we're going to do in this podcast is, we're going to do a retrospective on the series that we've done so far. And in this season, our first season, we've had quite a few different, interesting conversations and you and I are gonna look back at those conversations and see what sort of application we can get out of this.
Thanks Jesse. And it's a pleasure to be here, being an avid listener of the show ever since it first aired. What is it now, almost two months ago? And I'm really excited to be here in the seat that has hosted some fantastic guests like Holden, Zhamak, Paco, the lineup so far has been truly amazing.
Yeah. I've been really proud of what we've been able to do and what we've been able to talk to. So it's been a lot of great conversations. So you, you and I both have a lot of experiences you've mentioned in the introduction. What does the data dream team mean to you? What do you think are some important factors on this journey?
Right, right, right. I think in general, like building dream teams, that means a whole lot to both myself and my co-founder. Tom and I were on this continued quest to do just that at soda. So talk about it in the general sense, and then we can apply to data. But for me in general, building a great team, it starts on the one hand with the individual, like being highly skilled in a domain, experience, ideally some battle scars, to having generally nice people around, with good balances between EQ and IQ that ideally thrive in a culture of accountability is for me, what describes a great individual as part of a team. But to become a great team, I think there's of course much more than the individual. I think, there, it is important that you have a diverse and kind of complementary set of skills that you have a clear common purpose.
I think that's very often forgotten, but a clear common purpose. And then that you get empowered to achieve ambitious goals in line with that purpose is I think what is really, a great team. And then you could think, okay, what makes them even the next step, a dream team? Because I would say that's even a level further. And I think there, at least what I've witnessed in my career is, it requires on the one hand strong leadership, but it also requires strong operating principles. And I think that's really where dream teams differ. They've really defined a way of working, that they hold each other accountable to and where there's also room in that team for personal growth and development. So that to me is why I see it as a dream team definition. And if you apply it to data, I think all of this holds, but I do think that today in data there's a lot of confusion as to what are now all of these different kinds of people in roles. What are those skill sets that we need exactly in and how do they all work together? What are those operating principles? I think that is where there's still a lot of information to be shared and things to learn for teams.
I think one of the benefits of being a vendor and, in my case, being a consultant to data teams is we get to see a lot of different data teams all at once. So what do you think - what have you seen your customers do that has allowed them to use their data best? And what role do you think sort of plays in that?
Well, I think that, there's organizations kind of - they're organized in different ways. But how I recommend organizing and some of the successes that I've seen are similar to how you would organize modern software teams. So for companies that have been digital since inception, this might not be a big change. However, if you're not digital native there might be a bit more kind of change management work to do, but ultimately I think modern software teams, they're typically split into two key responsibilities that report to senior management and reporting into one person is important there as well, which we could talk about later for escalation paths, but it's a product and an engineering kind of organization - whereas product will define what problems will tackle and why, and then your engineering counterparts will decide how to best solve these problems. So what and why is the product and how is engineering - and product teams, they're typically more customer experience obsessed, while engineering teams, they more innovate around how to solve problems in the most optimal way that it's easy to maintain, etc. And that creates a great symbiosis. And I think what I've seen modern data teams, it’s companies that are doing very well in my opinion - they adopt this kind of organizational structure, in which they build data products. You have your product manager as part of the product organization and then an engineering team that builds, but also maintains and is on call for kind of the how that is delivered to the end consumer.
You mentioned that you've been listening to the podcast all along and of course I've been doing the interviews, we've hit somewhere around 800 minutes of conversations and over 3000 downloads and the big thanks to everybody who's done this, including you. Let's talk about our takeaways from each episode, let's start off easy. What was your favorite data dream team theme tune as selected by a guest?
Like for Daft Punk? I love the music.
Tell me about why you like Daft Punk so much.
Oh, that's a difficult question. It's - the music ultimately I think has an extremely good vibe. It's one of those types or they have a couple of songs that really make you feel happy when you listen to them. So I don't really have a direct connection to data, but it's definitely one of my top songs when I'm enjoying life with friends.
So in this case, we're talking about harder, better, faster - how would that be a good one for a data team then?
Well, in data, but also in software, what we're trying to do is we're trying to address business needs as fast as possible, but also in a reliable way, in a way that is properly controlled so that we don't make any mistakes. For example, that we, you know, there's no reputational risk or what have you. So I think harder, better, faster, stronger is what we're organizing for. Right. We wanna deliver data driven capabilities at speed at scale. So, I think it very much fits into that thinking.
And which one of those episodes are you gonna have on repeat and why are you going to have it on repeat?
I would say it will be Zhamak’s data mesh episode. Uh, I think the main reason is really because I'm now in the process of kind of going through her work, interpreting it. She has a couple of hard kind of concepts in there that at first when you read, it's like - Hmm, okay. That's, it's a bit theoretical in a way, but I think what it invites everyone to do is think about what that means to them and how they can put that in practice. So I think that's one and I also enjoyed the back and forth between you and Zhamak, had to chuckle a couple of times during that episode. So it's definitely my favorite so far.
Yeah. That one was definitely one of my favorites too. And I think it was because Zhamak had such interesting insights, something knew and that she was combining technology and teams kind of like I'm doing. And so I really appreciated that and she was very open and honest and interfering. So yeah, that was definitely my favorite episode.
Is there anything from any other episodes that you think has definitely worked while kind of bringing back up or that you may have learned from your perspective that was maybe kind of shocking or new or something you've added to your toolkits?
I've been chewing on Jordan's data literacy because usually when I'm working with the data team, we're trying to push data out, but I hadn't thought as much about the receivers as much as I should have, the people who are going to try to be data literate. So I've always talked about, we should not necessarily be doing, democratizing data because I think that kind of throws a big problem out and nobody's catching that ball here, let's throw this ball data's everybody's problem, which means it's nobody's problem. So I thought Jordan brought a good way of talking about that and saying, well, let's set certain people up for this. Let's make it their job. And that's what I've always advocated for.
No, I agree. And I think there's increasingly in data teams, we're thinking much more about what are end consumers, that person that's typically internal, for example, viewing reports or using a data product, how do they want to consume it? And I think that thinking comes from product thinking ultimately. So we're treating it much more as an internal customer and we're kind of obsessing about, okay, how can we make it easy for you? And is, I think overall, a thing that's happening to the industry.
So we've asked a consistent question, I'll ask you that question as well of what's the hardest role in a data dream team. Often people said it was data engineer or analytics engineer. What's your take there?
I think the hardest one probably will be the product management role for data because in a product management role for data, ultimately you're responsible for the entire life cycle of the data product, which means also early on it's about really capturing and understanding the business requirement to problem the ability to build a team around and bringing that into something that we can technically implement and maintain. And then again, kind of obsessing about that end user and how they're consuming it - if that is the right experience, is it delivering what it's promised to them? I think personally it is probably the hardest role, especially in machine learning or like an AI context where you have to have, as a product manager, enough technical depth to be able to have a good conversation with your data engineering counterpart, for example. So I think that's a very exciting job and also a bit of a newer one. I think data engineering is probably the most technically complex one, but it is one that you can quite easily, I think, get into, for example, as a software engineer and an analytics engineer I'm excited about, but I don't feel that that is necessarily the hardest one today.
Excellent. What type of leader are you?
I would say I'm more of like a coach-style leader. For example, we have introduced a system of OKRs - objective key results, if you know the framework - and it really allows you to share on a very regular basis what the company's strategy is, which is approved also, or agreed upon with the board Exco, etc, and then enable everyone to come with ideas, how to get there and then coach them, see it all the way through, is I think my style, at least that's the one I've adopted and I really like and enjoy. So, yeah. And that's working pretty well for me. What type of leader are you, Jesse?
I would say I am a benevolent dictator for life. In a sense that I would be more of an executive, more of a coach, more of a CDO, a chief data officer. And that's usually what I, when I'm consulting with a company, that's kind of what I'm doing and it's coming in as a CDO and helping them sort things out.
Got it. I like that, benevolent dictator.
For life.
Important, for life. So here's a question. I know that you're a strong advocate of not following what other companies do, just because it's for example, a Google or just because it's top of their markets. So I'd love to hear what you think is a good place for a company to get started. So what are the bare bones really of a data team?
Organizationally it starts with making sure you have your data engineer first, then expanding to data science and operations as you get production. But it's also figuring out what an MVP is for your company. So let's imagine you're a startup, you're just starting this out. What is that MVP? What is the simplest thing that you can do that will start getting you value? Because oftentimes companies will say, we're going to start, but we're going to go to zero to a hundred kilometers or a hundred miles per hour, just right off the bat. And those companies fail. So I talk about crawl, walk, run in the book that crawl phase is really important. It gets you set up so that you can start running, but you don't initially start running. You will fall flat on your face. So your bare bones is figuring out what is the minimum viable product. Maybe it's a data product, maybe it's a report. And then you go from there, you start showing value.
Question to you, Maarten - what are some of the great data myths that you've heard?
Oh, there's so many. I think one of the greatest is, I think, around MDM - so master data management. When I first got into the data space, it was about, it's now,11 years ago. And already then this was a big thing, right? The single source of truth, for example, a customer. So getting that 360 degree view of a customer so that you can improve customer service, create up and cross sell opportunities and many more very clear business goals. However, if we looked at how technically that was addressed it was very often kind of went into, you know, we need to centralize data, we need to create a unified canonical model and we need to manage that as a central team. And that thinking to me is, you know, that's outdated and it never really works. It has never really worked. Or at least as far as I've seen. Especially in a digital age, you have to be able to innovate fast. We talked about harder, faster, stronger, earlier. That's what you need to be able to do. And the more dependencies or kind of central control units you create, the more you're slowing down. So I think for me, at least MDM as to how we thought about it, technologically, how to achieve that is one of the greatest data myths.
So what do you think are the tools and tech to support new roles, new team structures and new approaches?
Right. So the bulk of the tools that will have a major impact on data teams, in my opinion, are the tools that have a certain level of sophistication yet are very simple to adopt. So that's kind of one characteristic. They should empower, I think, ultimately a data engineer to hand over responsibility of something they're doing today into the different kind of business teams that are increasingly managing and consuming data, because I think there's a big lack of tooling today to help data engineers ultimately enable them to take away pieces of work that they ultimately shouldn't be doing and giving that back into the different business teams. So in general, you kind of label these self-serve tools. And I think the first incarnation of that type of tool was probably late 2000 Tableau, self-serve BI tools became mainstream. And we haven't truly looked back. You're seeing the same thing now recently with more of the traditional data management tooling. I think, for example, how DBT is transforming data transformation or what we are doing in observability. I think the core of that is it's enabling the end user within a certain domain you could say, or part of the business to be fully self-served and to take away a piece of work that the data engineer is doing today, and shouldn't be doing and making kind of that self-serve I think to me, that thinking kind of will, and those types of tools will make it. And the next eight to 10 years will become kind of the types of tools that help support new team structures, which are much more decentralized, go faster on their own with data. So, I think we'll see a continuation of that trend.
Now you mentioned data observability. We have a podcast where we're talking to management, why should management be interested in data observability?
Right. Ultimately when you have data products, like data products are fundamental to becoming data driven, right? Into doing data driven or data informed decision making, as well as automating with data, right? We are increasing the automation with data. We build recommendations, 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 a top line. So 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 it's 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 too worse, 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'll actually have a lot less spend a lot less time operationally kind of 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.
Good. We've heard a lot about unlearning and changing behaviors to adopt a new approach to building data teams. I know you're an advocate for data mesh and data ops. Is this how you'd recommend teams be organized to gain the most amount of value from data?
Well, I think every organization can benefit from, kind of, studying frameworks, but I don't think you need to just take them on phase value. I think you, you should really, whatever you feel or think about - Hm, can this framework help us? - you need to analyze it, interpret it, maybe summarize it and then map those against the things that an organization is looking to improve. And I think if there's a match there, then by all means, I think you should go for it. I think ultimately these types of frameworks give, it's like a mental model. They describe this type of paradigm shift that we ideally will move towards. So there's a lot of value in that, but I think it's very important to make sure that when you're doing something like this that you first and foremost have the executive buy-in because you're asked to change a significant amount of things you're asked to change. What are the roles that you have? What is responsibility associated with each of these roles? How do they work together? What tooling do they use? These frameworks typically cover both the social part as well as the technical part. So they go quite deep and I think they can only be really successful as well if you implement them to a certain level of depth. So yeah, I would say by all means, study them, see how they can help you. And then also don't forget to get a buy-in because they can be quite transformational.
So continuing on with this podcast, we're going to do a new season next year. We don't play favorites on topics or guests, but what would be a topic that you'd like for us, or really want us to cover in the next season.
So I'd be very interested in diving deeper into how different organizations, data teams work internally and kind of what are some of the pros and cons or the lessons learned from that way of working is, I think, what I'm very kind of interested in. So it would go into questions like, okay, what are the roles in your data team? What does everyone do? How do they work together? How do relations happen? In my mind that is very interesting. Especially as many organizations are thinking about how to structure and organize, but I'm not sure for you Jesse, like who was maybe a guest of choice for this series for you?
I'd have to go back to Paco because he inspired me to take up a lot of this work - and so I have a great respect for Paco, not just as a person, but in his technical abilities. So always a big thanks to Paco for that.
Right. And if there is one take or two or three things that you want listeners to take away from the series, what would that be, Jesse?
I think it's the theme that I've tried to do in my work as well as on this podcast. And that is, management and organization is just as important in technology for data teams. And perhaps the second one is, if you're having organizational problems, they don't write themselves automatically, or just by chance, it takes a concerted effort to fix organizational problems within your data teams.
So Maarten, thank you so much for your partnership on this podcast. It provided a great value. Thank you so much to everybody who's listened, it’s been a real pleasure. When we started out on this podcast, we weren't sure how much it would resonate with people to be honest. But what we found through looking at the metrics really resonated with people. And I want to give a heartfelt thanks to everybody who's subscribed and continues to listen, because I know it's an important part of how we're going to create value with data, to what now and in the future.
Indeed, huge thanks to guests and listeners, but definitely just to you as well. Thank you for hosting this season. It has been amazing and I'm really looking forward to seeing what next year, the new season will bring just as well.
Everyone, a big thanks to Maarten and Soda. Thank you so much for sitting and please don't just listen, actually put this in practice and I'll see you in the next season in 2022.
That was great! So informative, refreshing, I loved it. Remember to check dreamteam.soda.io for additional resources. We’ll meet you back here soon at the Soda Podcast.
