Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
010 - Maximising the ROI from your Data team
181 Plays1 year ago
In our latest episode of The Stacked Data podcast, we're thrilled to have Thomas, CEO and co-founder of Tasman Analytics, sharing insights on "Maximizing ROI in Data & Analytics."
🔍 Episode Highlights:
- Uncover the common reasons why data teams are often perceived as cost centers.
- Learn strategies to transform your data team into a value generator.
- Dive into the keys to driving ROI for your analytics team.
- Discover where teams typically go wrong in maximizing the value of their data.
- Gain expert advice on crafting a clear strategy for a high ROI.
🎙️ Introduction: Get to know Thomas and Tasman, exploring their background and journey in the dynamic world of data.
💼 Data Team Transformation: Explore the challenges of data teams being seen as cost centers and learn how to assess if your team is a cost centre or value adder.
📈 Driving ROI:Thomas shares valuable insights on evaluating, strategizing, and ensuring your team drives a positive ROI.
🚀 Workload Management:Learn effective ways to manage the immense workload on data teams and optimize team efficiency.
🌟 Avoiding Common Pitfalls: Discover the biggest mistakes data teams make and get expert advice on resolving them.
Recommended
Transcript
Introduction to Stacked Podcast
00:00:02
Speaker
Hello and welcome to the Stacked podcast brought to you by Cognify, the recruitment partner for modern data teams hosted by me, Harry Golub. Stacked with incredible content from the most influential and successful data teams, interviewing industry experts who share their invaluable journeys, groundbreaking projects, and most importantly, their key learnings.
Meet Thomas: CEO of Tasman Analytics
00:00:26
Speaker
So get ready to join us as we uncover the dynamic world of modern data.
00:00:35
Speaker
Hello, everyone, and welcome to another episode of the Stacked Data Podcast. Today, I'm joined by Thomas, the co-founder and CEO of Tasman Analytics.
How Can Data Teams Drive Business Value?
00:00:44
Speaker
Tasman is one of the UK's leading modern data consultancies, focusing on bootstrapping early stage data teams with an emphasis on business value. Thomas shares some excellent insights on how to ensure you and your data team are driving a positive ROI and that critical business value.
00:01:03
Speaker
We cover areas like how to communicate business insights in the right way, strategies to avoid being seen as a cost center, and the biggest pitfalls teams usually fall down. I hope you enjoy our conversation.
00:01:17
Speaker
Hi, Thomas. Welcome to the pod. Really appreciate you coming on and talking to me today. How are you doing? It's my pleasure to be here, Harry. I'm doing very well. I'm doing very well. It's busy as always, but I like taking a bit of time to talk about the wider themes in the industry as well. So looking forward to this chat and thank you for the invitation. Yeah, no worries at all. I know you've been quite active across LinkedIn talking about
00:01:41
Speaker
The ROI of data and that sort of thing. I'm that annoying guy indeed talking about ROI all the time, I'm afraid, absolutely. But I think it's important, right, in the day that we're living in and the year we've had. Yeah, I think we see a lot of teams now really thinking through how they can not just deliver value because obviously
00:02:00
Speaker
Most data teams deliver a tremendous amount of value in the industry here, but also how to narrate that value, how to make sure that this is efficient and relevant as possible. It's really exciting, I think. If maybe the last couple of years we focus a lot on the technology and the stack, I think we'll definitely start to move into the business and ROI side of the equation now, Harry.
00:02:18
Speaker
Yeah, well, the stacks obviously exploded last couple of years, and it's easy to get caught up in the technology aspects. And yeah, the business takes a back step. But I think, yeah, now, and the conversations I've had this year is that was a big key point, you know, let's make sure that what we're doing is answering the business questions. So that's what we're going to talk about
Tasman Analytics' Approach to Bootstrapping Analytics
00:02:37
Speaker
today, Thomas. But I suppose first off for the audience, it'd be great if you could give a brief introduction to yourself, your background and who you are. Absolutely. Now it's my pleasure to be here. So
00:02:46
Speaker
My name is Thomas. I'm CEO and co-founder of an expert led agency in data analytics. We're called Tasman. We're about 25 people spread across London, the Netherlands and Sweden. So a nicely Northwestern European setup.
00:03:01
Speaker
We specialize in bootstrapping analytics capabilities for fast-growing companies. So that means that we come in and we don't just set up infrastructure because that's the stack. That's part of the stack that we'll talk about for sure. But we also make sure that insights are being generated, that we know what drives the needle for our clients, for the companies we work with.
00:03:21
Speaker
And we actually also help them hire and onboard their internal data team because we think that data is so important that it shouldn't be outsourced to consultancy forever. So we're very, very keen to come in, set everything up, make sure it's all working and then hand over to the internal team.
00:03:38
Speaker
That's what we do. I've been doing that now for about six years. I've done that for about 50, 55 clients, all very much in the startup and scale-up ecosystem, and if they're not a startup or scale-up themselves, then they're very much like to think of themselves as being in that space. It's been an exhilarating ride. There's, of course, plenty of data consultancies and data work out there, but we like to think that we have a nice differentiation when it comes to trying to hand over as quickly as possible what we do.
00:04:05
Speaker
Yeah, it's brilliant. I've seen known of Tasman for quite some time. And I think it is a truly sort of unique approach. And yeah, one that is valuable for your clients internal data knowledge is, you know, the key to long term success. It's critical. Absolutely. Yeah. Look, and my own background is I'm a physicist by training and have been in the London
00:04:25
Speaker
data ecosystem now since mid 2013. So a few months ago, I realized that I've been working in this space for 10 years, all the way back from when data science was still the term that was applied to every single data professional out there. If you remember that, it's been quite
Why are Data Teams Seen as Cost Centers?
00:04:40
Speaker
a ride here. It's been quite a ride.
00:04:42
Speaker
Brilliant. Brilliant. Well, look, thanks for that intro, Thomas. Let's dive into uncovering some of the points. So as we've already mentioned, this year, particularly in data and the wider economic situation, there's been a huge emphasis on costs and
00:04:57
Speaker
I think many data teams still are perceived as a cost center in certain areas of the business. So how do you evaluate if you are a cost center or if you're a value adder? That's, I think, something that business leaders and data leaders would really like to understand. Yeah, absolutely. And it's important to, I think, accept as well that good data professionals are not cheap. We cost quite a bit of money and it's therefore key to sort of understand.
00:05:22
Speaker
the return on that investment is, which is why we're talking about ROI all the time. I think there's probably three or four themes in why it's easy for a data team or an analytics team to be considered a cost center rather than a profit center. I think a few of them are
00:05:38
Speaker
intrinsic to the work that we do as data teams. And then maybe a few of them are within our control to help fix, I think, by just running the teams in slightly different ways. So the intrinsic reasons, I think, are that certainly if you start a data team from scratch, if you move away from end-to-end tools like Google Analytics or Amplitude, start centralizing your data for the first time, it's quite a bit of setup work that needs to be done. So that's not just setup work in terms of actual code that needs to be written.
00:06:06
Speaker
But it's also set up work in getting quite expensive SaaS licenses in setting up a stack that doesn't come for free either. And so the initial investment over the immediate returns, that's a balance that might feel like it doesn't really create that much business value straight away. So that's probably a reason one. Sometimes for companies to want to move very quickly that can overshadow the longer term benefits.
00:06:28
Speaker
So I think the immediate tangible results are not clear, but you've signed a 40K BI deal, and you've signed a 30K Data Warehouse Credits deal, and you've signed a 20K ETL tool deal, all of a sudden you're sort of coming up from behind when it comes to actually trying to grow the value of all of that.
00:06:47
Speaker
So that's one. I think second intrinsic reason is that data is a complicated subject. At its best, it is existential to the business. At its best, it informs every single decision and makes a business succeed because it can rapidly identify where room for growth is or where efforts are not working, where efforts are working.
00:07:07
Speaker
But the intricacies of data analysis, they're quite hard to grasp. And if you work with stakeholders outside of the media technical field, and most data teams will report one way or the other into the business side of the business, rather than the technical side, we can talk about that as well, because I'm a big proponent of data teams being seen as a business role. If you report a non technical stakeholder,
00:07:28
Speaker
If you don't communicate the impact of your insights extremely effectively, it will take a while for the stakeholder to understand the actual impact and investment of what you're doing. I think the third one is that even if you are doing all of those things right, you've set up the stack, you're running along nicely, very efficiently with a team of two or three people,
00:07:47
Speaker
Often the real benefits of a proficient team, which are things like improved decision making, refined operational efficiency, predictive insights, identification of churn, growth engine, all of those different things, has impacted all the materializers over time. The insight might be there quite quickly, but the way that the insight actually moves the bottom line of the business you work in,
00:08:08
Speaker
Well, even in rapidly-paced startups, it can easily take months, and in bigger businesses, I mean, let's be honest here, sometimes it takes years for that insight to pay off. So yeah, as a growing company, you might be tempted to focus on a bit more of the short-term gains and overlook those as strategically long-term plays. So I think that those are three sort of intrinsic reasons why we're sort of set up to be seen as a cost center if we don't do a job properly, Harry.
00:08:32
Speaker
Yeah, I think the key points and the cost from the get-go is so great that it naturally is always going to take time for that to pay dividends. So as an engineering team, by the way, I will probably add as in I think the trouble is that engineering teams are often seen as core to the product offering of a startup, whether it's a mobile app on e-commerce platform, or an advertising service.
00:08:53
Speaker
the software engineering team. You don't have product if you don't have software engineers. And so that's factored into the, shall I say, company growth investment budget from the very start. Whereas as a data team, you might be tempted to think that you can get by quite long without a clear investment there. So the concerns are often secondary.
00:09:12
Speaker
In my opinion, it should probably be primary sitting alongside the engineers, along entrepreneurs, startup founders to think about, well, look, I need to build a product, but then I also need to make sure it fits in the market, has great insights and a growth plan and for that I need data there for I need to invest in data front as well.
00:09:27
Speaker
Yeah, I think that's a key part. Data seems to still be a secondary thought rather than a primary thought. And obviously, that's where the growth comes from. Indeed. So Thomas, how do you actually drive ROI then in analytics? An organization that's spent however much on their stack? How are you going to make back on three in a case straight away? Look, this is not simple. And I
Solutions for Data Teams to Enhance ROI
00:09:52
Speaker
think that
00:09:53
Speaker
It's also important to say that this is something that you can't really learn in any formal environment necessarily. This comes with experience, with effective. We've done this for so many clients, but also with me starting my career, building out a data team in a company, learning all of the hard lessons from scratch. So if you're not doing any of the things that I mentioned here, just give them a thought, but don't feel that bad about it either. So I think there's a couple of things you can do in your team to
00:10:18
Speaker
sidestep the cost center drivers so to speak a little bit and communicate about them clearly but and the things you can do
00:10:27
Speaker
all come down, I think, to three main principles. One is communication. You're not going to escape the fact that in any company, whether it's a small fast-growing startup or big technology player or even a charity organization, so to speak, if you are not able to succinctly and precisely communicate value of what you do as a data person,
00:10:49
Speaker
you're going to be, I think, starting from behind in defending the value of the team. So, communication is key, absolute key. You're not just a technical worker. You are integral to the value of the business and you need to be able to communicate that.
00:11:05
Speaker
Second, I think, is your ability to understand the business well enough so that you can prioritize which of the, if you do your job well, hundreds of requests that the stakeholders send you, which of those to prioritize, right? So, if you end up in a sort of classic, fast-growing business that raises a seed round, raises a Series A round, hires a data team, raises a B round,
00:11:27
Speaker
often what I see is data teams who end up with something that resembles a bit of a ticketing system, right? So a queue of work that's requested by the stakeholders, whether that's a product manager, a performance, a marketing performance manager, whether that's the CEO, one that can board report. And you're going to start to prioritize those requests, not based on their intrinsic value, but based on who has the loudest voice, so to speak. And of course, you're going to prioritize the board report for the CEO, because that's what your job in many ways depends on.
00:11:56
Speaker
That's typically when it becomes quite hard to defend the value of the data team. Because at that point, you are not prioritizing the work based on how much you can move the needle on the business. You are not thinking through what can be done to communicate clearly about that value. You're just thinking through how can I get this piece of tactical work out of the door as quickly as possible and move on to the next one. And that typically burns data teams out. I think just a few other things that I think about in terms of how do you drive the ROI,
00:12:26
Speaker
cross-functional collaboration, make sure you understand what the other teams in the business are doing, not just on the business side, but also on the technical side. You want to almost operate a bit as an internal consultant, which is, of course, rich coming from us being actual external consultants, but it is an important skill set to work in a team, talk to people, understand the requirements, try to dig deeper, then just to plain request that they may try to understand what they're trying to achieve, how they want to achieve it, and how we can help them achieve those goals.
00:12:53
Speaker
you probably in the data team know the data better than they do. So if they come to you and say, I want a graph with these dimensions and this measure, gently push back. We always suggest and sort of say, well, is this kind of achieving the outcome that you want? How can we help you understand the drivers of that outcome that you want? What buttons can you push in, say, app design in order to get a higher phenocompletion rate? And let's define some tracking around that that we can set up, et cetera, et cetera, et cetera. That sort of two-way conversation is really important.
00:13:22
Speaker
I'd also say probably the last thing is really prioritized quick wins, particularly in fast-growing businesses. The sort of prioritization matrix we tend to be a big fan of is the urgent versus important matrix, right? So classify all of the tasks in front of you. According to that, I think they call it an Eisenhower decision matrix. What is urgent and important? What is important but not urgent?
00:13:44
Speaker
what's not important but urgent and what is non-urgent and non-important. And I think the advice is to immediately get the urgent and important stuff done, delegate the stuff that is urgent and not important, plan the stuff that's important but not urgent, and just remove the non-urgent and non-important stuff from the tool list altogether. Even if it means disappointing that poor product manager who really needed the insight in this particular button click.
00:14:07
Speaker
I think that's brilliant. You touched upon some really interesting points and I think again, it comes back to that key point of communication. That communication stops you from being a bottleneck and enables that further sort of enablement of what you're doing. I think
00:14:23
Speaker
The ticketing system is obviously great. You do need to have something in where, you know, people can ask for requests, but when you become just a, you know, a support function is where you're not going to be driving value. And as you said there, you know, you need to be communicating with your stakeholders to, to make sure that you're getting the best for them rather than just doing what they tell you. Because as you said, you probably got better knowledge of the data. They might have better knowledge of the domain. If you put that together, that's when you're going to be really powerful.
00:14:51
Speaker
Yeah, and think about ticketing systems, right? I mean, with the risk of making too big of a point on it, it's a symptom more than a cost, I think. But no one really sees, for instance, a customer support team as a profit center. They see it as a cost center that they have to have in order to have better functionality of the business. As a data team, you do not want to be seen in the same vein as the customer support function. So look at everything that defines that, so to speak, and then make sure that there's a data team.
00:15:19
Speaker
You learn from that. Don't do the ticketing system. Don't see it as a commoditizable job that doesn't sort of race to the bottom and certainly don't see it yourself as a cost center either. Make sure that you always have in mind what the value is that you produce for the business. That value point is so important and obviously that's what leadership should be doing, is making sure that you're working on impactful projects. But also if you notice that yourself, take responsibility and take it to the team within the business. That's a really important point to underline that.
00:15:49
Speaker
I think what we also see, if I think about all the different ways that data teams fail, I think the sort of reluctance to take their own ownership about what they want to be doing, rely on product managers, C-level executives to define the priority and the backlog for them, that sort of
00:16:07
Speaker
is a start of, I think, a bit of a slippery slope that ends with the data team not really caring about. Business actually wants to achieve, not really a bit lost within a forest of OKRs and tickets and so on, and what they want to prioritize, and not really having the agency to step up and do something about it. Because it goes two ways. If a data team is not stepping up to define the business value, then of course, senior leadership will step in and define the business value for them. But if the senior leadership is not doing that properly, then yeah, you get this sort of
00:16:35
Speaker
visual circle, frustrated data teams, long, long backlogs of work, stakeholders are unhappy because it takes one to get anything done. And importantly, as a data team, you need to be able to take a step back and think beyond all the different requests and think about, okay, do we need to now spend, say, a couple of weeks to
00:16:55
Speaker
restructure the data model because we might have run the same data model for a few years without updating it for new features or new app components and so on and so on. If you're running in a red race request type system, you never have the time to do that. And that is typically also a big driver for frustration and failure, alas.
00:17:14
Speaker
Yeah, no, that's a great point. Take ownership of your own work and don't let that be a disconnect. And go sell it. Yeah, absolutely. You are in a business role. You're supposed to communicate and sell it. So maybe that's a piece of advice that we can give together, Harry, to start communicating the value of your projects and don't hesitate to ask whether you can present an analysis you've done at all hands meeting. Don't hesitate to ask, hey, can I
00:17:36
Speaker
tell, for instance, one of the many meetups that are organized in London, Amsterdam, Edinburgh, Stockholm, and so on and so on. Ask if you can present there, because the best meetups or the best presentations I always enjoy the most are presentations of very impactful presentations of analysts who are analytics engineers or data engineers who say, hey, look, we had this problem here at this company where I'm working, and this is the way we solved it.
00:18:02
Speaker
And that's all there
Building Trust in Data
00:18:03
Speaker
is to it. And I mean, it raises your profile in the ecosystem as well. And it teaches you how to communicate about the work that you do outside of your immediate technical team.
00:18:13
Speaker
Yeah, I've said it many times before. You have to be a salesperson within data. Reaching to acquire. Don't oversell either. That's the other problem. So you've obviously mentioned a few areas where people typically go wrong, but how else can companies and individuals identify sort of where they're going wrong in this chase for being a driver of ROI?
00:18:38
Speaker
Yeah, yeah. I think there's symptoms and root causes if I can split them in there. So I think the symptoms are very much your executive team, your leadership is unhappy as in they keep asking you for reports and you sort of feel the frustration of them not really sort of seeing the amount of output from the data team that they want. And that's them. I think the cause for that is the ticketing system that doesn't prioritize the stuff that leadership actually cares about. Other sign to be wary of is
00:19:06
Speaker
creeping inaccuracies in reporting. That's a big driver for trust in data. And we haven't really talked about trust. But as a data team, you might be the best performing data team in the country in terms of beautiful data models, fantastic business relevant reporting that you build. You've nailed business value communication. You've absolutely smacked it up at the park when it comes to putting a beautiful partization framework so you never spend any minute on work that's just not that useful to the business.
00:19:33
Speaker
if your stakeholders don't trust the output it should produce, because at one point you published a laughter and value report with a 10% error in there, right? Then all of that is for nothing. So building this sort of right set of expectations within your teams that data is messy.
00:19:51
Speaker
You can guarantee accuracy data. There are ways to do that. It takes time and energy to do that. Sometimes you might opt not to go for 100% accuracy, but for 80 or 90% accuracy instead. Retention rates per cohort, you might not need 100% accuracy there. You might just need the direction, so to speak.
00:20:07
Speaker
lifetime value? Yeah, you kind of want 100% accuracy or close to 100% equity as possible there. If you find yourself in discussions about why does it take so long to build these reports? Why are all the reports inaccurate or why is there no trust in data? And why is my marketing team seeing different reports than my sales team or my product team?
00:20:30
Speaker
then I think at that point you find yourself in a position where the return on investment is clearly not large enough. But companies then tend to do is they tend to double down almost, and they tend to add new data team members into the mix. So for instance, you might have a team of three, a data engineer, analytics engineer, and a data analyst. And in a lot of growing companies with funding, the response to an underperforming data team, if you want to call it like that, because we're talking about perception here rather than actual, is to just add more people to the mix.
00:20:58
Speaker
But as we all know from engineering lessons, adding people to the mix of an already delayed project is going to make it even later. Again, you increase the amount of communication. It takes time to onboard someone. And the problem is not the staffing. The problem is how you actually communicate about it and how you build a trust and how you prioritize the ED request. So if you find yourself in those type of discussions, then as chances are high that your return on investment is not being appreciated for what it could be.
00:21:24
Speaker
Yeah, yeah, I mean, trust is such a huge thing. It's very easy to lose and much harder to win. And I think it then reverts back to communication, that understanding of, you know, the, as you said, the percentage of reliability on this area, I don't think you need to have everything, you know, with 100% data quality and governance, because that would take way too much time. But it's, again, it's back to the sort of prioritization of what do we need? I
00:21:51
Speaker
And give an example of that sort of triaging of data quality, right? Because that's an important bit there in
00:21:58
Speaker
If I think about the lessons that you learn growing a data team, solving again, running these kind of projects for quite a few of these companies for the last couple of years, you can't get to 100% accuracy in every data point. Select where you need to 100% accuracy and then go from there.
Event Tracking Strategies
00:22:13
Speaker
Tracking plans, for instance, if you start to deploy event tracking on your mobile app or your website, which is typically a step most data teams take from the moment that they start to centralize data into a data warehouse, they realize that
00:22:24
Speaker
day in the sort of aggregate statistics about user journeys and retention are no longer sufficient. You want to have a lattice of actual event data coming in from the mobile apps and the website into the data warehouse in a raw way to then model yourself. We
00:22:39
Speaker
We see data teams, if they do it for the first time, typically make a couple of mistakes there. They typically start to track every single possible event in the app in a mobile website, generating hundreds of thousands of events per session. It's way too much. You can't guarantee accuracy on the data modeling there for all of it. Don't do that.
00:22:56
Speaker
identity. Think clearly about what you want to do with the event analytics and then define events into three tiers. Tier 1 are events that are directly mission critical or revenue generating, so a conversion event, a registration event. If it's really critical in an app that you invite your partner, for instance, you track that as a Tier 1 event and you make sure that those events are
00:23:18
Speaker
co-plated, highly QA'd, properly tested, you run regression unit tests on them every time that you deploy a new version of the analytics tracking toolbox, et cetera, et cetera, et cetera. You then have your tier two events, which are mission critical supporting. Sign up for more completion because that's a necessary event to hit before registration, be tier two event. Looking at the sales page before you make the conversion decision, that's a tier two event as well.
00:23:43
Speaker
You still want to make sure that those are accurate, but because they don't feed into direct aggregations for revenue or for mission critical numbers like conversions, you can get by with a bit more of an error rate there. You can err towards making sure you capture all the data there rather than err towards making it as accurate as possible. And that's where I would, for instance, look at final completion rates.
00:24:04
Speaker
plus or minus 1% doesn't really matter too much there. You can still get it as accurate as you can, but it doesn't have the same pressure. And then everything in tier 3 is UX events, screen views, page views, link clicks if you want to track those, deprioritize those because you have not really seen that much analysis that properly uses.
00:24:22
Speaker
Tier 3 events in this triage matrix. And if you do need them, you just need to roll kind of relatively directional data set rather than all the full details there. So it's one way of doing it properly and understanding how data quality links straight to what you actually want to do with the data set. And that links back to what is actual business value that you want to create with all of this.
00:24:42
Speaker
I think it's partly a problem by the cloud vendors. There seems to be such an appetite to store as much data as possible. And I think what you're saying there is my key takeaway is identify the data assets which hold value, because not all of them do. Data is said to be the new oil, but oil is always valuable at every stage, whereas data, you can have a lot of data that is just junk.
00:25:06
Speaker
The amount of junk data that's generated, it's exhilarating right now. It's a really important point. It's very easy to create a lot of data. Modern data stack in particular has made this even easier than it already was, right? It's still a really bad idea to just track everything. And I'm not even talking about any legal or privacy concerns that you should quite rightly so look at as well. If you track every single user during the event, for instance, just bringing up the example of event tracking again,
00:25:36
Speaker
you will have a huge amount of work modeling that data. Because if you haven't really thought through what event do I need for what type of business question and answer,
00:25:49
Speaker
you're going to have to do all of that exploratory work in your data model reporting phase, and that takes a huge amount of time. Whereas if you've done the work upfront to think, well, okay, look, I need to have a lifetime value per customer report that I can segment by, say, device type and by cohort, right?
00:26:08
Speaker
At that point, you realize you only need three events for that. You need to know what the revenue number is, so you can get a left of value number out. It's a bit more complex, of course, but let's just assume transactional value. You need to know when the user installed the app or registered or signed up to the e-commerce platform, and you need to know what device to run if you want to sort of split it by Android versus iOS or split it by web versus mobile. That's all you need.
00:26:30
Speaker
Go implement those two or three events straight away, so to speak, so you can build this report and boom, you've created your business value. You have something there. You don't have a few thousand events you need to weed through in order to make the analysis. It goes quite quickly from there. If you keep doing that, there is a risk of
00:26:46
Speaker
Of course, designing a very organic event base where all of a sudden you find yourself having 10 different conversion events because you've done this 10 times, so to speak. But there are ways around that as well, around structuring your tracking plans, making sure that you keep them in the central place like Avo, or just a Google Sheet if that works for you.
00:27:04
Speaker
But at all stages, know exactly what you're going to do with the events. Don't let it be in a scenario where you've essentially just engineered all logging events that the engineering team has built into the app to be sent to your segment or Firebase or other stack instance as well. That's the bad position to be in.
00:27:22
Speaker
definitely do not want to be there. So, Thomas, this podcast is obviously all about, I suppose, learning from mistakes and helping others with success. So I suppose on that, the data leaders and people aspiring to become data leaders, what's your advice for a clear strategy to make sure that your team is driving a good ROI on data?
Selecting the Right Tech Stack
00:27:46
Speaker
Yeah.
00:27:48
Speaker
If you make mistakes, it's not the end of the world either, but these are just the sort of three big learnings that we found to put it in a slightly ambitious way to guarantee that at the very least you circumvent most of the pitfalls. So first of all,
00:28:06
Speaker
make sure that you select your stack as carefully as possible. There's a huge amount of tools out there. It's very tempting to pick up, say, an audited event pipeline because it looks shiny and you can see why it exists and you can see all the technical reasons why it would be fantastic to have a central event repository straight away, to have a full audited data pipeline all the way from the app to the data warehouse. If you're a serious company, you just don't need that at this point.
00:28:34
Speaker
Go and plug in Firebase or the Rutter Stack starter plan or something along those lines that might not have all the bells and whistles, but gets the job done. Other stack choices are around things like data observability, self-service reporting. So I always see those as a function of what you actually need to deliver on a day-to-day basis. Just a simple example, we absolutely love Looker. It's still a tool that we deploy in most of our clients, one way or the other.
00:29:00
Speaker
We don't deploy Looker in the first weeks or even months of an engagement for a small growing company because they just don't need it at that point. And if you think back through the reasons why data teams are seen as cost centers, that massive upfront investment in the tech stack is one of them.
00:29:17
Speaker
So if you reduce that, then it can only make stack decisions that are very clear. This is the value that we're going to generate for the business by having this. That's very good. I think it was also easier these days than it used to be. A modern data stack ecosystem has produced quite a wide array of different options at every stage in the stack, whether that's event ingestion or ETL or warehousing or data modeling or visualization. So you have some more options there, even including a whole bunch of very good open source options that you can start selecting.
00:29:47
Speaker
So that's about the stack. So avoid mistakes of over optimizing your stack before you know what you're going to do with it. Second mistake is data modeling. Data modeling is a critically under illuminated part of a data team set of responsibilities.
00:30:04
Speaker
At the end of the day, it might be easy to see data as getting data from the apps in the backend and then third-party services and then quickly building reports on top of it. But of course, there needs to be a data model in the middle to centralize the data and make sure it's scalable.
00:30:19
Speaker
What typically happens is what we call query-driven development, where a data team is so focused on getting the first set of reports to the stakeholder teams that they're gonna write a query that just grabs a bit of the raw data, joins it in the data set, maybe with one or two dimension tables attached to it, services it in mode or Tableau or Power BI and produces reports right away. Now you can do that because it very quickly produces value, right?
00:30:47
Speaker
But if you're not careful, all of a sudden you find yourself after 6 to 12 months seeing a very organically grown data model that's essentially a collection of loose SQL scripts where there's no design intention, there's no separation of concern, there's no understanding of how the different source data
00:31:04
Speaker
joined together to build a full view of the customer or a few view of the financial transactions or a full view of the conversion dynamics. Instead, you get a very organically grown messy data model that no one really understands anymore. And that's when you generate inaccuracies, different reporting, depending on what, what dashboard you query. That's where you lose trust in data as well. That's where it becomes very frustrating and hard to produce even quick reports because you need to weed through all of these queries in order to understand which one is the right one for this particular report from
00:31:33
Speaker
that you need to build for the product marketing team. So instead, think through your data modeling upfront. And for that, you have a few different tools. You can follow Kimball type design patterns, where you find a lot of tutorials online about how to build a proper app data model, for instance. We are a big fans ourselves of Inman type modeling, which is a domain entity modeling method where you model the business. In your data model, you have rather than have a set of fact and dimension tables, you have
00:31:59
Speaker
one table describing a user that might be composed of different data sources, you might have one table describing a conversion event, you might have one table describing a subscription state, and the main layer, the main model sort of designs and defines how those tables join together. There's reasons why that's a very powerful way of doing it. What matters is not what
00:32:19
Speaker
Topology you choose or what architecture you choose with metrics is that you choose an architecture before you start building. That's condition number two. Do that and you'll be very quick in the future to deliver reports, to deliver your insights, do deep analysis and focus your time on analysis rather than just pure dashboard.
Enhancing Business Value through Data Modeling
00:32:35
Speaker
Third component is the sort of
00:32:38
Speaker
pitfall or warning I'd give or tip I'd give is be very careful with self-service. So you know that you got to build reports, of course, that realize the business value. We talked about that. You know that you can't always take your business stakeholder at face value. Sometimes you need to push back a bit on their requirements. But overloading the complexity of report building to them has been quite popular over the last couple of years. A lot of tools have been out there promising a self-serve world.
00:33:05
Speaker
often is not the answer either. Instead, offer curated environments for your stakeholders so that they can look at, for instance, a small Looker Explorer or a small data set in Sigma or a relatively small set of dashboards produced in a tool like MetaBase or Alistix.
00:33:26
Speaker
where they can edit filters, where they can look at maybe a few different dimensions and one or two measures. Digital reporting on there, but not go outside of the bounds that you clearly defined for them, the guardrails that you set up for them. That's the level where I think data teams add the most value. They produce those small explorer sets, so the small data cubes almost if you want it in the old world.
00:33:46
Speaker
which are five, six different dimensions, maybe only one time dimension, one or two measures, serve that to the business end user. They'll be able to always build the exact reporting that they want because they can bring in that pivot field from the dimensions, they can run a table calculation on the measures and so on and so on, but you will not be lost in the maze that you might get if you just serve a big explorer, a looker, or a big data set in Sigma, or a big data set in MoTU straight away. So be very careful with your self-serve attitude.
00:34:15
Speaker
So yeah, focus on the infrastructure, make sure you select the text tag at the right point in time and don't overoptimize it. Don't forget about data modeling. It's really important to design it upfront before you start committing code and be very careful with self-serve. Those are my three opinionated tags on how to produce value as a data team, Harry.
00:34:35
Speaker
I love them. I love them. I think, you know, the first point you made, the marketing teams of these vendors are very good. Don't get suckered into them. Pick what's right for your team. The aspects around data modeling is still surprises me. How many people I speak to, you know, they say they're an analytics engineer, but they don't understand the different, you know, they don't even know the different modeling philosophies, which, you know, is a shock. So make sure you understand then they'll set you up for success. And then, yeah, obviously the final point,
00:35:03
Speaker
don't overcomplicate your self-service. Again, it links into that trust in the data. So perfect advice there for anyone that's looking to take a lead or is leading a team. It's a very easy checklist to focus in on.
Focusing on Business Solutions, Not Just Tech Problems
00:35:17
Speaker
I understand your business. The last thing I can say about the mistakes is in the amount of data teams that are primarily motivated by technical
00:35:25
Speaker
problems. It is a big trap to fall into. You're working on technical matters all day long. You're interested in technical matters because you're a data professional. But don't forget about the fact that at the end of the day, you're there to serve the business. If you can do it in an Excel sheet, you might want to consider doing it in an Excel sheet rather than a neural network.
00:35:45
Speaker
The world's best BI tool, right? Absolutely. Self-serve, right? Please don't do it in Excel sheets, people. Is it a figure or speech? No, well, look, Thomas, it's been great. I think there's been some really valuable advice there. And that really sort of brings us to the end of the pod. So I hope you've had a good time. But before you go, I got to ask you the quick fire questions, which we ask all of our guests. So the first one, Thomas, is how do you assess the job opportunity in your career? And how do you know if it's a right move? Yeah, yeah, yeah.
00:36:15
Speaker
So, plenty of jobs in data. I think over the last year in the bear market, I think data teams were not fully unaffected, but largely unaffected in my experience or less affected by layoffs than other teams. So, my assessment is that there will be a lot more job opportunities over the next six to nine months in data now that the industry is sort of put together again. So, yeah, you have offers almost certainly. How to know which offer is attractive. First of all,
00:36:41
Speaker
I'm afraid there's still plenty of companies out there that see data as a purely technical role. And those are one-way tickets to filled data team hellscapes in many cases. Not always, but make absolutely sure that when you talk to
00:36:56
Speaker
hiring manager when you talk to maybe to the founder in small companies that's very interviewing that they understand the value data brings that data is in the deeper part of their growth strategy and that they don't just see it as a way to get reporting into different layers of the business because that's not sufficient that's the main tip I would give their second tip is know what you're good at right
00:37:16
Speaker
Communication is really important as we discussed, but there's different layers and levels of communication. If you love telling other people about the insights you've uncovered, then analyst jobs are great for you. And if you're currently in an analytics engineering job, you might want to consider sort of moving a bit closer to the business, working a bit more on those actual insights and how to apply them to business value. If you are a great technical communicator, which is
00:37:40
Speaker
an incredibly underrated skill, I think, in many ways, then I think you have everything in place to become a great data engineer. And the best data engineers I know are excellent communicators, can explain even most complex pipeline container setups to the analysts in the team that might not have any DevOps or data engineering expertise. So I would follow my interest and what I'm best at communicating, because again, as we said earlier, the communication parts are very, very important here.
00:38:10
Speaker
Yeah, I mean, that's perfect advice. Know what you're good at, essentially. So what's your best piece of advice for people in an interview? Yes, well, always, that certainly comes down to communication. I think you want to show at any level that you're interviewing, that you're not just motivated by
00:38:28
Speaker
technology and tools, but that you're motivated by actually solving business problems. Now, we work mostly with startups and scallops, and I've worked inside of startups and scallops for my entire professional career. So this advice might be less suited to people wanting to interview at bigger companies that have probably more formal skills assessment frameworks and so on and so on. But for small companies, if you want to make an impact, be the data person that
00:38:52
Speaker
can explain very clearly what it is that they do and it can explain what business value that they generate. And that means that you should probably talk about projects you've run in the past and talk about not in terms of the exciting new technologies that you've deployed during those projects, even if it was a large language model, I'm afraid. But if you talk about what business problem that you help solve and what impact that they have on the business, talk about
00:39:15
Speaker
the lifetime value analysis that you quickly helped the marketing team with so they knew exactly what campaigns were generating, what amount of future revenue. Talk about the churn analysis that you helped facilitate as an analytics engineer so that your customer success team could reach out to customers that were likely to churn because you knew you found some correlation between
00:39:37
Speaker
a particular app uses patterns and people's likelihood to stop the conversions over the next couple of weeks. That's the sort of stuff I talk about because that will set you apart from the competition. It will make very clear that you care about working within a small company or in a small growing company because you're not just interested in becoming a better technical person, you're interested in moving the company forward.
00:39:59
Speaker
It relates back to the ROI. What was the response? Finally, Thomas, if you could recommend one resource to the audience to help them up skill, what would it be? Yeah, that's a very good question. So I'm going to say two things. First of all, just to be a bit boring, I'm going to talk about business value again. And I think that if you are a data professional,
00:40:18
Speaker
and you're not read into the sort of current events, economic news, economic podcasts, and so on and so on. Please consider doing that. Get a subscription to The Economist. Listen to a bit of the excellent Money and Economics podcasts that are around. It will really enrich your ability to talk about business, and it will enrich your ability to understand what challenges your business is facing. In terms of technical resources, go back to the basics, honestly.
00:40:46
Speaker
I think in data, we have a bit of a tendency to reinvent the wheel, I'm afraid. A lot of the technical issues or even the application to business issues that we talked about today, they were solved 30, 40 years ago in engineering, in software engineering. So for instance,
00:41:01
Speaker
domain and entity modeling, building good data model designs. That's early 1990s, end of the 80s, early 90s information modeling. Read those books if you want to, because they're really interesting and they talk about the exact problem that you'll face on a day-to-day basis. Also, don't forget about the classic high quality business books. I think there's a book called the Mythical Man Month, which goes back to adding more data engineers to an already delayed data team is going to make it even later. I always love the essays in that book because they speak.
00:41:27
Speaker
exactly to how engineering culture, including data engineering and elixir engineering culture, can go wrong quite quickly. So yeah, economics, podcasts and material, and don't forget about the classics.
00:41:38
Speaker
Yeah, I think that's great advice. Why try and fix a problem that's already been solved. Well, look, Thomas, it's been an absolute pleasure. I thoroughly enjoyed having you on. And yeah, I think there's some key lessons there for people to take on their journeys and to help turn their organizations from ticket machines to revenue generators. So thank you so much for your time.
00:41:58
Speaker
Now it's been my absolute pleasure, happy to continue this conversation at any point that anybody ever wants. And I will not stop posting on LinkedIn about this either. No, please do not. So yeah, if you found the talk interesting today, please reach out to Thomas. If you've got any questions, he'd be more than happy to answer and help out. So I'll put a link to his LinkedIn in the notes for the show. But thanks everyone for joining us. And thank you, Thomas. We'll see you all next week. Thank you, Harry. It was a pleasure.
00:42:29
Speaker
Well, that's it for this week. Thank you so, so much for tuning in. I really hope you've learned something. I know I have. The Stack podcast aims to share real journeys and lessons that empower you and the entire community. Together, we aim to unlock new perspectives and overcome challenges in the ever evolving landscape of modern data.
00:42:50
Speaker
Today's episode was brought to you by Cognify, the recruitment partner for modern data teams. If you've enjoyed today's episode, hit that follow button to stay updated with our latest releases. More importantly, if you believe this episode could benefit someone you know, please share it with them. We're always on the lookout for new guests who have inspiring stories and valuable lessons to share with our community.
00:43:12
Speaker
If you or someone you know fits that pill, please don't hesitate to reach out. I've been Harry Gollop from Cognify, your host and guide on this data-driven journey. Until next time, over and out.