There is a point in a lot of organizations where the data conversation starts sounding more serious, but not necessarily more clear.
The use cases are there. The business wants better reporting, cleaner data, more reliable metrics, sharper decision support, and eventually more advanced analytics or AI. Everyone agrees the direction is right.
Then the harder question shows up.
What actually has to exist for a data function to deliver?
I think that is where a lot of conversations go sideways. The language gets broad very quickly. People talk about strategy, governance, maturity, and skills. None of that is wrong. It is just incomplete.
A data function delivers when the work required to turn demand into outcomes is actually covered, and when the people responsible for that work have enough authority to move it forward.
That framing matters because it changes the question.
The question is not whether the organization has someone focused on data.
The question is whether the organization has designed a function that can actually do the work it expects.
I keep coming back to five lanes that have to be covered.
The first is business translation and prioritization. Someone has to work with lending, operations, finance, marketing, risk, and other business areas to decide which problems matter most, which use cases belong in the queue, what success looks like, and what should wait. Without that, the function becomes a collection point for requests instead of a mechanism for delivery.
The second is data engineering and platform support. Someone has to own the movement, integration, and reliability of the data underneath the work. If that lane is weak or informal, every new initiative starts by re-solving the same plumbing problem.
The third is analytics and solution delivery. This is where reporting, analysis, experimentation, decision support, and automation actually become business outputs. Without that lane, the organization can talk intelligently about use cases for a very long time without changing much in practice.
The fourth is governance and stewardship. Definitions, quality expectations, access rules, lineage, and accountability do not become real because everyone agrees they matter. They become real because someone owns them. That is part of why data work so often stalls. The ambition moves ahead, but the trust layer underneath it stays too loose. That pattern sits underneath a lot of what I have written before about why transformations stall, why strategy still does not move, and why responsible AI has to be a practice rather than a slogan.
The fifth is risk, controls, and adoption. In a financial institution, it is not enough for a use case to be technically possible. It has to fit the control environment, the workflow, and the expectations attached to decisions that affect members, operations, or compliance. It also has to be adopted by the business instead of living beside it as an interesting extra.
Those five lanes are the function.
But even that is not the whole story.
A data function also needs authority.
A title without written authority to prioritize work, convene the right people, set standards, escalate blockers, and influence decisions is not really a function. It is a role sitting next to the work.
It also needs support capacity.
If the organization expects discovery, use case assessment, source analysis, requirements gathering, data preparation, reporting, governance support, and delivery, then the function needs enough analyst and engineering support to do those things. Otherwise the data lead or team spends most of its time coordinating dependencies it does not control.
A simple example makes this clearer.
Say a credit union wants to improve member retention using better data and analytics. That sounds straightforward until you unpack the work. Someone has to help the business define what retention actually means in that context. Someone has to identify which member signals matter and where that data lives. Someone has to pull it together in a way that is usable. Someone has to build the analysis or decision support that helps frontline or marketing teams act differently. Someone has to make sure access, definitions, and stewardship are clear. And someone has to help the business actually use the result in campaigns, service workflows, or branch follow-up.
That is not one task. It is not one skill. And it is definitely not just a matter of having a data title on the org chart.
I think the more useful question for leadership is no longer, “Do we believe data matters?”
It is, “Have we actually designed a function that can do the work that belief requires?”
Because that is the real divide.
Some organizations have demand around data. Others have built a data function. The difference is not enthusiasm. It is whether the operating lanes are covered, whether the authority is real, and whether the team has enough support to move from ideas to outcomes responsibly.
When you look at your own institution, have you built a data function, or have you mostly built expectations around one?
