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?
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?
Unknown: And do you remember how you first got started working in data?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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.
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,
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?
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.
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?
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.
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?
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.
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?
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.
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.
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?
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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?
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.
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.
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.
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.
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.