Episode 9: How To Build Data Assembly Lines to Crank Out Value

Chris: When you’re leading a data and analytics team, you can blame yourself or blame your customers for fix it.

Intro: Welcome to InConfidence, the podcast for data ops leaders. In each episode, we ask thought leaders and futurists to break down the topics and trends concerning it and data professionals today, and to give us their take on what the data landscape will look like tomorrow. Let’s join the data conversation.

Nick: I’m Nick Curcuru and this is the InConfidence podcast sponsored by privitar InConfidence is a community of data practitioners that encourages conversations that will enlighten educate and inform data leaders of today and tomorrow, thank you for taking the time to let InConfidence be a part of your day. Today. Joining our community is Chris Burke. Chris is the CEO of data kitchen. Or as he likes to call himself the head chef. As you can already tell he comes at data operations. From a unique perspective, thinking differently has always been a part of Chris’s makeup. He has been doing this since his days in the Peace Corps Teaching Math to Young Minds, he found different ways to connect with his charges then. And now he does it with his clients today, Chris will share with us why he thinks data is an ingredient and how he works building data center lines cranking out value, Chris, welcome to the InConfidence community.

Chris: Nick, I’m really happy to be here. Thanks for that great introduction. And thanks for having me.

Nick: Our pleasure, Chris, I love that you call yourself a chef. And you take this uncommon approach to data primary in the world of being a chef, and assembly line and data operations. Can you tell us what inspired you to make these connections?

Chris: I like food, you know, that’s a good thing. And, you know, when you start to create a company, you’ve got to create a name. And one of the first things I just didn’t like boring names, you know, boring tech names. And I didn’t want to be just another Middle Aged data nerd, you know, middle aged white data nerd at a conference. And so to me, I think one of the challenges that data is a team sport, but it’s also a creative team sport. And so there’s a place where people have to do both. And if you actually think of a good restaurant in their kitchen, right, they have to consistently put meals out, week in and week out that are on their menu, given the variation on all the ingredients they have or the tools they have. But they also if they’re gonna stay in business, they’ve got to create new recipes and new meals, right, they’ve got to adjust to give it on what people want. And so there’s this built in tension between kind of doing the same thing over and over and over again with perfection, and then innovating and changing. And that’s very similar to the world of data and analytic teams today. We are constantly challenged with poor data, crappy inputs, broken servers, and and then we’re also challenged with customers who have 50 follow up questions. And so how do you live in that world, right, where it’s go fast, but not break things. And the experience of our forebears and people who’ve done work in manufacturing, like that Toyota Production System, and Deming, software engineering and agile and DevOps, I think, come to play. And I think those management concepts are what we’ve tried to bring, and technical concepts are trying to break what we tried to bring into the idea of data ops.

Nick: Well, I think it’s interesting that when you talk about this, the reason you started to do some of this work is coming to come from from your past. I mean, as you got out of the Peace Corps, and you moved into basically being a coder, there are a few things that actually got you a little bit, you know, I want to say upset, right? Or you saw things going in ways that should not have been going, can you share with us how you started to think about this assembly line, these that, that what you described as data is not just an ingredient, but a way to innovate through a kitchen. So provide just a little bit of background and how you got here.

Chris: So, you know, I went to the Peace Corps, I went to graduate school, and I studied AI back when my machine learning class had five people. And now it’s one of the most popular courses on any college campus. And so,

Chris: and I went to work in AI, sort of an air traffic control automation in the 90s. And then I wrote a lot of code, I joined some internet startups, one guy got bought by Microsoft, I started to kind of manage people and then about 2005. I thought, Man, I’m a really, I’m a big software stud, I’m gonna go to this data analytics thing. I’ll be home by five, it’ll be easy. And you know, my kids were small, no, no worries. And I joined a company that did analytics for healthcare. So I had what we now called data engineers and data scientists and people did viz and we had, we’re trying to build a software product too. But like, my life really sucked. Not because of the software product just because the stuff that we all face, right? Hundreds of data suppliers, they forget you exist, columns get dropped, data gets changed. They’re late, and a lot of people who are who I worked who worked from. He who really were well intentioned, but had weren’t working in that inner right system. And so one of the most important things happened to me on my 42nd birthday early in this company, I was, there was a guy who worked for me who was smart, a data engineer, and it was his 24th birthday on the same day as my 42nd birthday. And, you know, he was in a one on one of my office, and he started to cry, he was like, so upset, because stuff, you just couldn’t be successful. Like, he just could not the customers and my boss, which is asking him to do a lot, and you couldn’t get it done. And meanwhile, all the data providers and the servers were having issues and so his life was just hell. And he was upset about it. And like, what I started to realize is like, you know, the fault is not in him, the fault is in the system that he works in. And I got that idea pure out of Deming, right, and that it’s, you know, 94% of the time and a factory. It’s a process cause not a special cause, not a person cause. And as a leader, I took that to heart. 

Nick: So, you know, I think that’s interesting, because we always talk about any Maturity Model, or when we talk about technology or analysts, people process technology. Everyone just always goes to technology, where you started to think about it as the process the system itself, not necessarily the people, not necessarily the technology, but the system. And where’s the system failing? I mean, that’s a that’s an interesting way to look at it, because so many people just gloss over the process or the system itself. And that that does I mean, that’s pretty, that was groundbreaking. You know, 10, I want to say five years ago, because you don’t look at the over 47, by the way.

Chris: So yeah I’m 58 so I’m older.

Nick: But as you think about it, that’s, you know, that we said that’s your defining moment, you’re like, it’s the system is this ability to take Toyota’s assembly line, and create this system, where we can continuously improve, obviously, Deming, and then all of a sudden, you started to think about it as the restaurant. So that was literally 16 years ago, that you started. 

Chris: Yeah, and you know, I think it’s, so you face a choice, right? When you’re leading a data analytic team, you can blame yourself or blame your customers, or fix it. Right. And so to me, it felt wrong to, you know, I did do a lot of blaming myself, which wasn’t great. And I think, you know, we did a survey with another company recently, and found that 80% of data engineers want their job to come with a therapist, because they’re so stressed out 600 data engineer survey, which is insane. So obviously, that’s still around. So you can blame yourself, or you can blame your customer, and put up a bunch of walls saying, I’m gonna get my work stops here. And beyond that, I don’t care. And that’s okay. But like, I’m always been, like, I’ve been really focused on delivering value and having an effect, and like, putting an arbitrary wall between me and the stuff my team creates, and the customer just felt lame. And so that’s left with I’ve got to work on the system, right? I’ve got to, you know, I can’t sit in agonize, I’ve got to automate. You know, I can’t. And so I got tired of suffering and said, Look, I can build a system that can alleviate my team suffering. And that means thinking about what you do as a factory. That means thinking about stealing ideas from software, and automated testing, and automation and infrastructure as code. And so as we went through this journey, we had to build a bunch of stuff ourselves. And then when we started the company a years ago, those ideas were so burned into our soul, that, like we knew, and we knew that, that we couldn’t do anything else. And we also learned in engaging with early customers that there was an added complexity in larger organizations of the fact that it’s not just one team who does data and analytics, there’s centralized teams, and decentralized teams and hub and spoke and data science teams. And the organizational complexity of data and analytics is, it’s also a problem. So how do you go fast, not break things and not spend your life in meetings.

Nick: Well there ya go. But the other part that I like is, you know, you talk about service orientation and customer focus, and people talk to that. But what I like is, in our last conversation, you talked about that customer focus is not just the person who’s going to consume the data, but it’s also as a leader, a data operations leader or a data analytics leader, your customers, also the people that you are leading, you are managing, which goes to that 24 year old who’s in your office as as a how do you make that customer have a better life and really, let them understand that they’re making a difference? Right. So I think that’s the other part that I took away from our conversation is customers aren’t always that end person. It’s also those people that surround you to your right and to your left. 

Chris: Yeah, cuz I think that sort of focusing on your customer and making them six SAS is really important, but also and that could, you know, I think of that as value delivery, but also think of leadership in itself as a service, right, and you’re trying to be of service to people. And so in that way, as a data engineer, who are you in service of, a lot of times, you’re in service of the business analysts who’s using your data, or the data scientist who’s using it, they’re your customer, and you want them to make successful where they may, the business analyst may actually be talking to a VP of marketing or a VP of manufacturing, right. And, and so there’s these links of value chains that go on in our data and analytics world between who’s our customer, and everyone’s trying to have the same goal, they want the VP of manufacturing to like, listen to the data and not follow his his or her gut. Right, we want to make data driven decisions. And so, but to do that being of service, focusing on who your customer is making them successful in delivering value to them, those are, they can sound like trite words, but they’re often hard to do. And organizations because the incentives aren’t aligned, the incentives are oftentimes on, I just want to put my blinders on and focus on my own backyard, I’ll My job is to do a data transformation, my job is to make a nice visualization. And everything else is like, I don’t know, you know, and so I think the those sort of blinders that we put on to get our job done take away from the our best intentions and being customer successful and value driven and service driven. And I think, really, that’s a management issue, because management hasn’t given people a by a system at which they can see how they can, how their world can impact the bigger one. And what’s replaced with it is a bunch of meetings and paper documents that are often out of date and unused. 

Nick: But I think the other part of that is, again, not to have a meeting to have a meeting, but when I’ve talked to some of your people, you know, they’re they sat back and say, because I understand my customer, because I understand their perspective. And And to your point, they’ve said they use the word blinders. So it’s resonating through your organization, I need to look downstream. And they were like, What are you guys talking about downstream? And they’re like, Well, you know, I want you to talk about this is you, I guess, have this tremendous metaphor where you’re like, it’s not building a house, it’s something that you say, and you’ve got to it’s like a river, you know, trying to anticipate things. So a little bit about that, as you as you get this, take those blinders off and start to see to the right and to the left again. And for you know, what is happening? So a little bit, can you talk about that analogy about going downstream? 

Chris: Yeah, cuz I think one of the aspects of having blinders is like, I just want to like build a house and walk away. And analytics is house building. And like, I’m gonna build a house, and maybe I’ll have a punch list. But what really is, is analytics is there’s always follow up questions. It’s a river of unanswered of unanswered questions, because there’s always new datasets, always new questions. And so in that way, it’s much less like a housing project, it’s more sort of navigating rapids, that go on forever. Because you know, you do really good work, and you get 10 follow up questions from your business customer, you shouldn’t be upset about that you should be honored, right, that’s an opportunity to shine. But I’ve seen too many companies where they’re really good teams bummed out, because they got 10 follow up questions, because they know it’s gonna take them forever, and the customer is not going to be happy. And that’s just not, that’s not what we want. And so I think, if you look at analytics as a river of questions, and that’s really going to help you get the perspective that I need to work on the system that I need to work on my team and my processes, as opposed to just like being a hero, you know, because the other part, the emotional part is we’re often caught between sort of, you know, fear and heroism, and like fear, I don’t want to make a change, I got it working, it’s gonna break. And then heroism, I’m gonna jump in a lesson, and I’m gonna work nights and weekends. And honestly, you need to be a hero a couple percent of the time, and you need to have a need to be cheerful a couple of percent of the time, but the majority of time, you should be able to deliver consistent innovation with consistently high quality. 

Nick: Well, I think that goes to your assembly line approach that you’re talking about. And if I can if we could take that approach, and I’d like to ask you, you know, is there a client that it stood out in your mind where you took this data ingredient, this is somewhere on this post this, this constant challenges of going down the rapids, and it all came together? Is there a, you know, good case study you might be able to share with us where all these different things come together? 

Chris: Yeah, yeah. And we worked with Celgene. It’s now part of Bristol Myers Squibb. And they had a new product seven, six or seven years ago called Otezla. And it was a really great pharmaceutical product. And, you know, in the US, whether you sort of follow Bernie Sanders or not, there’s sort of pharmaceutical marketing and sales and like in any marketing and sales function, the launch of something new is incredibly important. And in pharma. It’s actually really important because you spend $3 billion developing a product and then the sort of curve of the sales have in your patent window really determines the success and determines. And Otezla actually amazingly got to be over a billion dollar brand, which is sort of a one in 1000 chance in the pharma world. And the way the there’s a whole lot of data that goes on anonymized patient data, opt in Physician Data, marketing, data, sales data, cost data of stalking data. And it’s really complicated because American Healthcare is just a complicated mess between payers and providers and insurers and drugs and pharmacies and like to try and take it all that right, there’s, you know, you have hundreds of people and hundreds of millions of dollars of spend. And so you need to be able to give the people who are going to make decisions, fast insight that they can trust, and be able to ask a lot of follow up questions, and be able to move down that river rapidly and do that in a way, like a lot of organizations, when they plan in a billion dollar launch, they get a data analytics team of 100 people, right, it’s a lot. We did it with both of the sort of the data people were to, and the analytics people were three, right. And they were able to produce insight for several 100 sales reps for the entire marketing and sales team. And yeah, there were some call consultants brought in now. And then so maybe the team was, on the average about eight or 10. But that’s 10% of 100. person team. 

Nick: Yes. So let me let me get this straight. So what it usually takes 100, maybe 120 people I’m going to add on, you know, you’ve got down to with this assembly line approach, this focused approach, you get down to a dozen or less certain points. 

Chris: Yeah, because you’ve spent time you’ve spent time building the system. So you’re not repeating the same thing over again, a lot of times, data and analytic teams are chasing down data errors, and they’re digging in and they’re, they get something working, and then they can’t change it, because they’re just keeping it alive. And like it’s so much work. And they’re like one armed paper hanger showing like I don’t working on patching this and patching this, and they don’t take the time from the beginning to work on the assembly line, build a good factory, right, and then focus on how focus on these factory automation methods. And it’s the same idea about why Toyota built killed American Motors in the 80s. Toyota worked on the factory, American Motors worked on like jeans, interiors, and trying to put robots in their in their things. And like, at the time, none of those worked, right? Yes,

Chris: cars that lasted longer, and they were cheaper. And you know what, they evolved them quicker. And so like, by focusing on your factory, you actually end up getting a better result from the factory. And so don’t like try the bling and jeans, you know, the jeans, Pacer, or buying some robots that will help you well, in 1982, you know, it didn’t work. 

Nick: So well working on it, but Dazzle, let’s get away from them. Let’s get down to the brass tacks.

Chris: Maybe having the jeans in your current theory is a good idea. But I don’t know.

Nick: Let’s get back to the Pharma. So you’ve got a dozen people working across probably hundreds of data sources. As I’ve worked for this building this assembly line, how did you build with those dozen folks? I mean, again, you’ve got an organization, they’re used to hundreds of people working on this, you’re saying you’re coming in with just a handful of people to be able to accomplish this. And then you’re you’ve got to build the trust that what you’re about to produce that used to take hundreds, now we’re into the handfuls is trusted, how did you begin to sell them on this assembly line approach to building that system building that factory to build that trust? 

Chris: Well, fortunately, we didn’t have to, we said, look, we can we can we kept eating more tasks and replacing consultants and internal people because we just delivered faster with low errors. And so the evidence was there. And so what happened is they, you know, the team who did it could, every time they implemented something, they wrapped it in automation, right in version control, and deployment automation. Everything that was built was wrapped in testing. And those tests ran that tell you if in production, that data’s provider screwed you over and also in development to tell you if my change in one piece affected another. And so by building along with the work that you’re doing, because it was primarily a cloud based sort of it was an ELT project with some Alteryx and some Tableau, some machine learning models built into Python, like it wasn’t, you know, it was good, modern tech stack, right. But it was, the data itself wasn’t entirely huge. It was sort of like 10s of terabytes in total, but by building the automation, the testing the deployment, the version control at the same time, and then anytime you had an inkling of a problem you you’d say am I going to do something new, or am I going to work on my factory work on my automation, my testing, and then we were able to go through and say, Okay, we’re gonna build some more automation, you know, we had a hiccup last week or this is what we end you get trust with your customer, because you’re constantly delivering that they say they trust you and say, You know what, that can wait a week? Why don’t you go ahead and add some more tasks and make this easier. And that relationship between working on the factory and working on the car is what really matters. And a lot of organizations, all we do is run around kind of making cars, and we short shift the whole the whole factory and the processes and building things. And all I’m saying is like, if you automate, you’re going to have a better result. And, and that’s, I, I’ve just seen that now for 15 years. And it happened in the software industry, too. You know, I think I’ve been in the software industry, we were stuck in heroism and pure mode for years and sort of these ideas of agile, which basically, and DevOps, which basically came from another came from manufacturing, made a big change. And now, I think it’s pretty commonplace to run a DevOps organization where people, you have 25%, of your team devoted to automation and testing and working on the factory. And so all I’m saying is, in data analytics, he got 2%, maybe make it 5%, maybe 10%, you’re gonna see great results.

Nick: Well, what I like is, as you’ve worked through the system, you’re freeing people up to do more valuable work, which is part of that we’ve, you’ve made it repeatable, you’ve turned around and said, Okay, let’s free up from, you know, we always say is the 80% of the same thing, the data wrangling or whatever. If we automate it, now you get chances and think about new things, how to innovate, how to get better, have more challenges, more problems, I guess, thinking about problems downstream, or the challenges so that you can face them faster? And better. So I think that’s important as well.

Chris: Yeah. And I think the role the role of a, of an ops engineer, a data ops engineer, is to work with someone who works with whatever tool maybe they work with a self service Data Prep tool, or maybe they’re a data scientist writing and are, maybe they’re a data engineer who happens to be working in Informatica, or maybe they’re a person who does on Tableau, all those people, they’re working in data and creating little nuggets of insight. And those nuggets are expressed as XML files, or R files or SQL code, write that stuff. And that’s really their work. And so how do you, what they want to do is improve that little nugget of insight. But taking those nuggets and putting them in a factory is and helping those deployment and testing and version control and automation. That’s the role of a data ops engineer. And maybe functionally, it’s could be part time other people who do other roles, but that that’s and it’s very similar to software engineering, you build some software, well, the software engineer runs code, but like, you’ve got people doing CI and CD, you’ve got people doing infrastructures code, you’ve got people doing testing and monitoring same roles, they call them DevOps. But I think that’s by investing at what you really do is you free up those, we internally call them nugget writers, data scientists, data engineers, to do their to create their nuggets, because that’s what they want to do, right? Because they want to be freed up to innovate. And they just want to say, hey, look, I created a new model, can I get it into production? And did I break anything else, you know, and even like, like just super simple cases, take forever, in some companies, like, I want to insert a new table into my database and do a join against another kind of table that can take six months in some companies, because you’ve got the testing and deployment and meet, it’s all manual. And if you think about it, a new table, a new joined, maybe it’s a new report, maybe it’s tweaked to the model, you’ve also got governance and security and privacy. There’s a lot of things to sort of professionally put a table into an existing analytic system. And then you end up with these piles of paperwork. And it’s like insane, you actually look at the real code that it does. It’s like, maybe it’s all in all. It’s like 100 lines of code. But the documentation meaning is 10,000 times that. And I’m saying take that code, but also put a bunch of tests and automation around it. And then the amount of documentation and meetings goes down that you do it right. I’m not saying you don’t need documentation, but like, you wrap your code and you wrap your nuggets into good automation, then everything else gets better. 

Nick: But I think what’s interesting, it’s not just the automation that becomes repeatable, right? And that that tribal knowledge that went into all that actually sits in the system. And I think that’s part of our other conversation that we’ve had is, is how many times have unfortunately, maybe a good software engineer or a good did ops person leaves the company, that tribal knowledge goes with them. And now you’re stuck it. I’m going to read, as you said, it’s the system. I’m going to just start my own system because I didn’t understand his system before me

Chris: Yeah, yeah. And like, sometimes the smartest people can do so much, right? They can go off. And they can get data, integrate data, visualize data, do science on it. They’re amazing, right? They’re full stack people. But they end up creating these sort of complicated hairballs. And like, in my last company, we had one guy was really good. He liked to use, he liked to use this arcane language that no one else knew. And he was super productive in it. And like, you know, what happens is if you leave, then no one else knows what you how you to do it, and like, you depend on it, it’s in production. And then honestly, if you build something, then you have it in production. And so the people who create these high complexity, hairballs, in my mind, add value to the customer, they’re fantastic. But they often get bored because they have to run what they build. And they’re really they’re interested in innovating. And so I’ve done that in my own career, I’ve created high complexity, hairballs, because I wanted to be a hero and get all the accolades. And then I create a mess for a bunch of other people. And like, it’s, it’s fun ish. Like, as you’re young, it’s fun, it boosts your ego, but like, you get a little older, and you start to manage people, you’re like, oh, man, they left, and now my whole team is screwed. And we decompose what they do, and everything slows down. And then it’s, it’s hard. And that’s why your average CTO tenure is see Chief Data Officers two and a half years, while we have a report of, of people wanting new jobs that have come with a therapist, because they’re, you know, we’re not giving the proper, we’re not giving the amount of effort to improve the system that people work in, that’s needed. And that’s sort of my mission is like, put some effort into it, and you’re gonna see, you’re gonna end actually end up doing more doing more and having more value to your business. That’s the secret here is it seems like it’s additive. But it actually subtracts a whole bunch of nonsense work. And you’re going to end up actually delivering more value to your customers. 

Nick: But I think that’s interesting part is simplify the process, and you get to actually do more and create more value. And you know what? I think that’s it goes with Danny kitchen, simple ingredients, make some of the finest food that we ever eat, right? 

Chris: Yeah. 

Nick: And that’s an important thing for most people to realize is simple, simple, simple, make it easy, right. And I think that’s one of the things I’ve learned in our conversations, is looking at that system is just as important as the technology is going to be or as more as more important, I’m sorry, don’t don’t get mad, don’t get that Chris, looking at the system is more important than looking at the technology that’s a part of the system. 

Chris: Well, you know, I don’t want to step on anyone’s importance parade, right. And so a lot of people, you know, what I’ve learned, and what I’ve seen in software is that in 1998 99, I had a release engineer work for me in software. So one guy, he took our software, and we had a sort of a SAS hosting. And we had almost 35 engineers working on it. So it’s a ratio of one to 35. And he was paid less than everyone. And he played the mandolin at parties, he was fun, felt like we all thought, you know, release, were thrown over the wall him and he could deal with it. And you play that forward. Now, most, the last statistic I read is 28% of the teams on good software are involved in DevOps automation, and they’re not writing the product. They’re writing the systems and factories and automation and tooling around it. They’re doing CI CD and monitoring, testing, it’s a huge multibillion dollar market. And so I think the same thing is going to happen in data analytics, and people are going to realize that it’s not scut work. It’s actually and honestly, DevOps salaries are a little bit higher than software engineer salaries, because people have realized, like, if you get a really good DevOps person, they’re, they’re a force multiplier. And so it’s no longer like, it’s so like, if you it’s scary, but like, you know, DevOps salaries are awesome, you find someone to really, you get a really good high DevOps team, man, they make your, you can start producing more code better and have less errors, and the whole system starts to home. 

Nick: Nice. So anyway, so let’s, let’s actually follow that a little bit. So that’s one of your things DevOps. Are there. Are there any myths or other you know, little insights like that, that you’d like to share with the folks out there? As we look forward? You know, again, data ops good career move, what else is out there? What are the little tidbits Do you have or myths that you want to maybe debunk?

Chris: Might latest is the thing that is has been really bugging me is is the value avoidant behavior that some organizations that some data analytic organizations have, and they’ve been so beat up by getting things wrong. They’ve been so frustrated, how slow they do, they do. They do define a wall, saying, Okay, here’s, I’m going to build a data lake, and I have no idea how the data is going to be used. But as long as I get my data in the lake, I’m done. And maybe they call it a lake house, or maybe they call it snowflake, but there’s organizations their goal is to move data from A to B. And then they, I’m done. And I find that really frustrating because it’s a value avoidant behavior. It’s part of, it’s necessary and important to do just like transforming the data, just like models and visualization, they’re all necessary. But like, you can’t, you can’t throw up your hands, you’ve got to make your customer successful. And like you got to know who your customers are. And so I find that sort of value avoidance and the sort of blinders I’m you know, I don’t know how I got the data, I got it, I do my I do my schema modeling are I do my ETL code, or I do my model. And I’m done. I find that frustrating, because I think we all are part of teams, and we’re all part of, we all should accept responsibility for results. And so that’s my one thing is like, man, if you’re on a team like that, I’d run away because inevitably, it’s gonna suck.

Chris: And it’s not and people aren’t doing it, because they’re malicious. They’re doing it because it’s really hard that jobs suck sometimes. And yeah, your customers, I live for years with very, very demanding extroverted marketing and sales customers who they got there, they got their livelihood, because they can schmooze and talk and like, I really hated when they call me up and and they wouldn’t be they wouldn’t yell, they would be passive aggressively nasty to me. It is almost worse.“Chris, that’s so bad. This is the fourth time it’s happened this month.” Oh, and you know, and then I know, they’d be hanging up the phone, and then swearing and then seeing, you know, how they could kick us out. And so I think, my experience, I just, I really just don’t like those conversations. I just, and so and I like to deliver value. And I don’t like to have those conversations. So if you, in my mind, the only thing I had that I had to do data ops, and help Help Help help make it happen. Because if I didn’t, my brain would explode. 

Nick: Yeah, I like that, as it’s like to, you know, build it and hope they will come right or from your perspective, what I’m hearing is, ask what they need, and then give it to them. And guess what you succeed.

Chris: If they don’t like it, iterate and improve it. If you do that quick enough, you’ll end up saving so much work, that you’ll end up that your customers will love you. And so instead of saying, I think they need 27 things, and I’m going to build my wall, and I deliver my definition of success is delivering the 27 things that are on my task list. That’s not the definition of success, the definition is your customer has gained some insight. And that’s a harder definition to success, initially, but it’s better, you’re much better off in the end. 

Nick: But to your point is the only way you know if that customer is going to be successful is if you talk to them. And you find out what they need, actually get their perspective, find out what they’re looking for find out, you know, actually interact with them. How’s that? How’s that for an interesting concept? Right, you know, interact with the individual versus just the screen in front of you. So again, I’d love that part of our list. 

Chris: And it’s hard like I miss coding, right. And I, I like working for months and months and months and some crystal Castle abstraction of my own making, it’s really awesome. But like, you know, I just learned enough like, you know, I’ve had enough experience in my life where I’ve done that. And then I said, I just did nothing for the last six months, I’ve gotten so wrong. And like, how many times in your career? Do you want to do that?

Nick: So as we’re going to be winding down our conversation, but there’s a couple things I like to do, as Chris says, we start thinking about that the things you’re looking at, you know, what do you think as you start to work interact with your, your clients, and what you’re seeing in the industry? What do you think are those next things that a CTO should be looking at, from, you know, as they look into the future? And what are those things that they should be putting on their desk and starting to consider?

Chris: Well, you know, I’ve been working and trying to market this idea of data ops, and some people call it model ops or ml ops, I don’t really care what you call it. You know, Gartner started to call it cross ops. Now, it’s like, whatever ops term is your favorite. But I think that ideas should be on the chief data officers. And yeah, they have information security, they have data governance, they have AI and data science, it’s hard to hire new people, you know, data security is a big issue. Those are all real things, right. But if you work on the team and the system, you’re going to accomplish all those things, and with a lot more velocity and a lot more quality. And so, to me, I think data ops or whatever ops, you call, it deserves a part of any data strategy. And it should be part of the toolkit of any, any team just like if you’re going into a software company, and just like many internal IT teams, and big companies, insurance companies, financial service companies have gone over the last decade on a DevOps transformation. That centers of excellence, they go to conferences, they have people and career paths. We need to data slash data ops centers of excellence in companies and start that transformation. And then our team because it’s not going to be overnight. Because, as you see, we’re talking not only about an approach, a technical approach to building data and analytic systems and workflows, but we’re also talking about a cultural pattern that’s hard for people to break. And that happened in software’s that happened in software and IT world as well. And I think this and everyone’s afraid of freaking Google and, and Amazon to come for their business, right? And they’ve all those teams have eaten, every part of their organization is agile and iterative. And you don’t get anything done. And so I think we’ve got, if you don’t do it, your competitors are going to get lunch?

Nick: Well, I think what’s really nice is everything you just described is actually kind of outlined in your ebook, the data Kitchen cookbook. So I’m going to encourage our listeners to actually go out and download that ebook, because I think a lot of the foundations that you just talked about are sitting inside that book, where it’s a great place to start a great way to kind of reshape the way we think about data operations and what we should be thinking about it as a system, as you know, working in a kitchen as a in a restaurant. So again, if I want to have my listeners, Chris, you know, get out and get Chris’s, the data Kitchen cookbook, you can download it at data kitchen.io, or there is a link in our podcast description for that ebook, for you be able to get a hold of it. So again, Chris, I gotta say, it’s been a complete pleasure having you on our show. I mean, it’s always a pleasure to talk with you because you bring a whole different perspective on things. And I get to learn from you each and every time. So thank you for being a part of  the InConfidence community today. 

Chris:I’m glad and thank you for your listeners. And you know, the data Kitchen Cookbook has got a lot of pictures. And it’s, you can read it by scanning the pictures and it can we even incorporated agile into how you read the book. So you can learn something by just scanning the pictures first before reading the articles. So how about that?

Nick: That’s my best kind of books. That is my best book right there. I love it.

Chris: Yeah, yeah.

Nick: So well, I want to thank our audience, thank you for listening to in confidence is the podcast for a community of data that just like yourself, and like Chris, we hope you found your time with us. Well spent. Also, we are enjoying your feedback and suggestions. So keep them coming. You can do that@InConfidence.privitar.com Once again, that’s InConfidence. That privitar.com InConfidence is all one word. Or you can reach me directly at Nick and I CK that CU RC, ru ru that’s net dot c u RC u r u@privitar.com. Or just connect with me on LinkedIn. Again, Chris, great having you enjoy the rest of your day. And for the InConfidence community. You know what, just you know. Until then, until our next conversation, keep on innovating with safe data. Thanks again for listening.

Outro: No matter where you are in your data journey. privitar is here to help privitar empowers organizations to leverage their data to innovate faster, while protecting the privacy of individuals at massive scale. privitar is unique in combining technology, thought leadership, and expert services to help your data operations thrive. Watch to learn more. Our team of experts is ready to answer your questions and discuss how data privacy can fuel your business. Visit privitar.com Thanks for listening to InConfidence brought to you by privitar. To hear more insights and advice on how to effectively use, manage and protect your data. Subscribe to the show and your favorite podcast player. If you liked the show, leave us a rating. Join us for the next data conversation.