How data literacy, evidence-backed decision-making, collaboration, and continuous learning are embedded in the organisation's culture.
CUL-01
Evidence-backed decision-making culture within the domain
When decisions are made within your domain, how consistently are they actually supported by reference to data, as opposed to being made on intuition, precedent, or authority alone, with data invoked only afterward if at all?
Maturity level descriptions
Decisions in the domain are made without reference to data as standard practice; when data-backed arguments are raised, they are routinely overridden by opinion or seniority. Domain decisions are made on judgement, precedent, or authority, with data-based arguments rarely raised and easily dismissed when they are.
Data is occasionally referenced in decision discussions, depending on the individual involved, but is not a consistent or expected input. Data Engineer can describe an instance where data was referenced in a decision, but confirms this depends on who is involved rather than being standard practice.
For priority decision types, referencing relevant data is an expected, defined part of the decision process (e.g. a business case template requiring supporting data). Data Engineer can point to a defined decision process for priority decision types that requires supporting data to be referenced.
Evidence-backed decision-making is the norm across most decision types in the domain, with the quality and use of supporting data reviewed as part of decision governance. Data Engineer's domain reviews decision quality and data usage as part of governance, with evidence-backed decisions being the observed norm rather than the exception.
Evidence-backed decision-making is fully embedded in domain culture — data is proactively brought into decisions by default, decision outcomes are tracked against the data-based rationale, and the practice is reinforced through visible recognition or feedback. Data Engineer observes that data is proactively brought into decisions without needing to be requested, decision outcomes are tracked against the original data-based rationale, and good evidence-based practice is visibly recognised.
CUL-02
Cross-functional collaboration between data and business teams in the domain
How effectively do data-focused roles (Data Engineer, data engineers, analysts) and business stakeholders in your domain actually work together, as opposed to operating as separate groups that hand work back and forth with limited shared understanding?
Maturity level descriptions
Data roles and business stakeholders in the domain operate entirely separately, communicating only through formal, transactional requests with no shared forum or relationship. Interaction between data roles and business stakeholders happens only via formal tickets or requests, with no regular direct engagement or relationship.
Some informal collaboration happens between individuals who have built personal working relationships, but this is inconsistent and not structurally supported. Data Engineer has informal working relationships with some business stakeholders, but confirms this depends on individual rapport rather than any structural support.
A defined forum or mechanism exists for regular collaboration between data roles and business stakeholders in the domain (e.g. a recurring working group, joint planning sessions). Data Engineer participates in a named, recurring collaboration mechanism with business stakeholders in their domain.
Cross-functional collaboration is systematic and covers the domain's significant initiatives, with joint accountability for outcomes and collaboration effectiveness periodically reviewed. Data Engineer's domain has joint accountability structures (shared goals, joint sign-off) for significant initiatives, with collaboration effectiveness reviewed periodically.
Data and business roles in the domain operate as a genuinely integrated team with shared goals, mutual fluency in each other's concerns, and collaboration that is self-sustaining rather than requiring deliberate structural reinforcement. Data Engineer and business stakeholders share goals and enough mutual understanding of each other's priorities and constraints that collaboration happens naturally, without needing formal mechanisms to sustain it.
CUL-03
Continuous learning pathway for the Data Engineer's own data capability
How well-supported is your own ongoing development as a Data Engineer — access to training, peer learning, and skill development that keeps your capability current with evolving data practices and tools?
Maturity level descriptions
No support exists for the Data Engineer's ongoing skill development; whatever capability the Data Engineer has was acquired before taking on the role or entirely through self-directed effort with no organisational support. Data Engineer has received no training, budget, or organisational support for developing their skills since taking on the role.
Some development opportunities are available informally or occasionally (e.g. an ad hoc course), but access is inconsistent and not planned. Data Engineer has accessed at least one development opportunity, but confirms this was ad hoc rather than part of any planned pathway.
A defined development pathway exists for the Data Engineer role (e.g. recommended training, certifications, internal learning resources), and the Data Engineer has engaged with it. Data Engineer has a documented development plan or defined pathway relevant to their role, and can show engagement with at least one element of it.
The Data Engineer's development is actively tracked and reviewed (e.g. as part of performance/development conversations), with progress against the defined pathway monitored and support adjusted as needed. Data Engineer's development is reviewed on a defined cycle (e.g. as part of regular performance conversations), with progress tracked and support adjusted based on identified needs.
The Data Engineer has access to a continuously evolving development pathway that keeps pace with emerging data practices and tools (including AI/GenAI-related skills), with peer learning and knowledge-sharing actively encouraged and structurally supported. Data Engineer's development pathway is proactively updated to reflect emerging practices and tools, and the Data Engineer participates in structured peer learning or knowledge-sharing (e.g. communities of practice) as a normal part of their role.