Hi, everyone. Welcome to More Than Numbers Live, a show focused on turning data teams from support functions into engines of growth. I'm Ollie Hughes. I'm one of the cofounders of Count dot co. We're a canvas based BI tool. We're all about turning data teams from dashboard factories into their organization's problem solvers. Every week, I have the joy of interviewing another data leader at the top of their game, talking to them about how they're drawing value with data in their organizations. And this week, I'm really pleased to, invite, Magnus Dahlback from, from Voy. Voy is a, one of the leading micro mobility organizations in Europe. They've taken over forty million car trips off the road. They're operating in twelve different countries, and Magnus leads a data organization there. And he's been on a big journey with him. I actually first met Magnus in a converted prison somewhere in Stockholm a few years ago. And since then, I've been we've been chatting, working through many different things. He's one of the most thoughtful data leaders I know. I'm so glad to have you, Magnus. Thank you for joining me. Yeah. Thanks for being here. Looking forward to a good and good discussion. Yeah. Yeah. I I can't wait. We've been talking about different things for a number of number of years. But I wanna make sure people get to know a bit about your background and where you are. I know that you were, done a few different roles before data. But first off, to help you understand maybe how old you are, tell us the first BI tool, the first tool that you started loving at, in in data other than Excel. Good good question. I think, it says a lot about your age, unfortunately, I guess. But, for me, it was probably QlikView back then. So I, my time as a consultant, helped rolling out QlikView at one of the big pharma companies, in their preclinical department. So I guess that was the first tool I really used a lot. Yeah. I love it. Yeah. Well, it's, you like your charts in gray and green, so there you go. Yeah. I mean, that's now not no longer the case now. The brand of boy is no longer a green is not is not a green and gray. It's a it's a nice kind of red or pinkish color. So it's a different color. We call it coral coral colored. So There you go. Yep. Cool. Between orange and pink. Very exactly. So we're we're that's good about that's who you are. Obviously, we're gonna talk more about I think about your consulting background a bit as we get into the interview because there's a lot I think you've taken from that, which, is really useful to how you operate. Maybe before we dig in a bit more, maybe we should spend a bit of time just talking about about Voy and how it how you're set up and maybe your data stack. We call it, like, show us your stack because everyone loves to know tooling. Maybe we'll start there and just just talk to talk to your your data stack for a bit. You actually created a nice slide to give on a bit of overview of things. We'll bring that up on the screen. You can talk us through it a bit. Yeah. So, these are our kind of logo stack, a bit simplified perhaps, but I think it captured the the essence on what it looks like. So quite the typical, I would say, modern, modern data stack, all cloud based. Snowflake at the core has a data lake data warehouse, DBT for all the data transformations, and, our flowing order as well. On the data quality side, we obviously use dbt as well, but also to call sync, which is tightly integrated with dbt. And, yeah, some on on the BI data science side, Steep, which is a new Swedish company in this this domain. So we started using them last year. Apart from that, Metabase, Vertex AI mainly for for ML and, Snowflake, obviously, too. And, on data ingestion side, we're heavily GCP users on on, on, like, invoice. So, yeah, PubSub, Stitch, but a number of other integrations. Yeah. Yeah. Stitch is stuck there. So I love it. I can see you can definitely see the kind of, the Nordic bias towards your data stack. You've got some some some Nordic startups stuck in the stack there. I love to see that. And, actually, also that you put Snowflake as a BI and data science tool in the front of the stack. So just the middle, it's at the front. Yeah. So, we are actually using, like, SnowSite, kind of built in features within Snowflake more and more. That's kind of beyond I mean, both notebooks, but, you know, writing SQL and so on. So, yeah, I think Snowflake are starting to provide more and more of these kind of capabilities, not just the core kind of data warehouse, but also the on the analytics, side. So, it's something where we're starting to use a bit more. And the other thing which is, I wanna I guess, is the thing I'd love to ask you is, like, you've also got Metabase and Steep. I mean, Metabase is often a kind of, I don't speak badly of a tool. It's very good open source BI tool, but it often lingers like a bad smell after the company gets a certain size. Good place to start. Is that is that what happened for you? Like, you started Metabase and then realized you needed to scale out of it as it got you going but maybe not so sufficient now. Where does it sit? Yeah. So we're actually using it from from day one, at Voya, and it it kind of serves its purpose for people that, you know, want a nicer interface to write in SQL or kind of drag and drop their SQL queries. But, it does come with some kind of governing issues once it scales. So, I think, yeah, we are thinking about what's the kind of future place on Metabase in our stack, because, yeah, lack lack of little bit of governance, you can say, around it at the moment. Yeah. Yeah. Yeah. Sure. Sure. It's it's it's it's difficult to it's very utilitarian, so you can do a lot of different things. It is therefore hard to to shift out of Fair Play. And tell us more about the team. I know that Voy itself is, like, nine hundred people, so you and you're growing very quickly. But tell us about the data organization. How have you structured that? We can dig into that more, but just give people a flavor of how the team's organized. Yeah. So we are a little bit more than twenty people, depending on how how your account is kind of part of of the data or about the we have a data platform team of of four people. So platform engineers, data analytics team of eight people, and then a machine learning, team of, six people. So that's how we're kind of for, organizing in the line or should say about, the way we work on a database is basically a hundred percent embedded into our business and product teams. So as a data analyst, you're maybe part of our, say, monetization or payments team, day in, day out, working closely with our engineers, designers, PMs, and and other people in that team. So And is that So, yeah, that's our approach we've had for for two years. It's working really, really well, I would say. We're gonna look into that a bit more later on. But is that is that, like, a matrix structure, or do they all report to you and then you've just made sure there's a very clear line of sight to different functions? No. Exactly. It's a matrix structure. So we have, still have kind of centralized data chapter to make sure that we we work in the same way and share learnings and so on, but, the data work is kinda done in in within this, cross functional teams. That's great. Thank you. That's that's really cool. I mean, and I wanna we wanna dig things this more because I know you've been on a journey. One of the things that I'm so grateful to you about is that you have helped and worked with us in the more than others community to try and build out this idea of the tenants, this idea of what are the levers or what are the activities or or principles that makes a data team valuable. And we've talked about it many times over the years, this idea of operational clarity, the idea of being problem solvers, not just report givers, and then being, you know, focusing on time to decision, not just about getting self-service going and stuff. And all these things that we've been talking about with all our different, interviews over the course of, this, this show so far has been something something that you and I have worked through. And it's been a journey for you. I know that you've been working on this, and I think you believe in these principles. You've been working to implement them. And what I'm just looking forward to sharing with the with the audience really is just the core lessons, the core things you've started to implement to make this come to reality. Yeah. And one of the things I think I wanna start with, if I can, is just the way that you think about metrics, that you've gone very metrics focused. And I wonder if you could just explain a bit more about, like, what when you say metrics focused, what is that and what is that not? Obviously, everyone thinks about metrics, certain principle behind it, which I think is really good to unpick. Yeah. No. I think, it was about, about two years ago, I was we started to think about, like, how can we, make it as effortless as possible to to consume data. And one of the reasons, we saw, like, it's not easy enough is if you think about there are typically, like, two ways of of interacting with data. Either provide access to your, tables in your in your in your data warehouse that you need to know SQL. You need to navigate in all these tables, etcetera. So it's powerful, but it's complicated for most people. The second kind of way of delivering data is through dashboards. Right? That that that that's good for many people, but it takes a lot of time from the from the data team to kind of build those dashboards, maintain those dashboards. You very easily end up in one, metric or data looking given different numbers from dashboard to dashboard, you kinda end up in this dashboard chaos that we can tend to talk a lot about in the in the in the data field. So Yeah. There must be some kind of middle ground, and that's where we'd see metrics coming in. As a kind of main main product for us actually from the data team. We that that's what we see in our metrics is our key, end product rather than than dashboards. That makes sense. So you'll see yeah. You're absolutely right. The idea of, like, if your end output is dashboards, there's a tendency to just spot or produce dashboards, and that creates this mosaic of different assets saying different things and creating that kind of informational noise that is basically the death of any data function or any sort of sense of understanding of the business. And so you're you're saying, let's not make that the reports themselves, a a deliverable. We're saying the metrics behind the report, that those definitions are therefore the key. Is that kind of the idea? Exactly. So, basically, what we have managed to build build up the the last twelve months is one common well governed metric catalog. So, instead of maybe in the past year, okay. I'm looking for, let's say, how many week else do we have in in the backlog in the issue warehouse in the UK at the moment. Okay. Try to find what dashboard should it use. Maybe I find two dashboards. And they give different numbers. That's classical kind of problem. Now it's more of one single, metric catalog. You would find the the backlog metric in there. And I think that's that's such a very powerful thing also, you know, having a metrics oriented approach is that it's if you think about it, that's our business language. Right? So Yeah. We talk about the backlog. We talk about rides and, you know, all of these things. We don't talk about dashboard names or data warehouse tables. So it's a very natural way also to interact with data because you kind of know what you're looking at. We have, yeah, we have kind of a definition of backlog. We we all kind of know what it means. So, if you see the backlog metric, yeah, I know what I'm looking at. So that's also I think has helped a lot in the in the adoption of of data generally, to to go with this approach. Yeah. Okay. That that I love it. You sort of you've you've basically made it so that there is a a common vocabulary across the whole business, and it's not based on report name or anything like that. It's just there's a common single source of truth for what a thing is and where to go find it, and that's that's pretty cool. Yeah. It's, it's it's I didn't maybe think a lot about before we we did this journey, but now I really reflect on it. This is such a powerful thing to to, embed your business language in in the in the interface use data. It's it's really helpful. And one of so, obviously, this is all linked to operational clarity, this idea of signal from noise, like, very like, the minimum amount of information to help a business understand itself. And I just, I wondered how you went about finding the metrics because often people you know, we we work with a lot of organizations ourselves, like, helping them build metric trees, getting that kind of visibility of the metrics, and helping the mapping of that to help the business understand itself. But it's often challenging. People often feel like, actually, what is the definition of backlog? Is backlog even the right metric to care about, or is it another thing which derived or similar to it? So have you got about, like, defining the metrics themselves so that the framework is that the everyone's not the same definition or the end date. You've agreed that backlog is the right operational thing to measure. Yeah. I super super important, super good question. And, to to rewind the list a bit, so when I joined Boy soon four years ago, one of the first things I did as my kind of top priority the first year is to really get control of our metric definitions. Right. So before we even kind of shift this approach in the way we expose data, we did a lot of, important work in in building up that metric catalog, but kind of offline. Who's the metric owner? How do we define this metric and so on? So then we ended up quite naturally, working with all the business departments and product teams with, like, maybe fifty, sixty metrics with, you know, good clear definitions. And then for us, it's been more about, okay, then we have a starting point and then kind of naturally you add more and more metrics. Also the fact that we have our data analysts embedded into the business teams and product teams has helped a lot because then they actually build a strong, solid knowledge of what metrics are relevant in each product domain or business domain. Yeah. So that that, I think, has been critical for us to, yeah, to come where we are now. And I everything that you mentioned there that you wanna pull out is that you mentioned how you, look for the owner of the metric. Like, it wasn't just let's define some metrics which are kind of potentially interesting or potentially, you know, paint a bit of a picture. It's actually adding ownership. Is that kind of a core part of this as well that every all of those fifty, sixty metrics, there's a clear owner. There is a it sort of aligns to the operating structures of the business? Yeah. Hundred percent. It's both like a technical owner. So, typically, the data analyst, responsible for the actual technical definition, but also business owner. And we're also kind of, exposing this in the actual interface where people use. So in in Steep, this tool that we just, mentioned. So in that metric catalog, in the same place, you actually analyze your your data, your metrics. You'll see who's the owner for this. So if you have questions, it's super easy to, you know, ping that ping that personal Slack, whatever. So, it's, all all these smaller things makes, like, actually quite a big difference, especially for people that are not, like, using data every single day. Yeah. Yeah. That makes sense. And so, obviously, you do have reports. You do have dashboards of some sort, or is it lit is that literally left to the business to build their own and it's all but they know the metrics are owned by the data team? How do you distribute that insight around? Yeah. So my my official saying is that we've stopped building dashboards completely on the data team. It's not entirely true. But, to a large extent, we we have, actually. We we we do of course, there are some dashboards that we know are widely used across the company, like, are are used by maybe fifty to a hundred people every day. Those reports, we we still build out because it doesn't make sense to have hundred people building their own kind of reports Yeah. On top of the metric catalog. But I would still say that, we have probably reduced the time spent in the data team to build dashboards by maybe eighty percent. On top of that, we also have much less, ad hoc basic kind of questions coming in. So really freed up time for the data team to to work on a bit more advanced things and maybe more value added things than coloring graphs or answering, like, how many rides we had in a certain city last year or something like that. So think people who've done that kind of organizational clarity that with the way the way you describe that, Neeslie, of, like, defining CAF method definitions of metrics than, like, a distilled set of metrics and then ownership of that and then make sure that's owned by unseen by the business, it it as soon as there's clarity about what actually how the business fits together, it just leads to that massive drop of ad hoc questions generally. Yep. Which is exactly what you described. But I was gonna It's been it's been a faster change than I had bought and expected as well, actually. So it's, I'm really, really happy with the the outcome of this change. That's awesome. Well, let's I wanna move on because there's other things I wanna talk about. One of them, as you mentioned, is now your data team have more time to do more value add investigations, and this is the whole idea of, like, problem solving. Like, your analysts are, focused on the value add work of digging in, finding insights. I I one of those thing we love thinking about is analysts being that kind of the problem solvers of business. They're there, you mentioned, embedded into these different product and business functions. Tell us what that looks like now, whether maybe that was, or maybe people could imagine what analysts are like when they're just answering ad hoc questions. Now how do they operate? What is it what's the way of working now? And and I'm not just doing ad hoc random bits and lots. So I think by having our data to, people, like, if it's data analysts, machine and engineers, and so on, embedded in these teams, the biggest difference is that you build so much deeper competence in your in your domain. So, I mean, working with data, I mean, for me, data always a business role. So you just need to have a deep understanding of the business, right, if you work with data. Otherwise, you'll be stuck in this kind of support ticket and centralized service function. By doing this change, what we're seeing is that our analysts can be much more proactive. So deeper understanding of a product domain means that you can, spend more time understanding opportunities, what's not working, what's working, and take that step to become, like, that advisor to the product manager or the business. So it's, it's, to think about it's quite basic. You guys need to spend time building business knowledge, then that comes quite naturally. I I one of those I love. It's I agree. It's kind of basic, but I I it it is that subtle shift. One of the things that I often talk about with all day leaders, maybe talk about this problem solving idea. It's like, where which who is owning the problem solve? Is it the business user who's throwing then throwing out requests for information so they can build a problem solve structure, or is it the analyst is saying, look. I'm gonna be I can do more than just give you the numbers. I can actually have you lay out thinking, structure the problem solve. And, actually, I'm I'm doing the critical thinking for you. I'm building the structure of the problem, not just the data which fill which fills it in. And I guess that's kinda what you're saying is, like, there's a Yeah. Maybe it's fairly owned. Ideally, it's a commonly owned framework, but the data analyst is actually part of that structure, not just the So I I see it more as a collaboration. If you take, like let's say, data analyst working in our product team called compliance. So our compliance team is focusing a lot on, you know, parking and and social behavior and these kind of things, building our products for that. There is I mean, this is really such a strong collaboration with with the PM and the rest of the team, of course, as well, and the data analyst in in that team where he can be, you know, be much more proactive. It's not about, waiting for the PM to come up with ideas and then execute on that come with insights, but you can really see this stronger collaboration where both do this, this kind of work. Yeah. That's great. It's a it's much more satisfying as well. Like, I find that, generally, they kind of, it just makes their the data data team people your analyst now doing what they they wanna do, that well, they love doing what they've gone to data for. So it's just a more definitely more satisfying environment. I'm sure. Exactly. And but it's also, like, depending on how big your organization is. Right? So when when let's say, in an art at a stage start up, we're a cut smaller organization, then it might make sense to be more centralized. But maybe later on, make that switch. And I think we have never regretted that that, kind of operations model. Cool. The the last thing I wanna come on is there's another, I think, novelty, which is not actually quite common even in very modern data teams. This is idea of full stack analyst that you're or the analysts are doing more than just the insight creation layer. As important as that is as we've discussed, they're actually going right back into the stack. Can you explain that how that works and, like, where how those different roles of, like, ingestion and modeling sit and how they sort of structured their time around that? Yeah. I I mean, I I know lots of organizations the last couple of years have kind of split this role up a bit. If you look at data on years, analytical engineers, and data analysts, we take took a decision to know we believe, in kind of more full stack approach to basically minimize dependencies. We believe we can deliver much faster. You have a better knowledge of of the underlying data as a data analyst if you also do the modeling of that. Obviously, it makes it maybe a bit harder to find the right talent, right, people that can do that. But, once you get there, you really see the the strength of that approach because you just basically get less dependencies. You can do things faster. It comes down to that. Yeah. Yeah. That makes sense. It it I guess, imagine it means you've got a very highly skilled data team. That's actually in a in a great way to have people who have business focused, who are also well paid, well skilled up, can do anything. It's just generally a good idea. So it's often sour when not always, but often you see data analysts, the people who are facing to the business as the lowest paid, lowest skilled people, the the the early people. That clearly can't be true for you. No. Definitely not. I mean, obviously, I'm super super happy with that. My team's super strong team, but I think part of that is is that approach that we just talk about, not full stack. But, of course, yeah, you need to have the technical skills. You now need to have the analytics skills. You need to have the comms skills and so on. So, it's definitely an an expert to go there, but, it's worth it. That's good. That's and that's so, I mean, that is a whole other kind of discussion in itself about how you get your team to become that structure, but it's interesting to hear it, and I'm glad it's working so well. Like, definitely sounds like, the place to be a good analyst is to be at that point of view because you're gonna get a breadth of skills that that most people aren't getting in the touch. Yeah. Yeah. Ultimately, I agree. That's one of the Of course you can. Of course you do. That's great. I mean, Magnus, this is so great. You've given us three really important, very helpful, very detailed explanations of, like, how you'd move the team, focus your operational clarity around metrics, problem solving, being full stack analysts. There's so much else there. But before we I wanna round out. I wanna just ask you as also back to your your early roots. Like, what's the advice you wanna give anyone who's maybe is working as an analyst or has just wants to get into data or is thinking about data more? How what advice would you give them to help them move their career forwards? Like, what's the one thing you knew as you started playing with ClickVid right at the start? I don't it's so long time ago. I don't really remember. But, no, I I think going back to what I said before, I really view the the data role. Let's say data analyst role as a business role. We we tend to talk a lot about tech and tools and, data modeling. It's all important, but at the end of the day, you're more a business person than than anything else. So have that mindset, I think. As an example, like, as a data analyst, I think you should really have a good knowledge of your company's company's growth model. How do we what what leverage can we do to improve retention? That's something that needs to be, you know, you just need to know as a data analyst. What's our unit economics for our company, for example? Also something that I think you should care a lot about and and know, inside out as a as a DA. I love it. I I I love the term. I know I know that you know this term as well, the idea of being a trusted adviser. In fact, it's one of the books on my shelf here, the trusted adviser, the Tome of Management Consultants, but also I just think so relevant to a a business focused data team as well. There's so many learnings in that. That's really helpful. Well, if it's okay, finish off, I'd love to throw you an anonymous data letter. As I as I always do with every guest I ask, I ask the community, what questions should I be asking, Magnus? Magnus, I think one of the I think the thrust of the questions I've got here, one is just because you really have elevated yourself, I think, in Voya as a as you're you're a senior director, you're very much top of the organization and and leading the team. And the question I I got was asked or one of the questions I wanted to ask you was was I on that line and moved it out to you. So the person I I spoke to, I said, I run a data team at a start up. We have influence and drive value, but I'm trying to work out my next career step. It's hard to see how to elevate my own role outside of just prioritization and management of my team's work. So I guess the question is is saying, how do I level up in seniority in the organization, not just be the manager of a data function? Actually, I'm part of the core executive team of the business. I'm really helping leveling up myself. What what's the advice you give if you have anything for that person? Yeah. First of all, I really recognize it. I mean, I've been there myself. I see a lot of data leaders still being in that kind of seat. And I I think it's a lot about what I talked about before. Like, as your organization grows, find the right time to go away from an ops model where you are centralized team serving anyone all the time to this kind of, yeah, matrix setup or embedded data people in your business, in your product teams. Because I think what will happen then, you as a data leader, you stop dealing with, like, daily or weekly task back close in your team and shift to more focus on the strategic topics, working closer with other manage managers, senior management in in the organization. How can we kind of leverage the data team even more? Where should we put the the efforts? What's mostly prioritized at the moment and so on? Not on a daily level, but maybe more on a quarterly, yearly level. So I think finding that sweet spot on when you should switch your ops model. Yeah. I mean, as you as you describe it, it kinda makes sense. We've just been talking about how to make our a data team far more business focused, far more leading to business to solve problems. As a leader, I guess the same thing absolutely apprised. The more that you're focused on just getting the numbers right, just doing the data task and managing the prioritization of that and not having an opinion about the business strategy, having opinion about the business can grow. You're never gonna be asked for your opinion. You're never gonna be doing an informed strategy and then move up, which is exactly the same principle as to apply to the leadership as it does to the rest of the team. Yeah. Hundred percent. Really really thinking through, like, we're and dare to down prioritize some business domains probably or or some some product areas. Like, okay. Yeah. This is so important. We we always have a limit to pass in the data team, but, okay, this is where we make most value out of it. I think that's it. Yeah. Saying no is basically the challenge. Leadership challenge is always saying no eight times out of out of ten. Do they really matter? Yeah. I love it. Thank you. That's that's that's really great. Thanks for answering that question so well. You've been is there anything what you're what where you at? We're obviously on a journey still. You're still, continuing to work towards the tenants. What's in the top of your mind now as you think forwards? Help people see, like, your thinking as you've got got to a certain point. What's the priorities for you at the moment? I mean, we've come really far with this kind of sub serve BI that I've talked about before, our met metrics instead of dashboards and so on. And we we have some work work to do there, and we're we're really, really happy. For us, we're kinda switching focus towards, experimentation now as as one thing. We really want to scale up, AB tests that we do. Like, let's think about, like, ten x, AB tests coming here than before. So Yep. That definitely is some some work needed by by the data team and the rest of the organization to to achieve that. And I would say the other area that we're really looking into a lot now is deeper product analytics. So have a a deeper understanding on how, users use our app, friction points, use of funnels, and, yeah, general behavior in our app. So that's an area where we are maybe a bit behind at the moment. That's great. Thank you. It's it's great. You you're focusing directly on the business problems already as you as you're talking, which is which is really great. Magnus, thank you so much for sharing all your journey, sharing some being so open about the challenges and where you've got things right and how you've implemented these things. I think it's been really eye opening for everyone to just hear hear this, the tenants in action, tenants are actually working, that it's a journey, which has been quicker than you'd even thought, which is awesome. Everyone else, I just wanna say, if you wanna learn more about Magnus, you can find his social feeds, in the more than numbers show notes. Don't forget, Magnus, actually, has very kindly given anyone who's watching more numbers, he's part of the community. He's given us a, a a Voi, code to give you fifteen minutes of free Voi travel. If you use the code MTN buoy in the Voyage app, you can zoom around on Magnus's behalf. So thank you, Magnus, for that. That's really exciting. All the other information on the show notes you all we talked about, you can find in the show notes. Just go to count dot co slash MTN, and you can see other other episodes and also, dig into more what we've been talking about today. Magnus, thank you so much for sharing. It's been really great to speak to you. It's been my pleasure. Thanks for having me. See you soon.