Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Danilo Sato: AI Readiness
50 Plays1 month ago
Danilo Sato, AI Platform & Engineering Portfolio Leader at ThoughtWorks (16+ years), joined Yuliia and Scott to discuss enterprise AI readiness assessment and how implementation is progressing. Danilo shared a fascinating case study about how technical solutions often face non-technical barriers. He shared his views on data mesh principles intersecting with AI solutions and treating AI models as specialized data products.
Danilo's Linkedin Page: linkedin.com/in/danilosato
Recommended
Transcript
Introduction and Danila Sata's Role at ThoughtWorks
00:00:00
Speaker
Hi all, it's 3D to talk, Yulia and Skoza back. And we are recording this episode together, together with Danila Sata from Sotworks. So Danila, happy to have you. Thank you, thank you for having me. It's great to be around, talk to you guys. Okay, please jump in, introduce yourself and tell about your new gig at Sotworks.
00:00:29
Speaker
Sure. So yeah, my name is Danilo. I'm still at ThoughtWorks, I think. I've been here for a long time, almost 17 years now. 17. Yeah, 16 and a half, I guess, if you want to be precise. Oh, wow. But doing different things, it's one of the reasons I'm still around. And yeah, I've been i be kind of moving around. So I was playing this role as the global head of technology for our data and AI service line. And recently, they asked me to take a ah ah leadership position in the service line again to drive our AI platforms and engineering portfolio.
00:01:05
Speaker
So I'm right now in the process of figuring out what does that mean internally, assembling the teams, and also like how am I going to work with yeah other the other functions, with the marketing team team and everything. So it's it's interesting, because yeah it's ah it's ah it' an another transition. and But I like to be involved again in the service line. And I think AI is the hot topic anyways. So it's it's the place to be. So I'm quite excited about this new role.
AI Excitement and Readiness Challenges
00:01:32
Speaker
Okay. Okay. No, it's definitely exciting. Yeah. and And I'm, I'm excited for you too, because I think it it is one of those things where.
00:01:44
Speaker
I know a lot of people rushed into AI way too early and then got burned. And so like having that that thing of, especially when you're talking about the technology, not just the services line, but the technology aspect of it, where people are like, can I just buy AI? Our past guest, Maya, had talked about um somebody saying, can and could we just rub some AI on it? like Their board of directors were like, hey.
00:02:10
Speaker
It's pretty cool. Yeah. Oh yeah. Sprinkle. Yeah. but I think she actually started using rub on on LinkedIn as well, just being like, it's no longer sprinkle. It's just like smear it up on there and just be like, yeah. And and it just fixes it, right? It's like, yeah ah. So like actually making progress and through the technology side, because there's some people that just try and buy it. And then there's some people that are like, no, you must build everything. You must practice it all out. It's like this mix.
00:02:39
Speaker
is is something that that I don't think we see, but yeah I think Yulia had some ah interesting questions that she wanted to jump into because as a technology provider as well herself, but like, how do we think about, like, where where are you seeing those gaps and stuff like that? So Yulia, I'll kick it to you to actually ask the questions. My question is, do you, like, you know, you work with a lot of customers at Tiltworks.
00:03:06
Speaker
How do you feel? No, no, no. Let's put it this way. Rate the readiness from one to 10 to, you know, to go for AI, where 10 is, you know, ready, 100% ready.
00:03:22
Speaker
Ah, in general, I think that that's a difficult question. It's we go for average or average. Yeah. But I think it would be like average score, actually, if I'm looking across the board, because first of all, the clients are the people that are probably adopting AI at the edge.
Defining AI Readiness and Its Dimensions
00:03:40
Speaker
They probably not our customers just start to start with. So like we we tend to work with like a segment of of the market and one way I like to put like what dot works as well is like we we try to keep up with the trends and you know like what the ah big tech companies are doing like the ah model developers and you know what's the latest with technology and then we help spread that across all the enterprise market like you know some of the industries that lag a little bit behind and it's it's trying to bring the good things about what what the new technologies enable companies to do and we help kind of raise the bar for everybody
00:04:15
Speaker
So we're probably skewed that we will work with the companies that are less ready for AI. But I don't know. I don't want to be overly cynical to say the whole industry isn't all ready for AI. But like we tend to find a lot of client clients that are not fully ready, for sure. And to be honest, like defining what it means to be ready is one of the conversations I'm having at the moment. like How can we help understand different different dimensions of being ready? Because yeah, they might be ready one angle, but not another one.
00:04:42
Speaker
and no Okay, okay, you know the follow-up question and then. So how do you assess the company? Is there really for I do injury or no? Yeah. and And if I can add one little wrinkle to that, go ahead because you did said, are they fully ready? Like, how do you assess not just yeah one or a zero, but like, how do you assess in what parts or in what ways, or like, how do you actually go in and have these conversations? And day one tells tell somebody, not necessarily their baby is ugly, but that their kid is not ready for school, right? yeah yeah say
00:05:21
Speaker
Hey, yeah your kid is not ready to be, you know, riding a motorcycle. Therefore they need training wheels on their bike. Like, you know, you don't say, Hey, your, your company isn't ready. Your company sucks. But like, how do you have that conversation of.
00:05:38
Speaker
getting that, you know, how do you, how do you assess it? and get in hu style where where Where they can make progress now as they're advancing themselves as well. Yeah, definitely. It's, it's, it's kind of like, we, we, we don't like to talk about like having a maturity model, like as a way to score the companies, but I like the idea of like heavy, uh,
00:06:01
Speaker
a multidimensional view of things. so we but The conversation we're having now is like friend different dimensions. i guess so The first one that's probably the most important one is like is, are they aligned to what the company is doing in terms of what they're trying to do? it data and AI, you can put both in the bucket. Because you know there's been a lot of experimentation and building proof of concepts just to play around with the new technology, which is a value for you know to understand what might be possible or maybe what skills do we need to develop. But you know like if you don't take it out of production and you don't unlock some kind of new value, then the CFO at some point well will start asking questions about why are we investing in this in this and not getting the results back.
00:06:45
Speaker
So like there is an aspect of aligning the strategy and understanding, are these use cases really going to unlock the benefit that we expect? like
Deploying AI at Scale: Challenges and Governance
00:06:54
Speaker
you like Does it have to be AI to deliver the value? like could We solve that using something else. So maybe one most important dimension is that one is like the business alignment of what they're trying to do with strategy.
00:07:07
Speaker
another Another dimension might be the, I mean, I love what we do is like, is the technology ready? you know Do you have the foundations in place? And you know do you have a platform that you can deploy all these things? Or like I said, you're just buying some stuff. You're just trying to smear some AI on other things. So at some point, if you really try to deploy at scale, then you do need more of like a platform to support deployed and operating for solutions.
00:07:34
Speaker
But there's a lot of things in the technology space about how you engineer those those solutions. How do you monitor how it's being used? Is it being cost-effective? Are you using infrastructure correctly? So like all of those technical things that we do, that it's interesting, but it's another dimension of readiness. ah There's another one that maybe is governance-ready. like Do you have some of the processes in place to help people use AI in a safe manner or like in a responsible way because it's very easy you know to build stuff out, just get hold of whatever data you have. and like You just just trump all of the the the good data governance practices. so's I think it's important, especially some of our clients in more regulated industries where like they are accountable to report on things. like They take a much more cautious approach. and that is
00:08:27
Speaker
that could be maybe the blocker right like it's like it's not ready that it passes all our governance compliance risk assessment things maybe it's technically built and if we think it will deliver value but there's still work to do to align on on the governance And then there's the the whole, the one that's also important, I guess it's more like the people aspect or the organizational, you know, ah people, the people have the right skills to, to use AI or to even to like a adopt AI, right? Because some of the AI solutions you can argue it would
00:09:00
Speaker
like I haven't seen anything that like maybe fully replaces someone, unless it's a very task-oriented role. right like It tends to be it helps you make some tasks quicker, and then you gain productivity. But like it hasn't fully replaced the role ah completely. But it does break the question of, like well, if if that's the proposition, if we're so arguing that the the value is productivity gain, then the CFO is going to say, how many people can we fire them to save some costs? So the there is a human aspect of,
00:09:30
Speaker
I don't want to be replaced by the AI. i don't like you know like People don't want to adopt the solution. Even if it's built correctly, if it allies to some argument of value, we put the governance in place. But the people aren't already to adopt it because it's threatening for them or we haven't done you know the ugly words change management for how do we get people up to speed. Sometimes it's even like reshaping the roles. right So we might have to work with the with the people departments. youll see like Do we need to change jobs descriptions or it could get to that level, right? Where it's like, oh, now the productivity is so massive that we don't need five people to do the job. Maybe one person can do it, but now it's a much broader kind of job scope because it's supported by some multiple or one AI solution. Right.
00:10:19
Speaker
So maybe like those four, I mean, i'm I'm kind of, it's not like we've got that documented fully, but like these are the, some of the discussions we're having about different different ways to assess. And what we see as well within a company, especially large companies, you will find pockets where like it could be when the firemen is more ready than another one. Right. So that's the other reason why.
00:10:37
Speaker
taking like a blanket score across the company might not be as useful but maybe if you work with the with the different teams of the different departments you can get something useful that helps them move to the to the next stage so it's reflecting on what you're saying It looks like what you guys do, you come in, basically, you know, somebody invites you, and they share with you the
Case Study: Automating Grocery Store Layouts
00:11:02
Speaker
use case. You start to check it how business profiles in use case, what is the technology, how data is ready, and you kind of start to and unroll in a way like
00:11:14
Speaker
What would you need to make it happen? What is, you know, what is the opportunity? What's lacking? What, like yeah you know, kind of do this assessment from different dimensions for a particular organization, for a particular case.
00:11:31
Speaker
yeah um But the sexual, it makes tons of sense to me. What was the most interesting case that you see that you saw and you can share with us?
00:11:42
Speaker
or you were actually you know kind of you got those uh shewers yeah i mean i i probably cannot say the clay name but it's ah it's an interesting story at least not we we were working with uh let's say a grocery company uh and they one of the things they do they do lots of things obviously but you know like how they design the store layouts you know which aisle which product goes on which aisle so like there's a there's a whole team of deciding what goes next to what and how does it flow and like what stays at the eye level versus so yeah they
00:12:21
Speaker
They have a lot of effort to do that. But the the way that it's done, like the store layout, is it's still very manual. So they have a team of people that have this expertise. And one of the questions to us was, like is it even possible to try to automate some of these or try to create some some store layout model out of that ah kind of book of knowledge that people have in their heads?
00:12:44
Speaker
and we We worked with them for a while. We built some prototypes like the just to show like technically it is feasible to try to encode some of the rules. like Some of the implicit stuff is often hard to to represent, but like that we could build something that a lot of the common case, like the model could represent, it could even draw things. and The challenge there was the adoption one that I mentioned, you know because it's like now that team of people that will be out of the job And then the other one, which was even more interesting that we didn't anticipate is the team that does this today, they come up with some layouts that they sent to the store manager was actually the one responsible for making the changes to the layout.
AI Models as Data Products in Data Mesh Architecture
00:13:26
Speaker
But the way they operate the store manager has.
00:13:29
Speaker
as a lot of say for what happens and what doesn't happen. So what actually happens in practice is like they would just override a lot of the things like even in the plans that they got from their own internal teams based on because he knows like this is the people that I sell to. This is the kind of things they like. They they have that local knowledge.
00:13:45
Speaker
ah you know the On the corporate side, yeah you you try to come up with this ah perfect layout in your head, but then yeah every time it gets executed, it's different. So we face two challenges there, like don the people doing the planning, heavy resistance to adopt something more automated, but then the store manager is implementing the plan, also kind of... they just had final say anyways and like they would override based on their knowledge which was interesting because yeah that it it gives you lots of new questions i guess you ask right it's like oh can we try to capture the actual thing that happens there because if we've got data about that that was a ah gap that we identified for instance just by doing this kind of exercise trying to automate it yeah is a child i think like what you're saying there is that
00:14:32
Speaker
that data work I've seen this when I talk to a lot of ThoughtWorks people. The data work um helps you capture the actual business process instead of the expected business process. ah yeah People above think that there is a store layout and you're like, no, like this needs to be very subjective. And but you have that store manager who has their own kind of particulars or whatever, and it's like, okay, they do this in this way. and you know, where is their tension? Where is their friction? And is that good friction? You know, friction can be a sign of there is value here, because we have to figure out what to do here, or it can be extremely bad. And so I think like, this is a game that
00:15:16
Speaker
idea that data work just has an answer instead of it reveals more and more about your business and what you should be doing. It's it's and something that comes up in every ThoughtWorks conversation because it is that rubber meets the road, right? Your your your plan doesn't survive getting punched in the face. no no ah No engagement with the enemy survives getting punched in the face. And that's kind of business is you're just constantly getting punched in the face.
00:15:45
Speaker
yeah they are stuff Yeah, the most positive analogy, but you know, a yeah, Yulia as a startup founder, you know that more. but that's That's why we like like agile mindset so much, right? Because like it's almost like you build that feedback into the process. You kind of expect that you're going to get punched. yeah So you prepare for how do we incorporate that feedback. What is the next round of questions or hypothesis that we can test it? But you're right, yes. This example I gave was trying to build a model, but like with data work is very similar. like yeah You'll find things by looking at the data that reveal stuff that maybe you thought worked in a way, but in actual practice, it's different.
00:16:24
Speaker
Danila, I have a question. And I was bothered with that. So not to reveal what kind of data you're taking input for this um um AI model or whatever where you had. But why it's AI? and And was it a large language model? or How did you do that? Like, why it couldn't it be a machine learning model? Yeah, no, that one wasn't even there.
00:16:55
Speaker
wasn't even LLMs around when and that story happened. So definitely we weren't using LLM. But part of that is is that was actually part of the discussion, right? Because like what we're trying to do is build Build a model to choose to try to encode the rules. ah But we didn't have data. So it wasn't like a machine learning model. But once we
Technical and Non-Technical Barriers in AI Adoption
00:17:15
Speaker
found out that is actually like the the layout is different than the team starting having some questionable like, oh, if we could capture the data about how it's actually layout and then the other ideas like, oh, we could try to capture
00:17:26
Speaker
ah but What do they call like footfall data, which is like, what are the paths that most being traveled to see like, is there a hotspot or not in the store? ah And so it it it turned into like, maybe we can use a different, different solution to to look at the problem.
00:17:46
Speaker
But yeah, that that one like for the the story, we we didn't get to implement all of this. It got blocked on that you know the adoption hump to the point that, OK, we need to stop and think about whether we want to actually do this. So I don't have like a ah nice ending to that story from our perspective, at least. But like the but learning, it was really interesting because yeah we were doing something technically difficult. that yeah We faced some non-technical barriers to get to adoption.
00:18:14
Speaker
ah This is hilarious. but yeah Thank you for sharing in the yeah details. um I also wanted to touch um about to touch upon data products, data mesh, and AI. How do you see it?
00:18:31
Speaker
he also you know A few different ways, I think. So like database principles, I think, touch some of those dimensions, right? Like when we talk about how we've got to do governance, how we're going to organize the teams to execute on things. But a lot of the product thinking, at least in my head, falls under the ah technical bucket for how do we implement these solutions. And it's something I was i was st talking through some colleagues. I've given a few talks recently about we can actually expand what consider to be a data product. Some of these AI solutions could fit as a quoteots data product in the mesh because you you need to consume data from other data products to train your machine learning model, let's say. And you have an output that's well-defined, which might be the the
00:19:21
Speaker
API endpoints where you but you you do inference for the model. So if you wrap that up, you know like inside, it looks very different because you're training a machine learning pipeline and doing feature engineering. Maybe it's different people doing it. But like from from a high level, that could fit as a data product in the mesh. It just happens to be an AI model that gives an inference that can be used by other but the systems.
00:19:45
Speaker
And so I've been kind of using that as a way to expand like actually different flavors of data products that like we could actually wrap a lot of the AI components as digital data products that fit in the mesh that will have a team that owns and evolves that over time and it's got a well defined input and output interface and obviously if If the type of products is different, then the platform needs might be different. And also the way that we govern and might be different. So in a way, if you're going to start expanding the mesh concepts, you have data products that are more AI, ML flavored, then the capabilities of the platform needs to evolve as well to support that. ah So an example, I guess, if we pick Gen AI, because it's the hot topic now,
00:20:31
Speaker
you could wrap up like a reg style application as a data product because you've got input is your knowledge documents maybe that when you ingest you do your i don't know gonna put in a vector store you're gonna create a knowledge graph or whatever uh and then your user query endpoint is when people are talking to the You don't use a query to ask something about your documents or your knowledge base. Then you've got the whole retrieval stuff. You're going to figure out which part of the query, get the relevant documents, do the ranking to pick the ones that are more relevant for for that query. Then you do the generation phase, you query the LLM, and then you return back the S to the user. It's go well defined, you put an output. But the platform that you need is out now I need to be able to she control and manage my LLMs.
00:21:20
Speaker
Maybe it's a vector database or a graph database where I'm putting that knowledge graphs. So like the the needs of an infrastructure and then all the control that we put around to govern a system like that is different than, you know, a traditional data product where you're doing data manipulation or transformation.
00:21:40
Speaker
And I've got something there, like a couple of little quick things that I'd love to wrap into the rest of the conversation without even a specific thing. But, you know, when I talked to Zmack and on Datamash Radio and had like those conversations with her, we were talking about the idea of a feature store going away.
00:21:56
Speaker
because that's just the mesh, right? Like you still store your features, but you you just treat that. And so I think that ML, like there is the input data to ML that you can have as a data product, but I think it's it's interesting how you think about that going forward as to, is this reusable by others? And and so the other thing that I'd like to wrap into the rest of the conversation is We were talking about data products, but you you talked first about product thinking. And one thing I've had a ah difficulty with that I talk about way too much, Julia will probably ah confirm this, but the difference between data product as the point instead of product thinking that the delivery vehicle for value through data is via a product,
00:22:51
Speaker
And the point is to deliver sustainable, ah you know, um persistent value through, and that's the best way to do that is via a product and therefore a data product but like when I talk to AI people, or or a lot of people that want to use AI that aren't deep in this, you know if you talk to like a you or a Paco Nathan, or you know Paco Nathan literally got his PhD in AI models, or AI and ML in um the 80s. The guy's been doing with this for for a very, very long time.
Agile Methods and Product Thinking in Data Solutions
00:23:27
Speaker
But like people think that the AI is the point, just like they were thinking the data product is the point. so like
00:23:35
Speaker
Again, how do we have these conversations where we have momentum from people that are looking to finance it, but that momentum is is fading fast with the return on investment not coming through, but like how do we think about having those conversations? so If somebody's listening to this, they go, oh, I can take this and and and move forward with that conversation as to still capture that excitement, that momentum, but marry that to that incremental pro you know progress. You talked about agile. like People do agile for the sake of agile, and that's completely incorrect. But if you actually have an agile thought process, it is like trying and testing and delivering value along the way. So like i I don't have a specific question there. I want to tee it up for Yuli if she's got a specific question on this. but like
00:24:29
Speaker
How do we marry all of that together so that we're not doing these point solutions in data when we're thinking about point solution for business value delivery instead of like continuous increase of value delivery and sustainable growth in that over time? Because I i feel like in data, we always talk about the solution instead of the process and the the thinking, the product,
00:24:57
Speaker
Thinking instead of the data product so I don't have a specific question usually if you do but i I'm sure Danilo you want to it's it's me on my BS so I'm sure you want to react as well yeah no I agree and the the way that we like to engage as well with clients is not like Platform up or data product up, right? It's like look across all the data you have. How do we redesign that? Put it into nice domains and then we figure out how we want to use it. It's the other way around, right? It's like because we want to capture the momentum is like, well, someone has a problem that they think could be solved.
00:25:31
Speaker
So we start with that use case to identify how do we what do we need to be able to to meet this use case or to at least either like it might be a slice smaller slice of the use case but we want some end-to-end proof that it will help so that you can invest further to develop for for for the next phase and then we map backwards right like if you know like One of the tools I like to use is is like we do like process mapping. You might use different methodologies, like if it's service design, Blueprint, I guess. If you're in like the end customer world, it might be a value stream map if you try to understand an internal process who gets involved for something.
00:26:13
Speaker
Every business will have some version of like, ah this is how we do stuff and you can map that thing and in a process. And you look at that as the kind of like the canvas to be okay, what are we trying to improve here that maybe data or AI could solve.
00:26:29
Speaker
What kind of people are involved here? What kind of decisions are they making? like Would it help if they make the decision faster or if they make less decisions because we automate some facilities? So we use the process as the as the inspiration, I guess, to carve out like a slice of the use case and then The smaller slice that you carve, then you can map like, OK, for this one, maybe I don't need to build the entire platform. I will need this kind of product. If it's an automated thing, maybe I'll build a model to automate stats. If it's a human making better decisions, it could be a dashboard. Maybe that will pull the right data for that person to use the dashboard at that time.
00:27:08
Speaker
And then if you kind of go back, resolve to train this model, I need this data. So you will need like a, it's kind of like a web of data products, if you will, that needs to be built, but it's not going to be everything for the company. And then we try to build that first. So you at least have something that gives that, that results. And then yeah, you find out if if it's valuable or not to do more or what you, what you vivid.
00:27:29
Speaker
But this is one way to try to avoid that that problem, I think. right like And I agree with you. like It's starting with the product thinking, right because we're looking at the problem space first. And what are we trying to solve? And what are the hypotheses of things that are going to be improved? And then we have to try to build something and quickly disprove it if it's not the right answer.
00:27:50
Speaker
that That's really interesting. and then you are so As far as I understood, whenever the client has a problem business problem, you assess what they have.
00:28:04
Speaker
And you actually try to build scalable data products so they can reuse it ah so that all the down the road, even if the business use case that you're going to try to solve, not going to be, you know, a blast just through the case that you described at the grocery store. So here's the thing. You, but as far as I understood, you look at data products kind of separated from AI and um yeah machine learning models.
00:28:34
Speaker
you cannot feel as as far as what what I understood that the data product still gonna be a data set with a specific logic how it's been generated. ah and And then only after then when you have this, you know, data set with all the data metrics, how they calculated, you're gonna feed it into the models down the road. So I like this.
00:29:04
Speaker
In this case, it actually highlights what you said at Google Cloud Next, that AI been just a flavor to a data product. Yeah. That's kind of what I think, right? Yeah. It fits in the data product ecosystem, but yeah, inside it's an AI model that you're training.
00:29:26
Speaker
But this is also interesting because so if you look at the model or machine learning model, you still need to How do you see like to work on it, to define like in machine learning model, you need to define the weight of features, right? and And someone have to do it. yeah So kind of, you know, put in a few few thoughts into that process as well. Yeah. Isn't it a data product as well? Maybe just different from what you just created.
00:29:59
Speaker
Yeah, exactly. I think it is. It's, like I said, a different flavor. But the team that owns that product will need that specialized skill that maybe it's not the same as the team that builds what I call traditional data product. ah But it's still a product team, just to say. So ah yeah, i i if if the model is worth building, then it's worth
Balancing Data Importance and Product Thinking
00:30:22
Speaker
maintaining as well. Because it's not something that you can just deploy to production and forget about it.
00:30:27
Speaker
even if you do that it could start drifting over time it's no guarantee that it will continue performing for the whole duration of ah its lifetime so in a way like models More than date, because people think data is like, oh, we captured the data, then it's there. Can use any time we want. But I think the models have a little bit more of this, like ah it's easier to grasp there. Like the models needs to be looked after because we kind of expect they will degrade or they need constant care, which should be reflects on like there should be a product team that owns that product that it's responsible for that ongoing maintenance and evolution. Even if it like at some point it gets retired or it gets replaced by something else.
00:31:07
Speaker
Danila, here's your set of questions for me. I'm, again, coming from a product management background, reading all Mardi Kagan books about inspired, empowered,
00:31:22
Speaker
And the third one, I don't remember the name. So when it comes to product thinking and traditional products and organization, organization put so like completely different investments in those kinds of products. They actually supposed to generate the revenue and income to sustain the entire organization, not just, you know, A question about data products and how we think about data products and how some professionals out there start to overthink
00:32:00
Speaker
uh, importance of data, and not like I'm trying to say the data is not important. Hear me out. It's important. But I was, I witnessed the, uh, uh, presentation where the, the person was talking about reading the Marty Kagan book about product management and imply all the frameworks to data products and that showed me off a lot because you cannot put as much time and thoughts into the data set and the end of the day, right? And data modeling as much thoughts the person as a product manager puts into go-to-market
00:32:43
Speaker
ah how to you know how to build it, who to contact, messaging, ah different software limitations just don't get me started. That's like a rabbit hole. okay and And as a product manager, I can tell you, they're not 100% sure every time its if it's actually going to generate some revenue because like they don't have a crystal ball.
00:33:11
Speaker
and expecting something solid from data engineers, pushing them to have this, um it feels like already mythical, product thinking about dataset and their model feels to me just too much. I think we need to normalize having a healthy view on that. My question is, when you talk about data products,
00:33:41
Speaker
How do you coach your clients? like What did you expect from these data products? what like There are different product stages for you guys. like What is a data product for you at Sunworks? Let's point this way. If I can augment it just a little bit or or or sum up a lot of what Yulia is saying, is this concept that I've asked, is is a data product more data or product?
00:34:04
Speaker
Right. at And, and, and Yulia is basically saying, if we try and optimize way too much on the product side, yeah it becomes a problem. But historically we've only done the data side and we haven't done any of the product side. And so like, where is that happy middle middle? How do you find that happy middle? Like, how do you have that conversation? yeah And I think Yulia is that, is that a good summation of where you were kind of going down that path? Oh, I love you. and we Thank you so much.
00:34:29
Speaker
and Yeah, hits I mean, I don't know if I've got the the the perfect answer, but i I get your point that if it's an end user, like some company, the product is what makes revenue for the company. And then, yeah, you do have to apply all of the frameworks and I don't know, it's real.
00:34:49
Speaker
product thinking at the finest. But the the other thing, like because the analogy I think about is we had a similar debate about like platform teams you know versus product teams. Even before data mesh, right like just in like before building technology systems, how do we build platform to support other teams? And ah we we talk about, like yeah, you've got internal customers. But you know it's not the same as your paid customer, because the customer is much further out. so Right. But it is useful to apply product thinking in in that context. Right. like go We've got internal customers that will use our platform. And then the same way, like, yeah, some of the data products is only going to be used internally. So how much do you need? Like, I kind of.
00:35:37
Speaker
I don't like to be like overly prescriptive, of like every product must meet this criteria, this framework and all of those things because then it becomes more methodology for methodologies sake, right? Versus, is it meeting that bad? No. Yeah. So we do have like methodologies, like e but like we're not as as strict to like, oh, you must follow all of these all the time. It's it's kind of like another tool, right? Like oh if it helps you get unstuck here, or it helps you, how do you do your internal customer discovery? It's like, okay, we need to go and talk to people. Here's a way that we can structure the questions maybe that might be useful. But yeah, it's not like you've done this, you've done customer discovery, you've done, you know, all the, I don't know, you know the tick box better than I do, but it's,
00:36:21
Speaker
It's product thinking again, right? Like it's it's treating, it's product thinking around your process. It's again, it's this agile methodology, but I think Yulia, your question was like, what is it reasonable to expect? And Danilo, you kind of talked about that agile aspect of it, of And you know, you can't expect on day one that your data engineers are going to know how to do this because historically they've delivered the project instead of the product. And so, you know, you yeah well obviously i want to give you time to actually ask the question, she but like so much of of what you guys have both said is. This is a learning process and that it is not yesterday. We weren't product thinking today. We are product thinking it's like,
00:37:06
Speaker
how, as an industry, we haven't taught any of these data people. We haven't taught data engineers at all how to think about products, how to think about product thinking, and those two things are different. And like how do we figure out where they are and how do we, again, slap those training wheels on them so they can deliver value? They can go from you know the front of the driveway to the end of the driveway or whatever, the beginning of the block to the end of the block and they're you know They're like, I'm making progress. e we Maybe we don't want to treat them like they're four-year-olds, but the the same idea of like where where are you finding when you go into these places where people actually are and what's helping them move forward because this is the the the problem is we either there's talk in a lot of these talks about starting state or end state.
00:37:59
Speaker
And we never talk about that, but like you you've been talking a lot lot about this, but I think that's where Yulia is asking the question of like, what can we honestly expect somebody to be able to to deliver? Cause they can't deliver a product and they don't know anything about product thinking. So they're a data engineer expecting them to suddenly be yeah for product not, but Yulia, I think you had specific question that you wanted to ask.
00:38:25
Speaker
No, you know I just wanted to share with you, it's more of a reflection and not it's just because um I feel like it's way too much pressure on data people with this product thinking.
00:38:38
Speaker
I'm not sure if all product managers have this product thinking yet, and it's this discipline have been, you know, over 20 years wrong. So I just want to share it this, what I learned from Marti Kagan Bloch's first one inspired is that, you know, you have an idea as a product manager.
00:38:57
Speaker
and But you have to get the buy-in, not only from software team, but from, you know, C-suite marketing, so forth, and, you know, how do you say it? I just forgot. Anyways, okay, you would need to get the buy-in. And there is going to be a community for you, basically.
00:39:14
Speaker
So you take the time you find the slot, you know, you in two weeks from today to get everyone by everyone' paying to present the slides and and so on and so forth. And in 95%, and this is from the book, you're not going to get the buy-in. You're not, because people are rejecting new ideas, but they're in nature.
00:39:38
Speaker
That's it. This is how
Challenges in Data Initiatives and Product Thinking Adoption
00:39:39
Speaker
their brain works. There is something new. There is something required from them. There is a block. That's it. you it's It's literally treated as an attack. You know, the same level of hormones, whatever. So what you need to do, and this is again from the book, you want to meet those people at the water cooler.
00:40:01
Speaker
a and pitch them the idea and get their feedback and then message them and then iterate on your slide deck. And then your chances to get the buy-in from your ah slides in two weeks is about 50%. And this is the entire product management board, like to get the buy-in. And this person, you know, who's presenting these slides is% sure when it's gonna work.
00:40:31
Speaker
but This is like, you cannot be sharing in something new. You can't take it as live. You don't know. And the same is for data. And when they, you know, these messages out there on voting, data engineers need to have product thinking. So what? They will question every, every week data model they're building in and their are data warehouse.
00:40:52
Speaker
And the question then, their existence and their work in the company of what? Like, just please, you know, people chill. It's okay to make mistakes, data models, and then to generate some data set. They're not going to create some, you know, substantial output. You can still kill it. And it's relatively non-expensive for the organization. Let people test.
00:41:16
Speaker
You know, because I think this much pressure is part of thinking stops data engineers from testing and innovating. That is yeah literally product thinking. But that that literally is what what product thinking is supposed to be versus how it's presented to data people. And and I think you're right. It is our framing of product thinking is a again, yes you must do data products instead of that. So now di when you're going into these organizations that are more in that not super, super leading edge. you know i mean I know you guys work with like a Zalando or somebody like that that is developing some really amazing things, but that you have these these ones that are more kind of mainstream organizations that aren't necessarily ready to jump immediately in.
00:42:02
Speaker
You talked about that change management. You talked about that agile methodology and that agile, like not agile, capital A, but agile methodology that you know you can base off of agile with a capital A, but that you're just kind of... So like how do you have those conversations to not make... yeah This was one of the things that I failed a lot with with Data Mesh when I was working on that stuff around it was it was a big, big, scary thing instead of like, Hey, like the whole point of this is to give you space to do your data work and do it in an interesting way, but you have to understand the why, but that doesn't mean you have to question why every single time and you have to have every single answer and you have to, so like, how do you have that conversation and how do you have that conversation with the data leader?
00:42:54
Speaker
to to give their people the space. So those people don't just go, I added the data to do data work and now you're telling me I have to do nothing but product work. So I'm going to bounce. I'm going to go find another organization to do this. Yeah. I mean, this is part of, I'm going to be super biased on my answer because this is how we tend to engage as a as a company. But what when when we talk about like The word is ah enablement right enabling the client. ah For the longest time, like we we'd never ever believed, even when we're doing agile for software before data mesh, right that we didn't sell training services too much, for instance, because training, you you acquire some skills, but you need to practice to actually become versed on that.
00:43:37
Speaker
So for us, like it's always big, like the way we do it day by day is always co-sourced, right? So we would work with the client team. We'll kind of demonstrate the behavior by working together with people. So like they will they will be working with us for three, six months, one year, a few years. that Then they start getting a little bit of like, what is this this way of tackling problems? What does it need for us to do the data product?
00:44:02
Speaker
Uh, and then the way that we scale that it's okay. Now, if we've, we've got people in, in the client that has experienced that by themselves, they will become those, the next layer of champions for, you know, so like when we spin up another team, when we go engage with another domain, this is how we kind of try to.
00:44:20
Speaker
broaden the scope of the enablement we'll we'll talk about like split and seed right so like we've got core team we build the first iteration together we put the MVP production then we we kind of establish ways of working and then the next phase we split the team will be some people from the client maybe some of our folks to seed the next team where we'll bring some new folks from the client into work But now it's not just us, it's us plus some people from the client that learned from that first space. And then you kind of start splitting and sitting to a point where like usually like we that's why we don't get engaged for multiple, multiple years with clients. like At some point, we we phase out as ThoughtWorks and then hopefully the client learned enough to to keep going on their own. like that's ah Unfortunately, it's the long way to do it. right like There's no quick answer. You just buy something and put it in production and then it's
00:45:11
Speaker
everybody's enabled, but it's part of that human aspect of taking people along the journey and having to understand what it means. like You do the practice by trying to work through a problem with them instead of just dropping the methodology and saying, follow this. It's it's proper parenting.
00:45:27
Speaker
but if that is It is. you know you You've talked about this with your kids, like where you're like, hey, I give them the freedom in a lot of ways, but I show them what is the good way, and then we do it together. Melissa Logan, who ah runs the the data mesh learning community stuff now. um We were talking about this and it was like you, you so you know, you see one, you kind of co-do one and then you lead one yourself. And it's just like, okay. Like, you know, you get walked through how it's done. Then you, you kind of do it together and then you're ready and you're still going to make mistakes. But like right
Improving Data Professionals' Understanding and Curiosity
00:46:05
Speaker
that whole thing. And then, and.
00:46:07
Speaker
how do you, yeah I mean, ah there's this view of data outside of the data world of one or a zero, either what you did was correct or what you did was not correct versus the degrees of of fit and the degrees of of how well you did it. So like, how do you get organizations that are in this old school mindset of you're supposed to tell me an answer and it is supposed to be correct or it is incorrect,
00:46:35
Speaker
and and give them that space to actually learn and get better and iterate and and that you know you can have a conversation of, this isn't ready. yeah I was talking with um ah car Charles Kubaczak from Springer Nature for Datamash Radio. At some point I'm gonna put out the episode and anybody out there. but um And we were talking about Band-Aid data and like they very specifically say,
00:47:05
Speaker
this is temporary. If you put this into production, that's on you. That's not on me. You can't come back and be frustrated when I told you, you can't use this. This gets you 80% of an answer and we've got a confidence interval of 80%, not 95%, not 99, but like how How are you seeing those conversations evolve? Because again,
00:47:31
Speaker
somebody that like ah a C-suite exec that is not um that understanding of data, again, has that one or a zero mindset. That's a very good point, actually, because it's almost the next sphere of influence. So like we were thought what I was talking about enabling is like the teams that are working to build the data products and to maintain it. So they have a level of learning. But now you're talking about people using their data. Maybe it's the business users. like they They need to be trained as well, because you're right. like They might expect to be right or wrong, but then there's no such thing.
00:48:06
Speaker
my My experience with helping with that is actually the data mesh idea of being domain centric is really useful there because what we're trying to do is get the data folks to understand more of the business to the point where we're going to start asking questions. And for instance, I've been on a project where like the business person told me what they thought the process was for like this is the payment process and these are the steps and like people.
00:48:31
Speaker
people click here they drop here i'm like okay so then i go look at the data and i try to model that and then i like i find like i don't know 30 instances where it didn't work the way that they thought so but now it's data-backed evidence for like but i i go it's kind of like uh i think i don't understand very well where you explain but like i found this 30 kind of odd cases that didn't fit what i thought you'd describe to me like did we miss something and i you'll be surprised how many times they're like oh but this shouldn't happen this this is wrong or like Oh, like a lot of time. Yeah. It's like, but it's like, well, the data is saying that. So either like we captured the data role or the process that you think it's one way is actually not that way. And like sometimes it's aha moment for them. It'd be like, Oh, I didn't know like this is all the flow was possible or.
00:49:16
Speaker
Sometimes it's a real bug actually. Like our followers are like, oh, we're instrumenting the event wrong. It is like we're putting the wrong tags on it. Then of course the data will be prepped about that. So it could turn into like, yeah, the understanding was right, but the data was badly captured. But many times it's like the understanding was wrong, even from the business person, because it's too complex. Like they they might not fully fit all the variants in their head about what happens with with the real data.
00:49:40
Speaker
Yeah, Yulia, you talked about that you were you were talking to somebody and they had they were, you know, somebody was really happy that they had optimized the cost on this thing. And it was like, but we migrated away from using that. So like, great that you cut the cost that we were wasting on this. So it was zeroing as much money, but it should be zero because we weren't using that process anymore. Or, oh, no, that process is noncompliant. Like, you know, it's And I think that that's where the the the data people, again, I have this problem where there are data people who are like, I got into data to do data work and not to talk to people. yeah
00:50:21
Speaker
and but If they're like, you got into data work and now all you get to do is talk to people, they're not satisfied. So like finding that balance and slowly moving somebody in and giving them rewarding experiences where it's not just like, you now have to go and talk to the person that that created the ticket and they're frustrated. So now you get to do that. It's the other opposite of like, you get to go and you get to make that person, you get to make the company way better through what you're doing.
00:50:53
Speaker
And if all you want to do is build your models, like there are opportunities for that, but like it's not here. And then people get you know freaked out because they're like, well, then we can't hire anybody. It's like, well, if you're not looking for the right people or if you're not trying to attract the right people, you're trying to attract those ones that have exactly all the skills instead of treating people a little bit like a product that grows.
00:51:18
Speaker
that you invest in, that you figure out that you take them in the right direction, but that have the right mindset and the right kind of approach. It's, I don't know, it's again, one of these things where I try, Yulia and I try and talk about like concrete next steps. And then we really struggle because so much of it is, what's your situation? Like what's the, what's defended? Like what each, trying to treat each data engineer as if they're all the same exact thing,
00:51:45
Speaker
Yeah, fails as well. Yeah, this this is actually like it's making me have an insight going back to the beginning of our conversation about like you said your interactions with the workers and how what we do to hire our people.
Historical Barriers and Vendor Influence in Data Practices
00:51:57
Speaker
But what one thing we hear a lot is that ah people like to ask why a lot. So like, you know, like even when we're high, it's like just build something. It's almost like in age to thought workers that we're going to say, but why? Why do you want to build this? Like if if I don't have to build it, that's better, right?
00:52:12
Speaker
So we we don't go with the mindset of like, oh, you hire me to build something, I have to build something. ah So there's something around that, I think, like, you know, like good data people, good, good data scientists, they have to be curious, right? Because you, you want to, as you learn more about the problem, or as you learn more about looking at the data, or the model they try to build,
00:52:32
Speaker
you should be getting new questions. right It shouldn't be just like a stream of like oh someone is telling me to build this model or somebody is telling me to move data from A to B. like it's just kind of like If that's the mindset, then that's the skill that might be missing. is like Maybe you should be more curious about like why why am I being asked to do this? Do I have to do this? you know Don't show just state the orders. Shift the curiosity from the data to the problem.
00:52:56
Speaker
Yeah, it's like a little relation. No, no, no, no, listen. So, you know, the problem I think we uncovered is basically majority of data people are in curious, there is word like this.
00:53:11
Speaker
yeah and I think about but i think about that the the business problems, and i and I don't think they are incurious. it's i think that they've been and and Sorry to cut you off because I want i want to i want to hear what you're saying, but i I'm going to step in and defend data people. It's not that they're not curious, it's that they haven't been given the pathway to actually be curious about the data problems because they've been given the tickets and they've been told close the tickets and that the yeah thing they they should be curious about is the data. And so it's not even that they aren't curious about the business problems. It's that they have been so separated that
00:53:48
Speaker
trying to be curious about it, then all of a sudden somebody goes, oh, okay, I'm going to dump all this information on you and you don't know what the hell I'm talking about. So that pathway to bringing them in and and leveraging that curiosity, because data people tend to be extremely curious, but we have to move them from being curious only about the data to being curious about the business problem to tackle that via the data.
00:54:13
Speaker
So my question was not to blame them being all curious. Like this wasn't my point. i'm i'm I'm trying to reflect where we are today. They are trying to be curious about the business saying, okay, I'm sure doing my stuff, you know, enjoy tickets. And I'm trying to take a step back and understand what's wrong with the industry with businesses was before. So we pushed, you know, data people in a position where majority of them I'm in a state saying, I'm doing these models. I'm interested in building. So i'm i'm I'm trying to understand at what point things go went sideways.
00:54:54
Speaker
Because this is industry-wise. This is not happening in waters. And again, I'm so much agree with you about the point that data people are curious by nature.
00:55:06
Speaker
That's true. Those people are very interesting. They are very meticulous. This is just,
00:55:15
Speaker
my my headphones are, you know, going mental, but yeah, so they're very meticulous, you know, and they can bring so much value, but what happened in the industry? So we got into the state where they are like, okay, I'm doing the jury tickets.
00:55:32
Speaker
This is an interesting rhetorical question. I have a hypothesis, but I cannot prove it. But I think and this is why I've been a big fan of data management, actually, because it tackles that problem. But historically, like we've been trying, there's way more problems to be solved than people in time for the central data team to do everything. So my hypothesis, maybe like because there's so much work, like it's easy to get bogged down by like, oh, we have to close the decades or you have to you don finish all the like ratios and stuff like that. And we never had enough and of slack in the system, if you will, to try to think more about the business problem. That could be one reason. did Data being under IT t is kind of what you're talking there is is that they've they've been this ticket taker mentality. and And I think there's also something I've talked about, which is the the informational poison well, which is so much of the information flow about how to do data well comes from vendors.
00:56:31
Speaker
and comes from vendors and their product marketing departments, not like somebody like Yulia, who is just curious and wants to ask these questions, but that they're, it's like the way to solve, if you have this problem, the way to solve it is by buying our stuff. And that's a very US centric approach versus, you know, you two are are both in Europe, Yulia, you deal kind of a lot with both sides of the pond. No, I think you do too, but I think a lot of your stuff is is still Europe.
00:57:00
Speaker
and Europe is more problem centric. So it's not nearly as bad as the US, s but the trends and the famous you know people and stuff like that tend to come from the US and you make your name in data.
00:57:14
Speaker
by solving the data problems, not by solving the business problems, but you make your career by solving the business problems, unless you were one of the 10% or the 5% that is so good at solving the data problems that people can come to you and just be like,
00:57:32
Speaker
I have this data problem and I have framed it in such a way that I have such a massive issue on the data side that matters far more than the the business side and somebody's already solved the way that this gets solved from the data side. I just need you to to build a you know, thousand node Cassandra cluster or to build, you know, I think about, uh, the, did the data mesh project at Netflix, which was literally just called data mesh. And it was not, you know, something different, but, um, it's just this massive scale Flink processing platform.
00:58:06
Speaker
And it's like, you don't have those problems in 90% of the companies. But those are the interesting things. And those are the things that that people talk about. And we can't always talk about the business problems, because that's always internal stuff. So so maybe maybe it is like even pushing people to get go into internal guilds and things like that, and have those. Or
Conclusion and Future Anticipations
00:58:26
Speaker
we pushing companies to stop being so, you can't talk about our business aspect of stuff with data. and it's like why like Okay, you think this is such a competitive advantage? If it is, now you should be advancing your lead constantly. so Just talking about what were some of the high-level aspects of this, you really think somebody's going to be able to copy you in six months, then you didn't do it right. You're not doing it right as an organization. you know i I'm being judgy, but that's that's these are the conversations especially that gets sparked when I talk to thought workers because it is
00:59:03
Speaker
Like how do we do the practice of data better and how do we stop treating it as if it is its own wholly separate practice instead of integrating everything we do into the the the business.
00:59:21
Speaker
if the business will have us because a lot of times like the other aspect of business people that I talk to are like the business won't talk to the data people because they don't want to deal with the data. They want to send a ticket and that's the only thing they want to do. so Again, I'm not off on money one of my rants. but So, yes, let's wrap it up with a fabulous friend of Scott. Daniella, thank you so much for stopping by. I feel like the conversation isn't finished, but I am expecting far more interesting sort of conference in Amsterdam. You go in. Oh, yeah. I had the World Service AI. Yes.
01:00:02
Speaker
Okay, let's catch up afterwards and thank you so much for stopping by. And yeah, that was a blast. Thank you all. Thank you.