Hey, 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 all about turning data teams from dashboarding factories into their organization's problem solvers. Every week, we get another industry leader tell us how they're drawing value with data in their organizations. And this week, I'm really pleased to announce we've got Philipp Van Blerk, joining us. He is, a friend and one of the most tattooed used data people I know. He is a man who's had twenty five years in data across various different things, including running a hedge fund. He is now currently the director of financial data at Monzo, and he's gonna talk to us about data team's secret weapon, the fact they can see everything. Philip, thank you so much for joining me. How are you? Thank you for having me. I'm doing well. Thanks. Well, look, Philip, I we know each other very well, but I wanna make sure other people get to know who you are and where you've come from. And the first question I wanna ask every guest is, tell us the first data tool that you fell in love with other than Excel in your career. Can you give us the flavor of when you first started realizing data was your thing? Yeah. So I, at university, we used a tool called s plus. The language of s plus is called s, which is now r. And so s plus had this whole really cool studio where you would have sort of a spreadsheet kind of thing. You can do your visualizations, etcetera. But at the core was r. So that was a very exciting start for me. But then, unfortunately, when I moved into the financial markets, I regressed into Excel, and only made it out of that, out of the matrix much later, when I moved out of financial markets back into banking, etcetera. There you go. That's cool. I've I've never heard of s. The idea there was a precursor to r makes me makes you realize that you are a very wise man who's been around for a bit. That's really cool. Thank you. So, look, before we dive into the content, I wanna just we call it, like, show us your stack. Tell us a bit more. You're currently at Monzo. You're director of financial data, which sounds given they're a bank, sounds like quite an important job. Maybe you could tell us more what that means and also, you know, tell us a bit more about your data stack and how data's structured in Monzo generally. Sure. So, we are, are doing basically data mesh two point o. So we have embedded data teams through the organization, what we call collectives. So finance is one of the collectives. So we have disciplines. Data would be one discipline. And within that, within your collectives, you'll have, some different disciplines depending on what the collective does. So I'm looking after, effectively, the data team within finance. Monzo is a what's called a newer bank. So we don't really have that much legacy issues. So one of the things that's quite impressive is that we are running everything all all back end is run on microservices, which is not new. But what what is impressive is that from the beginning, we ingest all of our events. I mean, that's the bulk of our data ingestion. It's just happening through events, through something called Firehose that that, was built, in house. We use AWS for our engineering, for our engineering stack, or engineering cloud provider. We have this weird thing where we sit in GCP, Google Cloud Platform for all of our data things. So BigQuery so we have to move everything across, from AWS to BigQuery. As I said, bulk of ingestion is happening through this thing called the Firehose. Then we use Fivetran for some of our other source systems. We use BigQuery as our central data store, so that'll be our data lake, etcetera, etcetera. Then for in terms of being able to well, so for our transform layer, we use DBT. We've done some really amazing developments with DBT, and, it's quite impressive, actually. And then in terms of our front end, it's it's Looker, which goes works very nicely with with Google, obviously. Yeah. Yeah. I gotta say on the I'm not sure how much this is public, but the the the downer on the street is that, like, what Monzo has with dbt is quite different, quite, quite unique. There's been a lot of customization. Not very much so. It's it's quite impressive. But it's it's, we get the most out of DBT through a whole, a lot of tools that we develop internally, which makes your life much easier when you use with DBT when you work with DBT. That's amazing. And tell us so and you mentioned before that you're in finance. What are the responsibilities that you have particularly that your team are owning within finance? Can you is that is that okay to share? Yeah. Sure. So, I mean, the so, effectively, finance is divided in two areas, treasury, which makes sense. We're a bank. Then, secondly well, I suppose it's primary is what we would call strategic finance. So those will be your classical, financial functions. So we on the one hand, we're doing very traditional what you would expect for a data team to be doing in finance, reporting, those kind of things. Because we're a bank, we have quite a large regulatory burden. So there's a lot of work that goes into that. Glad to hear it. Glad to hear it. And then on the other hand, on the treasury side, it would be doing more what you expect from a data team in in in a finance area. So it would be things as exciting as pricing up swaps, coming up with trading strategies, etcetera. So it's it's quite varied. That's awesome. That's that's really interesting. And, obviously, Monzo is one of the most successful UK tech stories, one of the most one of the biggest kind of new banks going. It has it has such an accolade in the data space, particularly as a team. It's one of the most lauded in terms of how data driven the organization is. So looking forward to digging more into exactly how you're digging value in a second. First off, I wanna just, remind people about what we talk what how we're gonna frame this interview and how we frame the series. So I'm gonna bring up the tenets of data value. And I know, Philip, you and I have talked about this many times that there are kind of four, pillars which we consider to be data team value. First one is operational clarity, the idea of data teams not just being, report builders, but they're trying to make the business feel simple and make sure the business understands itself really well. Secondly, we have problem solving, not just being a ad hoc request data mark, but actually helping the business to tackle difficult challenges, minimizing time to decision, and measuring yourself. And, Philip, while I'm gonna spend our time on today, the thing I'm really grateful for you to speak about is just what you've often called to me, like, the the secret weapon of a data team, the thing that is in the data team perhaps quite unique for, alongside finance and the executive team, which is like being the glue, the thing that holds the organization together. Can you when you'd say that to me, like, and you say it to other people, what does that mean? Give us a sense of, like, what it is to be the glue and why that's important. So I think that's, what you need in your organization is a common language. Obviously, you have your overarching vision and mission and strategy, and I think that's what you would have in in common. But after that, it easily splinter, because, you would break down your overall vision into into the different areas. And what is the thing that connects all of us is actually data. Data, if done well, is objective, and helps us, if we do it well, to be able to when we talk about how many customers we have, we should agree on that. When we talk about customer growth, we should be able to agree agree on that if we do data well. And if you think about that, that gives you then a a wonderful way to interact with different areas because we end up all speaking the same language. So if you think about data, I suppose finance is similar, but data sees everything. We are not supposed to be in a very particular area. So not only do so we are effectively custodians of all data in your organization, which makes you the custodian of, let's call it, all objective truth in your organization, again, if done well. And so when I talk about the glue, that's what I mean. It's it's the thing that should keep the whole organization together and aligned. Ideally, when you think about your organization, you want to have a couple of metrics that you follow, that you measure, that you track. And, again, your data team will be the custodians of that. Yeah. I love that. It's the like, it it's it's like the taxonomy that either data team creates the taxonomy that everyone is talking to, thinking about. And it just it's it's another way of putting the kind of operational clarity thing. Right? That the worst thing a that the own one of the unique things about being in data, which I think you often forget, is that they, as you say, they have oversight of the entire business. They're not not not shouldn't be, at least as a function, pigeonholed into just one part of the business. They should be giving getting data across the business and weaving that into a taxonomy that everyone can understand. And it just I think it just you I you you mentioned you triggered me because I just I talk a lot about operational clarity, and the way you put it is, like, it makes it even more essential if there's not a common team focused on taxonomy, on definitions, and being that truth sayer, then it's just you're just creating more chaos in other otherwise, an organization which is probably pulling apart anyway. That's so that's so cool. Yeah. It's interesting. I mean, so the idea of being a truth say, that is often people's biggest like, people often talk about data quality as their focus. And I guess this is part of the truth saying thing. It's not all that's about. Data quality is important, but being a truth sayer has a much more elevated perspective. Like, what do you mean when you say truth sayer? You're you're talking more than just accuracy there. You're talking about narrative. Like, what else is there to think about? So, I mean, I think if you think about data quality, it's a means to an end. The the end goal is this this concept of objective truth, which, as I said, your data team would be the custodians of that. So but with that comes a whole bunch of things. You mentioned clarity of definitions. So important. And not only clarity, but also versioning of definitions so that you can trace history, clarity of change over time. All of those things would then ultimately make up what is the objective truth of your organization. Again, nice analogy with finance in the sense that the cash what what cash flow is should mean the same things through the whole organization. In fact, ideally, should move mean the same thing across organizations. So that and and that's that's a requirement if you want to be a listed entity. Right? There's a very strict definition of what it means to be what cash flow means so that different analysts can analyze the same the same organization. So it is ultimately a huge responsibility sitting with this, this objective truth and making sure that it is well looked after, well maintained. And data quality then is crucial to be able to achieve that. But if you're telling me your data team's main responsibility is data quality, then I feel your organization will will end up falling short of what it can ultimately achieve. Yeah. I I think that's so I mean, I'm one that there's a lot to tease out here in the idea of, like, the similarities and differences between a data team and a finance team. I think it's it's really interesting what you say about, like, the auditable definition. Like, one of the things that holds finance to account is an external auditor, the fact they are professional service. They are professionals who have a standard externally to their organization that they're held to. And I think that does give them a degree of, like, this is the way we do things. And in data, I guess, it's probably maybe that there is a similarity in that kind of need for standardization, but I guess the difference in data is that people can create their own versions of what a what a what a what a what a user could be. There is a nuance for each business. No one is defining user the same way across every new bank in the market because no necessarily no need to do that when it comes to those metrics, whereas in finance, it has to be exactly the same across the board. That's interesting. So it's an interesting way of putting it, and that's that's where there's a similarity and a difference. Is there I mean, I guess there's there's therefore quality learned from a finance team and how they run and how they manage those metrics that maybe data teams can pull from too. Well, definitely. I think that I mean, if you think about originally, a lot of your BI teams originated in finance, again, because of this idea that it sits across the full organization. I think then when we moved into, I think then a lot of it ended up sitting with engineering, and I think we're finding a nice return with data teams. I I just feel like there's so much similar there's a lot of similarities and there's also difference between finance teams and data teams. Like, how much can data teams learn from the fact that how finance teams have been tackling this problem of standardization of definitions and that kind of truth saying for a while. Tell us more about that. So, I mean, if you think about it, your BI teams originated a lot of BI teams originated in finance. And then later on, they were spun out because the value was seen to go be able to go further than finance. But that concept of definitions of auditability, that you mentioned, an audit trail, which is so so important for us. The concept of lineage, which we talk about in data, that is so important when it comes to, to finance. When you think about I remember when I did accounting at school, we were not allowed to use you know that white paint you used to put over, your writing so that, you know, if you want the Yeah. Back to market. Well, yes. It depends. It depends. Topic. But I'm sure it's depends. It's called topics. Anyway, in accounting, you are not use allowed to do that. You would you would scratch out what was written there, and then you would write next to it to create that that audit trail. Right? So the idea of immutability, which is something I would hope that we all think is important in in data, that comes out of finance. And that's again, it's something that that a lot that we can learn from from finance, in terms of those those let's call it best practice when it comes to dealing with with data. Yeah. That I mean, I I completely agree. And I I mean, the the similarities are, I mean, very, very similar. I mean, I I actually haven't really realized it before, but things like you mentioned strategic finance in the Monza department. Like, I guess, they're they're trying to work through problems, business cases, trying to dig in for how to get further. And that's often a thing as we discussed in the tenants, that problem solving is a key value driver of of a data team, that they're tackling the organization's biggest problems. That may not be in finance. It may be in product or it may be in marketing, but it's exactly the same principle. Just a different domain. And you're right. There's so much there's so many similarities between them. It's just that data has, I guess, is has a slight weakness insofar as an or as an advantage maybe that that there's no there's no external auditor of what standards are that you have to meet, which can be a good and bad thing. For sure. Except, obviously, for us in sitting in finance, being a regulated, bank different. Yeah. We we there are certain definitions that sits outside of of the bank and that we can't miss work. You get they've once again, are not ordered to knocking the door of this interview, I really apologize. That's not what Philip said. No. Definitely not. No. Look. I mean, the point is that that's what I said. Right? The the regulator states a whole bunch of definitions, and we there's no room for interpretation for us what we think means. A liquid asset a highly liquid asset is defined by the regulator. We do not have the freedom to choose what that means. Yeah. Yeah. And I yes. Absolutely. Yeah. And then and that's true for you as a finance team data team in finance, but there's other the similarities are really are really striking, and that general data teams can learn a lot from their finance team and how they operate. That's the key the key takeaway for people who aren't in just the financial function. Kindly, I also wanna ask you more. I one of the things which I, I find really fascinating in this area is, like, you mentioned how data teams have actually spun out of finance, and that's again, it's it's helpful to think about that that legacy. I actually find when I talk to data data teams and see organizations with different with data teams who actually report to the CFO rather than, say, the CTO or the the head of product, which can often happen, they they definitely have a different flavor. They definitely have a different kind of flavor of data team. They they act more like the bookkeepers or, again, maybe understandably, the bookkeepers or they're the ones measuring, maybe rather than perhaps being the ones on the other side of the fence trying to drive value. It's it's there's a there's a pro and con of that, but I find it's really fascinating to see there's a different flavor depending what where the data team reports into. And and maybe that's something you've seen in different roles before, like, how you see data teams flavor impacted by where they're reporting to. So, look, I think, when you think when we talk about data, we are actually talking about three things. We're talking about data, the thing that's being captured. We're talking about technology, and then we're talking about some kind of mathematical technique, whether that's just aggregations or counting or whatever it is. So it it is all three of those things. And I think that you should not have that as narrow as only within part management or CFO because as much as well, I don't think of the finance team as where you find your newest technology, because you need stability in finance, not necessarily novelty. So I think the team my preference is for your data team effectively to sit outside of of finance. And the other problem you face is that finance is incredibly demanding in terms of the the frequency, and the quantity of of questions. And therefore, in our case, having a dedicated data team makes sense. But I can just think that if your data team purely sits there, what happens to operations, for argument's sake? Who answers their questions? So I think I'd my preference definitely would be for your data team to sit, ideally in technology. I think that's a really good that's a really good thing. Yeah. At a certain scale, you need to make sure that you're servicing finance department as any other function, but the value of a data team comes from this it's the problem solving aspect rather than the measurement, and I think that's a really good that's a really good I think it's a really good shout. That's definitely what I've seen that that it's there's a different kind of tension, a different kind of vibe with your workings into the finance only, and I think appropriately so. But it's not something which is it doesn't come for free. I think that's really good. Yeah. Let's let's also talk about, the, the other thing I wanted to grab you is just really about, like, how much if you're not a, in specifically finance, as a data person, if you're a data team who sits, say, reporting to the CTO in a slightly smaller organization, DeMonzo, how much do you need to be aware of, like, financial concepts? How much is that at an advantage if you're if you're if you're in that position? You obviously ran a hedge fund before, even getting into data. So you obviously have that financial background. How much does has that helped you as you've gone into different more generic data roles in your career? So, I mean, let let me first ask let me ask you your first question. I think that being a subject matter expert always will be an advantage because it slows you down when you have to try and find someone who can actually answer the questions. Right? Realistically speaking, data is not the truth, it's a representation of the truth. So you desperately need someone who actually knows what the truth is, and that would be your domain expert or your subject matter expert. Now, just think of the advantage of maybe coming from there. Let's imagine having been a finance person or coming from operations, and going into data. I think it's very valuable. However, having so I think if any data person I don't think it's enough for a data person to say, oh, I work with a subject matter expert. I think you need to to bridge that graph the gap properly. You need to make sure that you start to understand the subject matter that that you are working on. So whether that would be operation, whether that would be finance in our case. So the question is, how does it benefit me where I am now? Well, realistic, that that's very much why I was appointed. That's what made me a good candidate for this role was exactly that background. Because as I said, we affected it's on the one hand, we've got treasury, where you where you are you sit with the balance sheet of the bank that you need to apply profitably and responsibly. So from that point of view, I I needed that. But then also you need to have some form of an idea of basic accounting and that kind of thing. So I think, for me, it has benefited me a lot having come from that, though, that ad background. Yeah. Yeah. I mean, absolutely. For the role you have, you are a unique thing. I I honestly don't know I think I said to call a miss in the market in general that I think there's a big need, a big skill gap in the kind of data literate finance person. I think people, particularly if you're either an accountant who knows SQL or a data analyst who has a bit of accounting, I'm constantly seeing teams looking for that kind of that kind of expertise. And so if you're looking, I would recommend anyone out there looking for an extra niche to go into, I would definitely think about that bridge between finance and data. As we've discussed, there's loads in that space into the similarities, operational, operational strategic benefits of owning both sides of the fence. So it's a really interesting space to play in, and I'm grateful for you sharing your experience. I'm now gonna move on. I wanted to ask you something which is going back to your first inklings in data or maybe I should put it a different way. Like, what's the advice to someone early doors just getting to data that you like, the advice that you wish you gave yourself you got got you got going? Just share some share some wisdom from, someone who knew the language before r. Not to Robyn. Yeah. So so the first thing would be stay with r or s and don't move over to to spreadsheets. I think that and it specifically has to do with this idea of the the very thing I mentioned that the good principles we have in finance, immutability, traceability, auditability, all of those kind of things, you lose a lot of that, unfortunately, in a spreadsheet. The spreadsheet is incredibly versatile, but its versatility is exactly its downfall. So the the most important piece of advice I would give myself is, yes, it's more work to stick with a tool like that, but it's, the the benefit far outweighs the cost of just even just in finding a better way to put the the the the data products in the in the hands of the people who use it. Very quick to do that with a spreadsheet. But with a little bit of effort, you can put it in a in a in a let's call it a more sustainable and a and a a more, manageable and governable way in people's hands. Love it. I I completely agree. That would be like the more you can I I I had a similar situation where I I've effectively deskilled? I used to write a lot more code at the beginning of my career than I sadly do now, and I do that deskilling is a is a loss to me and my productivity, like, ultimately. That you mentioned it both more for the repeat a bit more for the auditability side of things, but I just think, yeah, the depth of the spreadsheet is is a it would be an amazing feat. All that I'm here to plug your tool, but I think the beauty of your tool is that you do end up of count is that you sit with the versatility. You definitely sit with the versatility, but it's transparent. Right? And it's very structured, etcetera. So I think that having something like that, I think, is amazing. Well, I you can definitely plug my tool. That's wonderful. Thank you so much. It is definitely something which we, we keep seeing. That kind of transparency, the auditability is helpful to us to anyone who's engaged with an answer. Like, we you're totally right. It's back to that piece of, like, if you've got a metric or you got a number, you're gonna make a decision, you wanna know how you got there, and that's really important. That's one of the benefits of the Canvas. It gives you that easy auditability, that lineage all the way through to the decision point rather than just being an abstract number. So, yeah, you're thank you. That was a una unrequested plug, and I'll take that. Thank you. Right. Okay. I have one last thing I wanna cover off with you if I can, which is the, we we call it the slot, the anonymous data letters. I've told people in advance that I was gonna speak to you, and I asked them for some questions. This one is one I I thought was most, helpful. It's a bit long, so I'm gonna read it from the sheet, but bear with me. As far as I said, I'm a data leader running a team of seven people in a two hundred person company. So, obviously, a bit smaller than your context, but I know you've worked in similar sized orgs before. We've got some role specialization, data engineer, analytics engineer, analyst in in facing into different functions. Currently, I'm feeling that we just don't have enough capacity to serve our very hungry data organization. We're looking through various self serve options, but but I believe, ultimately, to serve at the pace they're asking, we're gonna have to have, more headcount. The problem is we're focused on getting to profitability, as I guess as an organization as a whole. So every headcount addition needs a business case. Any idea of how to go about doing that and start negotiating with my CTO and the wider exec team? It's a bit of a I say, it's a challenging situation. The the business case for Datahead is, is an age old one. Have you got any thoughts? Yeah. So I think the I would say you need to start by thinking about this, in a different way. In that, see everyone in your organization as a data practitioner because that is just true. It's impossible for us to go through life without interacting with data and not just capturing it, but also analyzing to a certain extent, or organizing it. So I think that once your viewers then to say, alright. I've got seven expert data people, and then the rest of my organization are also data practitioners. I would say your first objective should be to increase the data fluency through the whole organization. Because the moment you do that, any conversation about the value of data becomes easier because people are not on the back foot. They don't feel alienated. They understand exactly what you what you are are referring to. So for me, or as a data leader, I think it's very, very important to see your whole organization, all of them, as data practitioners and to make sure that you are actively working to increase the data literacy, and, well, one step further, the data fluency through your organization. I love that. I think that's I love that flip. That's a really cool idea. The fact the way that you're sort of you're basically I mean, one way you you could put it, like, the suggestion is to sort of say, go to the CTO or the exec and say, look. We've gotta increase our capacity to answer questions in the organization. There's a few options. I can get another specialist, make it eight specialists in this organization as a head can increase, or I need budget or time to go and train up another look at the distribution of capability, and I need to train I need some budget to train or some time to train the next cohort to be operating at a higher level. I I think that's really cool. You're basically putting it to it's not necessarily headcount. It's a business case for capability, and there's a different ways you can play it, and you're giving them options. But the problem is then you're still solving the problem just a different way and giving them a way to see the problem in a different light and not just a headcount number, which is that's really cool. I love that a lot. Funnily enough, I mean, one of the things I actually I spoke to a a head of data at a a slightly smaller, neobank, who who who would be a rival. But the way the things they that that that person has solved the problem is actually his organization's headcount and costs actually don't sit centrally to him. He's in charge of their, management and their product management line, but the budget for the headcount for his team, effectively sits in each department. So when they need so and they basically he's democratized out the specialist. He's basically said, you know, if the head of product wants to get more answers, wants to move quicker, they can put a headcount into their team on their budget for an extra analyst or so. And it's amazing how they've he's basically democratized, the budget to well, he's basically made the business case available to each function to pull in more resources they wanna go faster, and that's how he's completely done it. It's just he's made it a kind of a market a market market dynamic rather than it being a central bot. Yeah. It's the same for us at Monzo, except that we have it both ways. The the headcount sits and then with the budget sits, definitely within the collective, but we also do count, in the aggregate. In other words, you want to make sure that you you have enough data scientists, for argument's sake, through the whole organization, and they're not all sitting with marketing because they have the biggest budgets because you're going through a growth phase. So but it's so it's it's it's both and for us. But it's it's the it's the same kind of idea. When I want, additional data people, I speak to the CFO. I don't even speak directly to the, the the the the head of data. There we go. That's amazing. Thank you. That that's a good I think it was a good it was a good answer for the person who asked. We're out of time for them. Thank you so much for being here and talk about this. We've learned so much. We talked about the hidden secret data teams being the glue, having full oversight of the whole business and that being one of their superpowers. We've talked about the similarities between finance teams, and data teams. We've talked about how to justify headcount, how to justify investment in data in general, which I think was a pretty pretty amazing insight there. If you wanna learn or more, meet Philip, hear more about Philip, you can find him and his socials in our show notes. You can head to count dot co slash m t n to find more of our episodes on the show notes for this episode. Thank you so much for watching. Philip, thank you so much for being here. I'm really grateful. It was fun to be here. I always enjoy talking about these things, as you know. Thank you.