Data Superstars are a Trap — Thomas in ’t Veld

Thank you, Tony, for the invitation. I felt very old when you said I've got a decade of experience here straight away. That's the first thing I'd say. Hey, Luke, I grew up in Belgium. I did physics. I'm a theoretical physicist, which means that I was not allowed anywhere near or lab with real life instruments and so on and so on. And it's still sort of the case. I'm very much in the statistics, numbers, computers kind of game. I moved to London when Big Data was the main game back in 2013.

I joined the consultancy as a data scientist, which at that point meant being a unicorn, being able to do everything with data from Excel sheets to massive Spark clusters that you had to manage yourself with the help of some Googled and Stack Overflow instructions and so on and so on. But I had a ton of fun for a few years and then joined a gaming company, mobile gaming company, one of the first big ones in London, where I grew the entire data function from scratch, built a growth engine, helped the company get acquired with 10x growth over six, seven months, and then go from there. That was a lot of fun. And Tasman, as a concept, was really born out of the work that

I did at that company because we wanted to bring that level of growth engine to as many other scallops and ambitions or organizations as possible. And now here we are. Yeah, almost 10 years later, Tony. We're having done that for about 75 companies. So, you know, it's been a ride. It's been a ride, but it's been a lot of fun at the same time. I'm now based out of Amsterdam, but still spent a lot of time both in Belgium and in London. So I'm floating somewhere above the North Sea in my natural habitat. Right. And, you know, I kind of want to start by asking this because I know you really well. And I know that Tasman is built on

Yeah, so we believe that we believe a few things. We believe that great data is necessary for sustainable growth. We believe that great data insights are necessary for great business outcomes. And we believe that great data capabilities are so strategically important that you need to own them even if you're a very small company. And so our mission is to enable that great decision making, the great business outcomes and the internalization of your data capabilities for any kind of company. Now, what we actually wanted to do was bring the type of capabilities that over the years were sort of the reserve of big companies

that had a massive data team and a lot of resources at their disposal. Try and find the leanest possible way to bring that type of technology to startups and scale ups. That's the core of our mission. Like find a company that really needs the data for growth that really sits on that inflection point where they're all of a sudden growing bonkers for a few months and realize that Google Analytics is no longer cutting it and they need to properly centralize the data stack and bring them in the technology that allows them to do that themselves. So at Tasman we do three things. We build the capability with the infrastructure that allows that. We build insight that makes the great decision making possible

and we make sure that we also onboard or accelerate an internal data team. So we always try to make ourselves redundant at the end of every project, which I'm being told is not great business, but for us, it works really well over the last 10 years. Well, it keeps consulting us happy as well. It keeps consulting us happy, of course. That's right. And it also meant that as a company, the type of people we have hired over the years, they're not classic consultants. They are amazing subject matter experts. They are the best in the field. They do not want to be outsourced to a client to sit in a client's office five days a week. They want to work with other best in

What do you want them to know what the company to see if they decide to go for you guys? Yeah, that's a good question. And I've said this for years. I think the combination of skills where you're technologically, where you're technically great, where you've got great business insights as well, and where you're a great communicator, those are three quite different skills in my mind. And for me, the best consultant, but actually also the best data team member because I've got a view on how internal data teams should be structured

and often they are best structured, I think, is internal consultancies. But the best hire for me is someone who can combine the technical excellence with the business empathy, with the communication articulation skills. And if you can combine or three, if you can be excellent at all three, then you've got to go in the future. Now, obviously, we have got data engineers who might be less good at the business side or the communication side, but excellent at the data engineering. But still, the three skills should be fairly well balanced in my view. And if you can do that, and you're trying to find a consultancy that matches that, try to consultancy that actually makes even their deepest, most technically sophisticated data

engineer slightly client facing. I think it's a very healthy balance, even in a big consultancy, to have your experts actually talk to the clients and not always put a project manager or a manager in the middle. And because I think the shorter the feedback loop, and this is maybe my startup background, the better the results are going to be, which is one of the reasons why we run sprints at Tasman rather than go for long projects because sprints force everybody to really work together with the client rather than work in separation. So that's probably my advice. If you're technically excellent, try and find that business insight and the common communication skills. If you create a business, try to find your technical baseline

and make sure that you really understand the technology that you're trying to deploy. That's kind of true. I've seen a lot happening that I don't know how much is your personal fall versus your employer, but sometimes you get inside of a corner and it's like, oh, this person is amazing at programming. Let's just make sure that this person is doing the programming and don't waste your time. I think it's, oh man, absolutely. It's really sad, I think, in many ways. It's like the, look, I'm very proud of the Tasman, we're getting very close to 50% gender split as well in the team. One of the reasons why we sort of strove for that is because we think you need a very

looking for a job in that consultancy, look for a place where they will allow you to grow in all of the access. Yeah. But if you're forming a data team internally, yes, you might not find a person that is good at everything, but make sure that across everybody in the team, they're well balanced. Yeah. Good balance of skills. Hire your compliments is always a good thing. If you're the first data person in the company, the first decision, the first decision I had to make when I started hiring, which I completely messed up, as you can imagine, is what is my compliment? Is my compliment someone who is because I was a bit of a hacker, I was really good and sort of

very quickly under a lot of dopamine induced pressure, getting out massive data models in order to make the board report on time for Monday morning and so on and so on. I was never going to be the person who would be able to sit down and spend four months building the sort of most rigorous data model at that point. I had to teach myself that later, but still at that point when I hired my first direct report, I hired another sort of hacker. And that was a mistake because at that point I didn't really consider the fact that we probably had to rebuild the data model from scratch at one point. And then six months later, we were still in the same messy data

model thing because I would hack things together and they would hack things together and no one would really stand still and say, hey, hang on a second, let's start in the definitions here a little bit. So if I go back, I will probably say, yeah, hire a compliment, get a diverse set of profiles in there, make sure that you do not hire in your own image because you're going to do a better job if you've got a diverse set of people in your team. That means backgrounds, it means capabilities and skills in all three levels. That's a lot harder in practice because I've been in companies that have very strict and very long interviewing processes. But then my experience is after two

months, you realize like, oh, okay, you're like, how can you find out if somebody is going to be a good compliment in a, I don't know, I guess you have like three to five interviewing rounds, something like that. One of the ways it's more and more meta than that, I think. So I can talk you through the interview process in a second because it's interesting because it's changing rapidly at the moment, of course. But I think one of the ways that we have gone to ensure a diverse set of people in the company is we've been quite sharp when it comes to role definitions. We actually built a whole roles and skills and responsibilities matrix three years ago when we

were only 10 people. It was really early. I think it's probably a little bit too early, but it tells you something about how serious we took the, hey, what roles and responsibilities to actually meet in a company as we grow. And that meant that all of a sudden we had a very good definition for not just what a data analyst does, but what a level two junior data analyst does, what a level four senior data analyst does, what a staff data analyst does, what a data engineer does, what an analytics engineer does. And almost by virtue of that, the people we hired over the last three to four years, they all have this expertise in either data analysis, analytics engineering, or data engineering.

tests and so on and so on. And the reason we all did take home tests was they are an easy way to sort of make sure that the super confident people who don't really have confidence problems in the whiteboarding interviews in person and so on and so on, that they're not get a sort of unfair advantage over the people who are actually really rigorous and good if you leave them alone for a few hours. But of course, take home interviews. They don't really have that that variance in them anymore, because now it's really hard. Now you're actually comparing how good someone is at deploying cloud code on their on their own on the interview process. There's still really good uses for them.

We use some of them as shorter ones as filters in the start of the system. But for the engineering side, we've now moved to much more of a co-development kind of interview session where essentially it's a three hour block, two to three hour block where you don't need to prepare anything, but it's just two, three hours where in a quiet way you're working with two or three of our other engineers on a call on what is essentially a real life problem where, yeah, we are going to just sort of do cameras off for half an hour and let you just work quietly. And then you pop up again and ask some questions and then we help you along the way.

And you go away again because that reflects our day to day work a lot better than any other take home process does. And then the rest of that's the core of the interview process. The rest of the process is around filtration, making sure we know who to talk to in a long list of candidates and making sure we got a good assessment of what people's skill based skills are. But yeah, it's a lot of work to get a good recruitment process in place. I'm very interested in your experience, of course, having worked for a much bigger consultancy, how you see this happening at this point. Well, yeah, it's well, actually, just to recap, I do think that my tip, if you're looking

for a consultancy, is look for one that has very well defined roles. Yes, that to me, a lot of difference. You don't want to apply as a data scientist to end up doing Excel work or any permutation of that. But yeah, I'd also say that if you're looking at the market at the moment for a consulting job, find a consulting company that has a very clear definition of what I mean by being a native. Everybody out there thinks of themselves as an AI native agency. But right now, there's two reasons, I think, to be a consultant at this point. Either you're very early in your career and you're looking for a place where you're going to learn a lot in a very

short amount of time, actually, probably join a bigger consultancy. They're going to have trading programs. They're going to really propel you forward. They're going to give you ownership. You're going to you're going to work very hard, but you're going to learn a lot. I mean, I would I would, of course, also argue for something like like Tasman, but we're never going to be as great at training programs as the bigger consultancies are. So for us, I think maybe it's the second type of why as a young data person, you might be looking for a consultancy at the moment. We are great if you've got a few years of experience under your belt and you just want to sort of ramp up your experience

and look at doing a bit of very interesting work for six, seven companies for a few years and then go and really level up your career from from from from there. Maybe there's a third category of a consultancy. If you're already like a pro in the field, you've you've done the rounds, you've worked with three or four companies, you've really built yourself into a senior data practitioner with a particular expertise. And a consultancy is also great because you can be the sort of gray hair brain in the middle of a project and really make sure that things go go go well. But I wouldn't necessarily see consulting as a career on its own in the same way that that that that might have been 10,

15 years ago or that it will be a management consulting or something along those lines. I think the most interesting careers for data, I think, are always careers where you can pivot a bit from in-house to consulting to in-house to consulting use distancing, consulting to really propel your career and your knowledge forward. You know, it's funny because if I had to choose again, I've also worked in a lot of consultancies. I would choose a small one once again. Interesting. I've philosophically just in context, I've worked in three different consultancies and a couple of times I saw them from very small to becoming very large. And I immediately saw like the culture change after 50 to 100 employees regardless. I think maybe scaling

consultancies are the worst. Well, I don't think it's about bad or worse, but my theory is the worst position to be as a consultant is being in the middle of the fact of your consultancy. Because the best consultants and what best constitutes is very subjective. But generally they're the ones that are going to be introduced to the most exciting, most interesting, most heartbreaking clients and assignments. And those ones are going to have like a really cool experience. And then the very new ones, the company is still going to start investing in them and they're going to come along with like the most senior every now and then to shadow. So that's a really cool thing. But if you're somehow in the middle,

There's a lot of stuff to dissect there, but I will say it's, it depends on what

someone like, just give me the space. I'll figure it out. Let me do it. And I think the size of the company is indicative, but it's not necessarily a guarantee for what will be supportive, right? You can be in a 10 person consultancy and it can be very hierarchical. And it's like, you do this and don't, don't do other stuff. And you could be in a hundred person company where you're enabled to do this. And I think what you're mentioning earlier, like you don't really have an analytics and an engineering team. It's more like packs. This is something I'm seeing with my clients as well. Right. Because you see like this sort of, um, AI is sort of increased the appetite for

brings into the app or so. Um, but I mean, even by listing all of that, those are very different skills. And so the question is more as a fast going company that has one shot to get their data stack sorted. Are you going to take that risk? And my, um, strong advice is don't take that risk. It's not worth it. Right. It's it's it's, it's a single point of failure. You don't know what you're going to get. It's very hard as with overalls to know in advance whether a superstar is going to work hard on earth or where they even there. They've got the right abilities. And even if they do work out, they might quit after 12 months and then you're

nowhere because you don't have a team to sort of fall for fall back on. Um, I will explain this and illustrate this with an anecdote. So I, I, I was that single point of failure data unicorn at the mobile gaming company called peak that I joined in 2015. Uh, and I did eventually build out the data team and so on and so on. But that was after I first led not just the data stack built or the data model built, uh, and the build of the growth engine that allowed us to understand which of our customers were high value and therefore which campaigns were, were, were high value campaigns. Um, I was the most responsible for all of the data analysis of the, uh, the due

diligence round that was happening by the company that was trying to acquire us at that point. Now I almost tanked that due diligence round twice because I couldn't get the data models in such a position that it would answer the question. What does the lifetime value for this cohort in the same exact way, two days in a row and the company acquiring this had a small army of accountants looking through the numbers and saying, well, why are these numbers like two, two, 3% different? And if you're, if you're marketing growth analyst or super sort of data unicorn, like I was at the time, you're like, ah, it doesn't matter. It will be all right. And there's two most numbers we bet you

if you don't like today's number, that's not okay for, for, for, for this role. So yeah, we, we had some big issues in the due diligence there that, uh, that, that is probably the founding's to guard the issue for why the first thing I did at Tasman was, uh, was actually get really good at data modeling. We're still very much a data modeling forward, generally believe in the importance of a properly domain and entity and objects modeled layer in your data model that makes your entire data model scalable. And that makes the, the business logic static in your, your data model rather than something that you always have to redefine. Um, so this is just from lived experience. Again, it can turn out very well.

If you hire a data superstar unicorn, but in my experience, it's much better to focus on what is a good small data team that you could build out instead. Get someone in from the engineering side, get someone in on the analysis side at minimum, because those are two completely different disciplines with different and almost orthogonal incentives where the analyst is always going to be focused on, uh, how well is the quickest, hackiest way I can get the data in such a position. I can build proper dashboards on top of it. And the engineer is always going to be in the position where they're going to try and build the most scalable, most elegant framework to support something the analyst might one day want to do.

And those are two very different questions in incentives and a great team does both. Now, um, it's hard to find. Typically, sometimes if you only have budget for one data hire, it's really hard to hire for as well, because you don't want those two people to be juniors, right? So this is where Tasman comes in. We offer fractional team services, and this is exactly why a fractional data team is such a good fit for startups that are starting to think about the first data team, because for the price of one, 1.5 FTE, we can say, well, here's a team. You don't have to decide whether you're going to hire an engineer or an analyst. You can get the engineering and get

Isn't that, that's a, that's a big difference there. So this, this is where, where I think our point of view comes from. Data superstar is really enticing or really, but probably one of the bigger

mistakes and more classic mistakes because it makes sense on paper in theory for, for startups and scaleups to make when they hire their first data person. But I can totally imagine too. I mean, now it's even more tempting because you see like all of these AI agents and you're thinking like, well, if I have one superstar, now they can have the output of a team of 20 people. It's closer than ever. As in, I wouldn't be surprised if a year from now it is actually possible to run an entire data team with a set of really great contracts and agents and so on and so on. My experience though, at this point in time in 2026 is that the best users of AI

in analytics are people who are insanely great already at data engineering and analytics engineering and are using it to go from being a 5x engineer to be a 50x or 100x engineer. I find that the risk of taking a close box approach to analytics, whether it's in engineering or in the actual proper kind of deep analytics. Is too large to entrust to a single person who might be a bit junior, but things they can do everything AI enabled straight away. Now this might change in the next six to 12 months. We might get great at at a genteck analytics, but just recently even anthropic came out with quite a long blog post talking about how they do analytics themselves internally. One of the things they point

out is they have a human curated semantic layer on top of their data warehouse that they say is vital to the functioning of any great a genteck solution and I wholly subscribe to that. I've definitely seen this article. I think we can conclude Kimball data modeling is still alive and well. That's I'm gonna say. So long ago, it is not data. Actually, it's in the data modeling in the middle of your data model and then Kimball to kind of build presentation models, but that's that's we can talk. We can talk. So you did mention before like it. It's really important for companies to be a native in the right way. So I mean, obviously, we've talked to a lot of

different people and they have very different opinions of what that means. What does it mean for you? So I can't comment on what being a native means for a product business, for instance, or or or a retail business because I'm not a product person. I'm not a a a operations person in a large multinational enterprise and so on and so on. But I think for analytics forward data forward companies don't want to make data really important part of their growth strategy. For me, the AI nativeness means that you are able. I think it means two things. First of all, you're able to make decisions really quickly. So for us, analytics at the speed of thought has always been this sort of pipe

dream of how can we get companies as close as possible to actually being able to understand what the users are doing, what the app is doing on an almost continuous basis rather than having to wait for the data team to build a report, which might be two months before you get iteration number four of the report. It finally shows the correct number. So we instead what is the way to get as quickly as possible to the relevant actionable novel inside that you need to know to make the decision right now that you need to take right now. And I think AI native slowly gets you there if you get to sort of right systems in place. The other bit of AI native means that

your data team is accelerated in Saley. And that doesn't mean, as we said a few times earlier, that you're going to replace your data team by one person who has a cloud max license. You're going to replace it. You're going to have a data team of maybe two or three people who are now be able to produce the output of a team that used to require 10 people, 15 people. And most fast scaling businesses, trust me, actually have a need for that amount of data. And that is output because anybody who's done a good job when it comes to data for companies, organizations in the past knows that great analytics begets more great analytics. The sort of questions don't stop if you

build a great dashboard, they only start at that point. And so being able as an AI accelerated data team to serve that with fairly low FTE, but high amount of output for me, it's an upside opportunity rather than all of a sudden we're going to all lose our jobs to cloud code. I don't think that's quite true. And for us at Tasman, what AI native means for consultancy is two things. It means very low context switching cost. So for us, we need to be able to swap quite rapidly from client A to client B because most of our people, particularly the seniors, are probably four or five clients they're working across. So they need to be able to go insanely

quickly from say Ecosia to Pension B or the Earthshot price. And AI really helps there because you can have your project, you can get read in really quickly there, you can share context and knowledge with each other and so on and so on. Secondly, additive knowledge, meaning that rather than and this again comes down to the fact that we see data consulting at its best, not just as a technical solution, but as a business solution as well. Any project is littered with institutional memory around why did we make this definition this way or that definition that way or why you're prioritizing the marketing report over the product report and so on and so on. And in the past it required really

conscious note taking or conscious sharing of information to communicate that into the wider team. And now we've built an internal system which we call Tasman OS, which for every client we have, compiles everything from the first sales notes all the way through to what we do sprint by sprint, all the way through to what we do in product releases and data product briefings and so on and so on. So that any new person who just joins the team today can just fire up cloud, connect in two Tasman OS and say, hey, what's the latest on Visana and get an immediate readout with everything that's relevant for them straight away. That's for us what AI Native means. And then of course the obvious acceleration

constantly thinking like, oh wait, I could maybe use this interaction and this. I've been using a lot of AI data before. I don't know, more than a year now. And every other week I come up with something and I was like, yeah, how come I didn't think of this? Exactly. Why have I not used cloud for this yet? Yeah, it's a thing. I'll add to that that being AI Native also means taking risks. So for instance, I think a lot of us, if you use AI, for instance, to build a little strategic framework or a memo document or something along those lines. Being AI Native means that you're not scared of sending through something that is quite obviously AI assisted into the

rest of the company for review. Whereas if you're not that AI Native, you might actually say, no, actually, AI might have helped me to generate this, but now I'm going to write my own version of it myself just to make sure that there's no traces of AI generation in there. I think the step you have to take is to realize that, no, no, it's fine. It's fine if there is a little bit of AI sloping in there as long as the big picture is correct and as long as the sort of point that you want to bring across is correct as well. I'm on the edge of envelope there a little bit to the frustration of some of my team members, but it does mean that we

are able to move really quickly from a strategic point of view. I have things like client requirements in the gathering. It used to take us two weeks to write notes from a requirement session because it takes quite a bit of synthesis work. Now you can get a rough draft, rough first draft ready in an hour, with the right set of skills and contracts to, of course, have internally. That is a game changer because all of a sudden it means that we can move much faster and be less like stuck with bottlenecks in many ways. You know, coming back to another conversation that we had a couple of episodes back, I think being AI native has also something to do with being good

enough with governance to be able to keep AI in place. Yes, I agree. And also being able to understand what makes things robust. And so, for instance, we had to replace our head of engineering last year and we made a strategic decision to not bring in a like for like very seasoned data engineer. But instead, we hired a chief product and technology officer, someone who brings a lot of product thinking into the head of tech, head of engineering role. And I have no regrets there because he's the one building the internal operating system at the moment and the main value add to the main time is plenty does is the product thinking around how do we build the governance? What are the rules we put in place? Where

do we do the hard coded logic versus the soft AI generated logic here? And so building the sort of scope requirements framework around that. It's a message we've always preached that has been around your data work is only strongest requirements you have around them, the acceptance criteria around them, which is why we're big fans of data product thinking. Because the worst thing you can do is build a big omni topic or look or explore with all of the different fields that you can think of in there and then hand it over to the business stakeholder. No, you need to give them you need to treat it as a product. You need to give them a way to use it. You need to give

really forward thinking I'm just trying to keep up as best as I can hanging on to the sort of rocket ship. I think there's a lot of noise out there. So I do rely on a bunch of channels that get our good filters. I think there's a few really good blog writers out there Ben Stensel, for instance, is one of them, like one of the better ones, he founded multi analytics back in the day. And now, after selling it, he's actually been one of the better thought leaders out there. I was really like your orchestra Hugo Lou, a newsletter that he sends out every every few weeks, we did partner dinner with them a few weeks ago where we were able to really bring a ton

of thinking around context layers in there, for instance, and then now a few weeks later, all of a sudden, everybody's talking about context layer. So we would like to think we're pretty forward looking there. I've got also here's my cheat code for a good data practice. Good data practice almost always stolen from engineering. So find the problems that most data teams have at the moment and then think about maybe software engineering has figured this out 20 years ago and has come up with solutions for it. It's one of the reasons why we're such big proponents of object entity modeling in a data model is because engineering figured this out 20 years ago, that that's the best way to build an internal

representation of a business model in a production system. So lift and shift, not a problem. Same with things like product thinking engineering figured out long a time ago that the best way to make software work is to add product managers to two software teams. So why not the same with data, right? And I think now with context, I think it's the same thing. You are trying to build a gantic analytics that is really going to struggle with not just trying to make the definitions consistent from query on a Tuesday to query on Wednesday, but also with trying to understand what's the wider point of view, what's the wider purpose of this insights and these analytics bits, what has changed in the

business of the last couple of weeks. And there the obvious question is, well, you do need to just feed in what is actually happening in the business one way or the other to the gantic agents and then make sure that you've got a really strong separation concerns in there. So coming back to the AI native point, we think in AI native data stack is a stack that by definition has separation of concerns at a few different levels of abstraction. And that's an engineering principle we're applying here. There's nothing new. It's just about make sure that your source of truth for data is a different layer in your data stack from the semantic layer that tells you not just the AI agents,

but also your BI tool and your analysts, by the way, how to join tables together and how to calculate metrics like lifetime value or VAT or average order value and so on. And then another layer with the context that an agent needs in order to take a messy question from a CFO on Sunday night and translate it into the right set of semantic queries into the right set of insights that come back on the back of that. It's all kind of every single project. I'm a physicist. I've been taught extensively and against my better nature of being lazy of my studies for a number of years that the best way to solve a really complex problem is to find the

I'm talking about in my personal case. I can very easily name you the old and old me, but I'm sure you must have like a much bigger list. We don't have a massive list here because for us any project we run were opinionated about the stack. It needs it's typically greenfield stack. But we're also agnostic. So we typically do follow our clients recommendation and insights there. But I think going through the stack when it comes to data loading, you're looking for tools that bring great governance infrastructure as code integrated orchestration. And I think great understanding of what the data team actually needs from an extractor load pipeline rather than what an engineering team needs from it. And then automatically you look at the

established players like five train or segment and go like a very clunky great tools, but you use them where you need big as a lace and quite a big sort of team. If you're a small company to moment, the OT and particularly the deal to help run a pro version of that which I work bench that that they launched recently is a phenomenal engine to connect to almost every single data source out there and have a really great way of connecting into any of your warehouses. And do a ton of debugging and I followed sort of really great Unix type philosophy to one thing, but do it really, really, really, really, really well. And because they're all infrastructure as code. This is, by the way, one of the key

requirements for any tool we use. It means it's easily version controllable for the sort of playbooks you build with them. And they've got an amazing plugin for amazing skill set for cloud code and codecs and so on. So you can just kind of integrate it in your native development workflow effortlessly. Now I think if I what has changed over the last year is that I can now run a really high and data stack just on my machine with the OT hub as the core extraction load framework. Local ducty be which which if you don't know it's it's it's a little bit like SQLite, but it brings a ton of analytics rigor into a local database as well. And mother duck is the cloud data

you try to model it still dbt very excited by the fact that this just come back to five trend in many ways, but that the dbt five trend merger is actually giving dbt core a new lease of life. Which means that open source lean projects use dbt core 2.0 when it's in general release have the great new dbt fusion engine in there keep running your projects as close to the metal as possible with version control and everything and so on and so on. Works great with all the rest as well works great with mother duck what's great with the UT hub and so on and so on. And then for visualization once you got your systems in place notebook style

marimo is a really great tool for amazing interactive graph notebooks rather than linear notebooks which if you know you know and then for bi were partners with omni have been for a long time now because they have taken what used to be fairly stagnant bi space dominated by looker and essentially built it into a semantic. Source of truth where for small data team you do not need a separate semantic or context layer just bundle it into your bi to use that as a platform that everything else is carrying and that's what what omni gives you. And I think in a very elegant analyst Ford kind of way so that means that if I say you just need two people in your data

team if you're a big company that's very much true because of these tools that enable you to do all of that at the moment and that's your data stack right now yeah. Nice really nice list for anybody that's looking for what skills to learn this summer and that's now I'm hoping that there will be more coming out of the next couple of months because yeah it's never been as easy to code really great. Data engineering supporting solutions as it is at the moment, but it's also never been harder I think to market and position yourself well so always comes into. So what I'm hearing in this conversation if we're talking about how to hire good people how to be a good data consultant

how to work if AI and all the tooling I guess the way I would summarize this conversation and some of the like larger principles is you have to be inquisitive right you have to ask questions have empathy and really ask through slapping AI tools on someone that asks for questions is not going to work. You need to be proactive and you keep track of things and see where the industry is going and be open to try new toolings and new ways of working and three you need to have discipline and I think this is what what really sort of strikes me in your choice of having someone that's really think about the product. If we're thinking about if you have some

that's really good at pushing out a lot of philosophy and really good asking questions that can still build like a bazooka lot of things that you don't need. You need some discipline something that says these are the key tenants of what we're trying to achieve and these are the directions that we're going and I think it's interesting to see like how that be I space is also evolving with the context layer and semantic layer and all of that. What I'm seeing personally with a lot of my clients is now that it is easier to build custom experiences I see a divergence when it comes to data user experience and we've talked this before on this podcast as well but some people

Yeah in very interesting points Tony. Just a few maybe few reactions first of all on discipline I think it's true that that in order to be successful as a great data person you need to have focus and be able to focus remorselessly on what actually moves the needle now the thing is that's not something you're supposed to figure out all by yourself and so maybe just a few pointers there if you're struggling with. Kind of random ad hoc requests from your from your from your your your stakeholders don't just build the engine that answers to random ad hoc requests instead think through. What is the way I can help my business users asked right questions that's quite an important skill which is quite so

important you have the business understanding and the communication skills because. You start trying to accept the sort of no no don't just ask about yesterday's course lifetime value ask about how it correlates with the campaigns on Facebook that they came from or how you think it might evolve based on the dynamic discounting campaign marketing is running over the next couple of weeks right so that that double business context in there, which is one of the reasons why I think a data team. Should be a bit of an internal consultancy understanding where the business is going and not just what the technology does. But focus also comes from having a very clear partization from the business sometimes you're lucky and you

come into business that says. Tony we we know exactly what we're doing over the next six months we're going to focus completely on acquisition of new customers you're going to sit next to Joe head of marketing you're gonna make sure that he's got the growth engine and is exactly all the different growth metrics that he needs in order to run the best fucking marketing out there. Usually you don't get that level of clarity from your your your your leadership and so you have to figure it out yourself you have to sit down with your CMO your CFO your CEO and have those conversations even as mid level of junior data person because they are only positive. I have those conversations say what are

in order to bring the business forward. I couldn't agree more with that that is I forgot the rest of the question Tony. That is perfect. I think you got right to the core there that is exactly what it's about and I like that you gave that counter you know because sort of that question invites you to the next question. I think it's people thinking again about oh what are all the things that could be building where instead of asking the question what should I be building, which sort of gets back to your point that any data team is actually a sort of mini consultancy for their company I do see how you how you get to the conclusion from that.

I'm biased obviously but yes absolutely that's hey and also talking about sort of journalists versus more specialists there so great the best specialist in my experience are really good at a few things but they've got a really adequate if not great understanding of the rest of their industry as well so there's always T shaped as a sort of kind of kind of model. I wish I could say that that's why we're called tasks but this is sort of T shape generalist bit but that's that's not the case. When we first started testing the first five hires were generalists there were hackers there were I didn't hire my compliments I hire people like me that were able to run into any problem and

figure out the sort of 80% solution there which was really key in the first five to 10 projects we ran because speed and getting to zero to one was most important there right now after I'm pretty five we started to shift is quite consciously to know now we need to get a proper gray beard in so we worked with a gray beard see CTO for two years it was amazing at helping us understand the actual technological complexity of what we did and so on and so on. We had to hire more specialist people who come in with an actual formal education in data modeling or as formal as it gets who actually understood the difference between Kimball and in the modeling and

all of those those different things to in order to sort of make it to 10 15 people and keep raising the bar in quality and right now I'm very about to say that all of our projects have a much higher bar of quality than the first few projects that I read myself as a data journalist seven eight years ago and part of it is that really conscious conscientious hiring of specific roles with a specifically high quality bar but still having the broad skills and capabilities in the background there absolutely and that also means that we're all very high native if I'd hired just sort of. Classic SQL Server data architects 10 years ago, right. I don't want to kind of slag over already

weeks every six minutes at this point. Yeah. Now for all those people listening in that also don't want to do the coolest thing but together a few Thomas where can they find you and what's the what's in the store for the future of Desmond. Right so we're at Tasman dot AI t a s m a n dot AI. I won't spell AI out. I think you know how to write it. We are providers of professional team analytics capabilities. We do that for scale ups and we do that for larger businesses that want to bring the leanness and the nimbleness of scale up analytics into their big team. Typically we work with transformational projects for those bigger companies for small companies we we come in when you

have got an existing data team that your bits not under you need some help on better data modeling better governance better AI enablement. We're a team of 23 people based out of Amsterdam and London. We are fun people. A lot of us are in our 30s with young kids which builds a particular kind of culture around around really efficiency of work but still with a good work life balance. We publish a monthly newsletter which is a lot of fun finders on our website at tesman.ai for our blog as well where I tried to post every two weeks and I'm on LinkedIn as Thomas and felt where I tried to post weekly with my thoughts on what's happening at the moment

in data and analytics. For those listening in we'll have all the links in the comments to be able to find all the wonderful resources Thomas and Tasman have and thanks again for giving us a master class and how to run a technology a consultancy and so many topics you still want to go into. I feel like there could be a part two, three, four, but for today. This was a wonderful conversation and thank you again for joining us. Thanks for the pleasure. Thank you.