Data Engineering Podcast

Share on social media:

Support Data Engineering Podcast

[00:00:13] Unknown:

Hello, and welcome to the Data Engineering Podcast, the show about modern data management.   Atlin is the metadata hub for your data ecosystem.   Instead of locking your metadata into a new silo, unleash its transformative potential with Atlin's active metadata capabilities.   Push information about data freshness and quality to your business intelligence,   automatically scale up and down your warehouse based on usage patterns, and let the bots answer those questions in Slack so that the humans could focus on delivering real value.   Go to data engineering podcast.com/atlan   today, that's a t l a n, to learn more about how Atlan's active metadata platform is helping pioneering data teams like Postman, Plaid, WeWork, and Unilever achieve extraordinary things with metadata.  

When you're ready to build your next pipeline or want to test out the projects you hear about on the show, you'll need somewhere to deploy it. So check out our friends at Linode.   With their new managed database service, you can launch a production ready MySQL, Postgres or MongoDB cluster in minutes with automated backups, 40 gigabit connections from your application hosts, and high throughput SSDs.   Go to dataengineeringpodcast.com/linode   today and get a $100 credit to launch a database, create a Kubernetes cluster, or take advantage of all of their other services. And don't forget to thank them for their continued support of this show. Your host is Tobias Macy. And today, I'm interviewing Tracy Daniels about the role and responsibilities of the chief data officer and how it is evolving along with the data ecosystem. So, Tracy, can you start by introducing yourself?  

[00:01:39] Unknown:

Absolutely. Tracy Daniels. I am the CDO, the chief data officer for Truist.   In this role, I do a couple of things. I work on governance for the company, so really laying down sort of the law rules   in how we use and manage data.   I manage our data platform, so how we deliver both the capabilities   and the data to our teammates across the organization.   And the last bit is around culture. How do we create a data culture for everyone in the organization, And what does that mean in terms of literacy and and how we interact?  

[00:02:12] Unknown:

And do you remember how you first got started working in data?  

[00:02:15] Unknown:

So it's kinda interesting. I probably got into data probably 25,   30 years ago. And I started,   I was managing   a program at another bank called the Information Foundation Program, and we were starting to roll out things like data stewards   and talking about domains of data, and   we were working on data warehouses.   We were also working on things like where do we store physical copies of data, and how do we manage and move that data, and how do we retain it? And then just from there, you know, I've sort of come in and out of different technology jobs.   But the last 1 also involved, call it, the consumption side of data. So I had an analytics   team prior to coming to Truist that actually did fraud analytics.  

So this is a bit of a full circle moment where the   database job, the change management job, the operations function, and the analytics function all comes together.  

[00:03:11] Unknown:

From the initial introduction to working with data, can you describe a bit about what your path to your current position as the CDO looks like and some of the   experiences that you have leaned on along that way to be able to   be confident and   grow into that role?  

[00:03:28] Unknown:

Yeah. It's been, I would say, not a ladder to the role of CDO, but more of a lattice. And so there's been, as you mentioned, right, sort of complimentary skills that I think I've picked up along the way.   1, I would say just, you know, the technical background, not only on data, but in applications and how are folks gonna use it and what's the actual purpose we're trying to support and the problems that we're trying to solve.   I've had experience in change   technical   change, the the technical change, the process change, the impact on the customer and the client.   1 of my favorite roles that I've had along my journey has actually been in operations where I've been customer facing. And I remember an event where we had a significant   data issue,   and, you know, it sort of crystallizes that it's not just a technical or academic exercise when it impacts, you know, thousands of customers and how they see and interact with, their financial services. So all of that, I think, just informs the way I go about my job,   which is hopefully a very business driven end to end perspective.  

But not just, again, the technology, but the processes and how do people   consume the changes and the capabilities that you're you're delivering on behalf of the company.  

[00:04:47] Unknown:

As somebody who's working in this position of the CDO, I'm wondering if you can enumerate the core responsibilities   and the scope of influence that you have in your organization?  

[00:04:58] Unknown:

It's very much an enterprise role. Right? That at its core, as I mentioned, that's a control function.   There's a fiduciary and ethical responsibility   in terms of how we think about and use data.   And so on the governance side, the control side, that's 1 element of the job.   The other, I think, is the engineering function and just how do you create elegant systems with the right level of   scale and availability and resiliency   that, you know, your organization   is looking for. So there's a technical aspect of the job that's fun and exciting and, as you know, always and ever changing.   And then there's this collaboration   component of the job because at its core, data   is used technically in our systems of records and in our applications,   but, also, it's very close to the line of business. Right? It's very integral in the objectives of what   our teammates in the line are trying to do. And so I find that our role also is a bit of a bridge between   the technical teams, the data science and the analytic teams, the business teams with what they're trying to do and know   about our customers and about our financial services. So   control function, technical function,   and a collaborative, right, culture function that helps to bridge between   our line of business teammates and our technical teammates.  



[00:06:20] Unknown:

As you mentioned, the CDO is viewed as an enterprise responsibility. And I'm curious what your experience has been as to   the factors that determine when   an organization   should have a CDO as a distinct role.   And in the absence of that being in explicit position,   where do those responsibilities   tend to aggregate in some of the other common roles such as CTO,   CEO, you know, geese of engineering, etcetera?  

[00:06:50] Unknown:

Yeah. So   at Truist, we do have a distinct chief data officer role   in addition to a CTO   role. Right? So 1 of my peers who is also assured service is responsible for the infrastructure and the data centers and the compute and the storage, etcetera, that we use at Tris. And I have yet a 3rd peer who's responsible   as the CSO, the chief information security officer, for how we protect all of those systems, both the hardware, the network, the software,   the data that sits in. And we actually work in concert.   You know? At the end of the day, we want to be able to say those elements   of the stack from the building all the way down to all the bits that go across that we are managing effectively and consistently,   and in a way that allows our divisional CIOs to use it on behalf of the businesses that they serve with the applications   that they build.  

I actually had a conversation with a higher education   group that was thinking about   creating a CDO role, and they've not had 1 before. And 1 of the questions I asked them was, why do you want 1? Why do you think it's important? And how are you planning to compete with data?   I think that helps determine just how big a role, the scope, the remit, the expectations that you have   on a CDO because what I found is many of us in this role actually have very different remits   across industry depending on what the business is actually trying to do and how they're trying to compete with data.   But I think what you see is more and more, the role does become distinct. And as the function is fairly broad and important,   you want somebody focused on it as a discipline,   not necessarily as an afterthought or just an adjunct to it, another technical role.  



[00:08:37] Unknown:

As you mentioned, there are people who are starting to think, oh, I need to have a chief data officer   responsibility,   but they don't necessarily   understand   what the   requirements are or what the potential impact is on the organization.   And I'm wondering what you have seen as some of the   emerging   I don't know if best practices is the right term, but maybe consensus   on   what the responsibilities   of that CDO role look like and some of the ways that they might be   bespoke across different organizations   and their   industries or scale of operations and things like that?  

[00:09:16] Unknown:

Yeah. I think there's 3 things that I see   either coming together or sometimes, you know, very intentionally separated. 1 is the governance role, right, that we sort of talked about. I've seen that be more of a risk role or a compliance role where   it is separate from actually managing   the platform itself.   And I think there's perfectly good reasons for having that separate. I think there are synergies when you put it together.   In that, you have a group that's not making a,   call it, you know, theoretical governance responsibility   or thought process   and are actively applying it, and in some cases, even automating   that function when it is paired together with a delivery function.  

So what I've typically seen is there's an element of governance and or then there's the platform.   Are we focused on more of the technical components?   The last bit that I think has become more of a decision point   around the role of CDO is also, what do you do with analytics?   Do you leave it in the line? Do you create centers of excellence to enable analytics?   And so you start to see a lot of chief data and analytics officers. Right? And so what that represents in my head is   now you're taking the platform component and the consumption   of it, and you're putting those a little bit closer together. And, again, I think as you continue to automate this space and the   capabilities   continue to grow, whether it's in compute or storage or in the actual   algo   space, it makes sense that you create a really seamless pipeline that you could go more in, and so the role can start to converge more, right, when your governance   is equally   codified as your platform engineering capabilities,   as   your consumption   through the analytic workbench.  



[00:11:06] Unknown:

For people who maybe are working in   engineering leadership or engineering management,   where perhaps they're the, you know, the head of data or VP of data,   what are some of the ways that   those sets of responsibilities   and the   areas of focus that they're paying attention to differ as they maybe elevate into that CDO position?  

[00:11:28] Unknown:

To me, the inflection point becomes   maybe a couple of things.   How do you articulate   and solve   and measure   the business problem that you're trying to solve?   Because it becomes less about solely being   technical prowess,   and it really becomes   about enabling the business. And so you wanna be able to speak   about the technical capabilities   in terms of what they are delivering and doing on   behalf of the business. Right? So the business value   that you're driving and ultimately   products   that you're creating   for your businesses to consume and leverage   and serve their clients.  

The other, I think, inflection point   for senior engineering leaders is to be able to   tell the story, right, of what the organization   is doing, again, I think in those business terms.   But to take something that can be very technical,   something that can sometimes come across   a little bit more dry, and really create the art of the possible   that business leaders are attracted to and understand   relative to, you know, what they're trying to deliver for their clients. I think those   2 things layered on top of the technical capabilities   is what starts to make the difference in people's careers.  



[00:12:53] Unknown:

As you move between those different levels of maybe a VP of data or VP of engineering into that CDO position, I'm also interested in understanding   how that shifts the   people   and maybe business units that you spend the most time with. Because I would imagine that as you move into the CDO role, you're actually spending more of your time talking to the CEO, the CTO,   maybe some of the business stakeholders, and some of your customers. Whereas in the VP of engineering, head of data type of role, you're probably more likely to be working directly with the engineers. And I'm just wondering how that shifts the way that you spend your time and the ways that you think about how you're communicating and who you're communicating with.  

[00:13:34] Unknown:

I have a few different constituents that I focus on. Absolutely,   the business. And I've actually got a whole team in my organization   whose responsibility it is to have regular   touch points with our line of business partners, inclusive of the data scientists that are, you know, practitioners on the data that we create so that we really understand   what their needs are. We understand where their pain points are. Sometimes we've created those pain points, and we wanna make sure that we are resolving them as quickly as possible. But, again, back to that point around the business value, making sure that we're attuned with   what we are delivering and making sure that it drives business value on their behalf.  

The second set of folks that I spend a lot of time with includes   my peers, right, and making sure that I'm   plugged into the activities that they're doing on the application front. And that there's as little daylight as possible between   how we think about and activate our data strategy and what they're driving   on the application side and making sure that it's in line with where we're going as an overall tech team, and it doesn't feel fractured for them.   I also spend a lot of time with my   teammates because   this space is so hot. It is so forever changing.  

Try to make sure that we're getting a read on how our teammates feel, how are they feeling about their skills, how are they feeling about, you know, being engaged,   how are they feeling about the value of work that they're doing, are we   meeting their needs with respect to career development? It is   incredibly difficult to find really strong talent, and it's even harder to keep it. So making sure that we're treating our teammates well   and staying connected with them. So those are all the, you know, stakeholders that I'm sort of managing manage   as   manage as   well. The last constituent that I spend time with that I think is really important as you continue, you know, your career journey   is with my peers.  

So right before our conversation, I was actually speaking with the gentleman who manages data at UPS. Right? Different industry, different applications,   similar   challenges, similar   considerations   in terms of how we're thinking about it. But I like to spend some time with my peers so that we can bat around different ideas,   but also find some nuggets of things that I can apply maybe differently in in banking and financial services that I was thinking of. A couple of interesting elements to dig into in that peer conversation,  

[00:16:14] Unknown:

1 of which is how you actually   find and connect with people who are in similar roles and are open to sharing their experiences.   And then in the case of being able to learn from each other, I'm interested in understanding what are some of the   common core considerations   and requirements   across data responsibilities   regardless of industry,   and what are some of the elements that you have found to be unique   to your role in your organization   and just figuring out how do you translate some of those lessons to your peers to be able to make sure that everybody's growing and expanding the capabilities of data   as an ecosystem for everybody?  



[00:16:56] Unknown:

I am the world's best   Google and LinkedIn stalker there is. So sometimes it's, you know, reading an interesting article about an inflection   point for a company, and I'll search out if there's somebody in data.   I have leveraged our consulting partners to make introductions because they're doing work with similar organizations   and my peers in the industry. So I'll ask for   introductions to leaders that are doing maybe some interesting things that might be in health care or retail   or whatnot. That's been good. Sometimes when you're at conferences or you have an opportunity to be part of a roundtable, I'll pick at least 1 person   that I would like to follow-up with and, you know, reach out either on LinkedIn or while we're at a conference and say, hey. I'd love to follow-up. And everybody,   nobody has ever turned me down. I think we all, you know, strive for community, and so everyone's always very   generous with their time.  

Then what I try to do is, you know, come up with a a couple of questions. Like, why am I interested in this person? Is it because of the industry? Is it because of a specific   project that I think I've heard that they're working on? And I'll come up with just a short couple of questions   that I'm also willing to answer. Right? So that there's an exchange of ideas.   And, typically, I will try to keep it going. So whether it's once a month or once a quarter,   I try to make it not a transactional   exchange, but more a relationship that we're building.   And I'll think of, you know, more questions and places that we might wanna focus on.  

With   peers that are in the same industry, I'm very careful to stay away from competitive topics. So we're probably more talking about   governance, organizational structure. We're probably talking about talent,   I mean, things that we're looking for in the market.   With peers who are in different industries, I'm really interested in how they might be using data a little bit differently   than how we're using it in financial services for those, you know, sparks of innovation of things that ideas that we may not be tackling or either tackling it   in a different way. And then usually,   regardless of what industry folks are in, there's a lot to talk about technically and things that, you know, folks are sunsetting new   technologies, folks are contemplating for similar problems, and they're usually around   data quality and getting, you know, sprawl under control. And more and more, it's around really activating analytics and making it easier for the data scientists, data analysts, and the companies to do their work.  



[00:19:31] Unknown:

RudderStack helps you build a customer data platform on your warehouse or data lake. Instead of trapping data in a black box, they enable you to easily collect customer data from the entire stack and build an identity graph on your warehouse, giving you full visibility and control.   Their SDKs make event streaming from any app or website easy, and their state of the art reverse ETL pipelines enable you to send enriched data to any cloud tool.   Sign up for free or just get the free t shirt for being a listener of the data engineering podcast   atdataengineeringpodcast.com/rudder.  

As you are doing the work as the CDO of Truist, what are some of the projects and activities that are vying for your time and attention, and how you think about being able to balance them to make sure that you're addressing the highest priorities, but not letting things slip through the cracks?  

[00:20:23] Unknown:

That's the magic   that we're always trying to balance.   You know, as part of our data strategy,   1 of the things we included in the approach was always starting with the business use case. So making sure that the work that we're doing is truly grounded in business value   for the company, not just interesting technical project,   but something that is going to benefit a line and multiple lines right over time. There's an opportunity to, you know, grow and expand that capability on behalf of many lines of business.   Also, try to focus on and leave   capacity   for foundational   items.  

So things that people may not be asking for, but we know we need to build   or things we need to improve or tech debt we need to solve.   Because what I found is when you don't do that   and things break,   you lose all your capacity to focus on the new things or the business value   driving opportunities because you're spending so much time   fixing things. So   we carve out a good   20 plus percent of our time   to stay ahead of   call it technical debt or you know, things that we believe are truly foundational so that I think pays dividends and preserves the capacity to work on the new fun stuff that's coming down the pipe. And then there's a sliver that I think about,   we're not really brilliant at it yet, but we'll get there, around really truly innovating   and pushing the envelope   on certain technologies. So we do try to leave room   in the basket, right, of capacity to really focus   on some of those newer things,   moonshot things, stuff that we don't need today,   but we think could be game changers in the future.  

It's more of an art than a science.  

[00:22:14] Unknown:

In terms of the ways that you think about the composition and organization   of your teams and the different data professionals throughout your organization, I'm wondering   what your approach has been as far as how to think about   which capabilities   you need, what their responsibilities   and scope of impact need to be,   and how they're organized in relation to their various engineering counterparts and business counterparts to make sure that all of the communication is flowing,   but also so that different data professionals aren't isolated   because they're embedded too deeply in different groups or that they're not all too consolidated   and starting to get into an echo chamber around their own data oriented concerns?  



[00:22:58] Unknown:

I think we've learned, and we're still learning,   how to manage   all of that. So   a couple of things. There are   horizontal and vertical views, I would say, in my organization.   The vertical views are those that are usually more line of business focused. Right? So they're   building assets, moving data,   and have some sort of an alignment to the line of business so that   there's a lot of muscle memory and a little bit more context on the data that they're touching and managing.   Then there are horizontals, which might be capabilities regardless of your line of business   that you're gonna use. Right? More platform orientation,   even some of the ops   functions that we do. And we try to run communities of practices,   both that touch the horizontal and the vertical. So what do I mean by that? There are routines and ceremonies that we do where we're gonna focus on a line of business so that we can go deep into the technology stack, but keep the context of the line of business.  

We may share   other things that are going on in other lines of business, but we're trying to do it in a way where we are   providing context for that particular line of business.   We also have communities of practice in certain ceremonies where we're doing it as a horizontal.   So I may be pulling all the engineers together, or there might be   opportunities for, you know, data scientists to pull together on AI and ML kind of topics.   So that regardless of where you sit in the organization, we're creating community for you to   best practice share and reuse   ideas rather than feel like you're on an island on its on your own.  

The last bit that we've not   fully operationalized yet, but we're getting there, is we're trying to create   collateral that allows us to push, but also for the end users to pull and be able to do it at a pretty seamless way. So we started with wikis and things where you can go to figure out, you know, what you need to do. There are snippets of code if you wanna play with certain things. There's explanations   for platforms or new technologies that we have coming out, but we've done it from a very technical perspective.   I think there's   a opportunity for us to lean into more of a product focus and think about, okay. If we were really a software company, how would we make this more consumable   to the layperson   and continue to improve those types of collateral that's out there.  



[00:25:25] Unknown:

In terms of your   work as the CDO,   it's definitely subject to the   evolution of the data ecosystem   and growing capabilities   or shifting   patterns and practices for how to think about processing data and working with data. And I'm wondering   how you approach that balance of making sure that you're able to set a particular direction and maintain course and build velocity towards it,   but not miss out on potentially game changing capabilities   as new   patterns or technologies emerge and just being able to understand   which ones are here to stay, which ones are a flash in the pan, and which ones are maybe subject to consolidation, and you need   to give them some time to evolve and mature and just what that balance looks like as you're also trying to work with the business to make sure that you're just delivering value and that that's where your focus is lying?  



[00:26:20] Unknown:

So, you know, we've been kinda consumed with this merger   for the last couple of years. I would say we haven't   fully matured   a practice that allows us to do it. But what I envision is more   like something I ran in a prior role. I was actually the ops role, but I had responsibility   for   a digital platform for our customers. And what I would envision is more like a quarterly   strategy session where we are looking at   what do we have today?   You know, are we buying or selling, you know, the current technology?   What is on the horizon?   Have we done any experimentation   in that area?  

What is on our roadmap to start experimenting and playing with. And then as we talked about a little bit earlier,   leveraging our monthly touch points with our internal stakeholders   to continue to create a backlog of   ideas and capabilities that we should be building upon.   So I would like to take us from where I think we are more today, which is just incremental   regular review of projects that are on deck that pretty much get spun up on an annual basis   to more of   a quarterly strategy session or a product based view where we are   comparing the backlog. We are prioritizing   the items that we think drive   either business value   or foundational capabilities that are, you know, emerging on the market.  

And we're running it on a much more   continuous basis because I think it would force us to your point, right, to really assess   the basket of things that we're working on.   And, you know, in some cases, stop some things   much quicker   to adopt other things perhaps   faster as we move forward.  

[00:28:09] Unknown:

Now that you have come out the other side of this merger and you're looking back at your   experience to date in the role of the CDO and looking forward to where you want to move to, I'm wondering what you   see as the evolution   of your role as the CDO and   how the   general consensus around what that role is responsible for   influences the way you think about the work that you're doing.  

[00:28:35] Unknown:

As we pivot, right, out of this merger, I'm looking at   how do I better organize and run   like a product function, like a   product delivering organization   on behalf of enterprise   technology. Inclusive in that, how do I continue to have a greater   customer focus so that we're really building things that drive   value for our teammates.   The third thing I'm also focused on is how do I enable   my teammates, so my DCIO   partners and the analytics teams   to be able to do and consume more.   I don't ever want my organization to be a bottleneck only place where really amazing data work happens. I want   our teammates   in the lines and in the tech teams to be as proficient   and accountable   for how data gets used as we move forward.  

And then maybe the 4th place we continue to evolve is   more innovation   in the things that we do. So even a topic like governance, I push our teams   to automate more of that work. I push our teams to think about how you could infuse governance with AI and ML to be able to predict   more work, more quality being woven into   our products,   more measurement of the elements of data that are being used, across the company. So again, as we pivot, I think about how do we become more product focused, how do we continue to   improve our client centricity   around how we think about the products that we create and who's gonna be using them ultimately?  

How do we enable use   as frictionless   as possible for our teammates, what their experience is? And then how do we continue to,   innovate   across   our various functions and data?  

[00:30:28] Unknown:

And another interesting   consideration   to explore is   as you are working at the c level of your organization and you have your own set of priorities   and areas of focus,   I'm wondering what are some of the organizational   politics and pressures that you have to navigate and some of the ways   that other priorities at the c level can be at cross purposes to what you're trying to do as the CDO?  

[00:30:54] Unknown:

You know, resources are always scarce. Right? So the prioritization   conversation is a very   important 1 to make sure that   there isn't cross purposes and that we are all aligned on the same   organizational   goals. And that can be challenging. Right? And that's where I think really understanding your customer helps you to articulate   better   how your capabilities   support their work rather than competes   with their work.   I think there are   great synergies I see with my peer DCIOs.   And usually it's a timing. Like, are you going to be able to consume my capability, or does the capability you're trying to drive in your application actually need to come first before   a collaboration between our teams makes sense.  

But, again, it's a constant   conversation   across teams to make sure that the alignment is there,   and we are all doing   our part, right, to further the corporate strategy and the corporate focus   and figuring out how what we're doing helps align to that rather than directly compete with 1 another.  

[00:32:02] Unknown:

In your experience working in this position of the CDO, what are some of the past experiences   and skills acquired that you found to be most useful to make sure that you're successful   in the responsibilities that you have?  

[00:32:16] Unknown:

For me, collaboration is key. No no man or woman is an island onto themselves. Like, to get work done,   we need to be able to collaborate and, you know, communicate across our teams.   I like to make sure that myself, my team, we have a healthy   amount of curiosity about what's going on in the market so that we don't, you know, get left behind. We can apply   newer techniques to the work that we're doing and hopefully   gain some efficiency from the work that we're doing. And then lastly, I mean, at the end of the day, this is a technical function, but we like to make sure that we're running it like a business. Right?   I don't ever want to be, you know, replaced by, you know, the ability to go externally to get the work done because   they're either better at it or cheaper than what we do. So   there is, you know, a focus on being efficient and effective   in what we're doing. And then maybe the last bit that I mentioned earlier was also just taking care of our teammates. You know, In this world, in this trying times, you know, we do try to focus on 1 another being caring   with our teammates, being in tune with what they're trying to achieve from a development perspective because it is incredibly   competitive out there on the market. And we wanna make sure that, you know, Truist is known as a destination   place to be in technology and specifically in data. And so making sure that we focus on   the people in our organization, I think, is is also really key.  



[00:33:43] Unknown:

Bigeye is an industry leading data observability   platform that gives data engineering and data science teams the tools they need to ensure their data is always fresh, accurate and reliable.   Companies like Instacart,   Clubhouse and Udacity use Bigeye's automated data quality monitoring,   ML powered anomaly detection, and granular root cause analysis to proactively detect and resolve issues before they impact the business.   Go to dataengineeringpodcast.com/bigeye   today to learn more and keep an eye on your data.   To that point of being able to attract people because the work that you're doing is interesting and valued,   wondering how you think about   advertising that and thinking about   the ways that you're   building and investing in your own technological and data capabilities   to   make that a place that people will want to seek out and work at given the fact that it is such a competitive landscape for people who are working in the data professions?  



[00:34:44] Unknown:

You know, first, we try to make sure that the work that we do is really interesting and compelling so that we've got   great stories   to tell people when we're out, you know, whether it's at conferences or we're going to colleges and universities looking for really amazing talent. We want them to be excited about the work that we do and the people with whom we do the work.   And so we are really focused on making sure that we're doing great work, and we're, you know, recruiting really great people that create an amazing environment.   The second thing that I think we do is, you know, we have these types of conversations where we share what we're doing at Truist so people can learn about it. You know, even today, I think a lot of people don't understand   how technologically   focused financial services is. And so while, yeah, it's sexy to go work for, you know, start up x,   a lot of really amazing work happens. And so making sure that we get the word out through   communications and conversations with folks like you is really important.  

And we like to show up in other places. So, you know, conferences, and as I mentioned, colleges and universities,   sharing the work that our teammates are doing, I think, is really important to attract the talent.  

[00:35:57] Unknown:

In your interactions with other CDOs   and peers   in similar positions across different organizations and industries. I'm wondering, what are some of the most   interesting or   unexpected ways that you have seen those responsibilities   and the position addressed in those different contexts and environments?  

[00:36:17] Unknown:

A couple of interesting places. I'm   always fascinated   by my peers that   work to really monetize   data, meaning that they're either   selling or creating products on the market, not just internally focused.   Because I think those kinds of   opportunities   help amplify   the power of data.   Everybody loves to tell the Amazon stories. And when you start to accumulate a series of those stories in various industries,   I think it really brings to life the power and possibility of data. So   those that are working on those really   externally   visible   marketplaces and exchanges   and using it as a way to generate revenue streams,   I think are really interesting.  

My peers who   have figured out how to do a lot of automation   and use predictive capabilities of data to   automate the mundane,   I find highly fascinating.   So whether it's how you manage   servers or how you optimize   delivery routes   or how you   codify   governance,   expectations,   and code,   I love to poke on and think about how folks are using   the data to solve   the flashy problems, but also the really mundane   problems that are out there.   The last group that maybe I also   focus on and think about is and governance is never the sexiest topic, but how folks are thinking about   the way the laws are changing,   right, with respect to data and how do you stay ahead of that?  

How do you   interpret it, and how do   you make it come to life for your teammates so that they   abide by the law and they come up with creative solutions to really lean into   the expectations,   both of the law, but also of customers that are operating in these new spaces where the velocity   and the volume of data just continues to   accelerate.  

[00:38:24] Unknown:

In your own experience   of working in this position, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:38:32] Unknown:

Oh, so many.   So, you know, 1 thing that's kind of interesting to me is I had some experience in my past around the business process   and   really understanding the business process   that the data supports and spending time there   not only   in understanding it, but as you're creating new capabilities,   really rethinking the business process. Right? Because at the end of the day, I don't wanna just   collect data   in an antiquated business process. You wanna really think about how you use it   to power and simplify that business process.   And that's always fascinating to me because it takes what's a, you know, a technical capability and really   applies   it in terms of how the business is working. So, you know, 1 of the lessons learned and 1 of the places I'm, you know, thinking about how my team   continues to grow is really understanding the business process that underlies the data that we   collect, curate, and ultimately move half of the company.  

I think the other, you know, lesson learned or the thing that I appreciate is something I mentioned a bit earlier, which is   spending time on the fundamentals,   the resiliency,   the availability,   learning from your mistakes pretty actively   so that it eats up less and less of our time   as practitioners.   I think we're starting to do more work to collect information on   where those friction points are in the places that our teammates consume our data. So, again, we can   reduce the amount of time that they have to spend   solving for, navigating those problems, and they can spend more of their time on the fun stuff. Right?  

So to me, you know, 1 of the lessons learned is get the   fundamentals right, solve for the friction points so that your capacity can be really used for, you know, neat and fun things. And then, you know, I always tell the team, like, we just have to keep learning. I need to keep learning. I try not to   stay too far away from   the technology advances that my team's actually working on. And so I'll ask them to   understand   how you're thinking about,   you know, architecting this differently to really avail ourselves of compute differently? So really spending our time to go a little bit deeper in the technology,   but always, you know, stepping back and thinking about how are we ultimately gonna use it in the company.  



[00:41:01] Unknown:

For organizations   that are looking to invest in their   capabilities with data and trying to   derive value from it and be able to use that for powering the business, what are the cases where the distinct CDO position is the wrong choice and they need to instead invest in their engineering leadership and focus on their core competencies   and let the engineers kind of do the work that they need to do to use the data to power these systems and just moving those responsibilities more into existing roles rather than splitting it out to a distinct position?  

[00:41:35] Unknown:

I'm completely biased, I'll admit.   I think there is a role for   data.   I do, to your point, think that   there is a role   where data is infused in many places. So I guess I would say it this way. Don't assume   that the   chief data role or the data role is the only place   that data happens.   The way I've tuned our organization   is   we actually assume that data happens in multiple places.   So it's more about enabling   and educating folks to be able to conduct those roles   effectively.   But, yeah, completely biased. I'm not sure that you never don't need a data role, but I definitely see where the data role shows up in many.  

[00:42:24] Unknown:

For folks who are working in engineering or working with data, what advice do you have for anybody who's interested in charting a career path to the CDO seat or something of a similar set of responsibilities?  

[00:42:38] Unknown:

I think raise your hand for   more and more   responsibility.   So, you know, if you work on platform x, gain some skills in platform,   you know, y. You know, move from the lake to a cloud,   get some experience   pitching and selling   solutions, not just capabilities.   Again, it's this building the acumen of being able to tell the story and why   that function   matters and how it helps to improve the business itself.   And I think also, you know, take some risks.   I've appreciated   being wrong   enough times because I think you   develop a perspective. A perspective. A, I think you start to lose your fear of being wrong, but you also,   I think, learn some things along the way that you can apply.  

So, you know, I always tell my team, you know, do a little bit to the left and a little bit to the right of what your job is so that you're doing it better, but you're also learning   in the context of the   pipeline that you're working in. Right? So if you're working with your security   teammates on a project,   do a little bit more   security side so that you're understanding at a more visceral level   how the data needs to be protected and how you, you know, think about not just use, but misuse.   And I think that helps you do your job a little bit better. And I think the collaboration,   I love learning from my peers   and finding ways to apply, you know, things that they're doing in their space, in the data space, and hopefully, vice versa. Right? Exporting some best practices   as well. And I think those are some of the things that get you noticed, not just as a technologist,   but as a business leader and a solution provider.  



[00:44:24] Unknown:

Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And as the final question, I'd like to get your perspective on what you see as being the biggest gap in the tooling or technology that's available for data management today.  

[00:44:39] Unknown:

I think there's this opportunity   around how we integrate all these disparate pieces and parts that still   has room   for improvement. So I think about data that sits on prem,   data that sits in the cloud. I think about the number of tools that are out there. And, ultimately,   I think something   that allows you to integrate those panes of glass   elegantly   would be really helpful.   I also think about   the life cycle of data. So from,   you know, the models that are being developed and the data that they're using and the engineering that has to have the platforms that they need to sit on.   Again, things that help us integrate from AI ops to model ops to data ops and allows us to orchestrate that channel as efficiently as possible   is really important.  

And as we continue to move into more   advanced analytics, I think   there's a good number of really great platforms that make it easier and easier for folks to do that work.   I think helping folks,   you know, manage the traceability   of that work as it proliferates both in models that people build and tools that people buy is really critical as well as to be able to explain   the outcomes that we're we're creating.  

[00:45:58] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share your experiences   and perspectives   on the chief data officer role and the responsibilities there and your experience working in that space.   It's definitely very   interesting conversation and, interesting   consideration about how people think about scoping their career journey. So I appreciate all of the time and insight that you've shared, and I hope you enjoy the rest of your day. Thank you so much. It's been a pleasure.  

[00:46:30] Unknown:

Thank you for listening. Don't forget to check out our other shows, podcast dot in it, which covers the Python language, its community, and the being used, and the machine learning podcast,   which helps you go from idea to production with machine learning.   Visit the site at dataengineeringpodcast.com.   Subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a product from the show, then tell us about it. Email hosts at data engineering podcast.com   with your story. And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.