Before You Join: A Data Leader's Due Diligence Framework
Four questions that separate a genuine data mandate from an expensive lesson.
Preface
The most costly mistakes a data leader makes rarely happen on the job. They happen before it, in the interview room, when the role sounds like greenfield opportunity and the hiring manager uses words like "transformation," "modern stack," and "strategic."
This framework distils hard-won field experience from regulated financial services environments in Malaysia and the broader region. It is not theoretical. It is the checklist that should have existed before signing the offer.
Four questions. Each one a diagnostic. Together, they tell you whether you are walking into genuine mandate or structured ambiguity dressed as opportunity.
The Framework
Question 1: Who owns the data strategy, and what is their background?
This is the first question because everything downstream depends on the answer.
A data strategy owned by someone from a compliance or audit background will default toward defensibility. Data governance, ownership matrices, classification frameworks. These are not wrong, but they are insufficient. The mental model is "data as liability to be managed" rather than "data as asset to be leveraged."
A data strategy owned by someone from business operations will default toward reporting. Dashboards, extracts, regulatory submissions. The mental model is "data as a by-product of process" rather than "data as a decision engine."
A data strategy owned by someone from technology infrastructure will default toward systems. Uptime, integration, data movement. The mental model is "data as content in pipes" rather than "data as institutional knowledge."
None of these profiles is disqualifying on its own. What matters is whether the person owning the strategy has the range to operate across all three dimensions and the authority to make decisions that cut across organisational lines.
What to look for: Ask directly. Who signs off on the data roadmap? What is their career background? Have they ever owned a P&L that was shaped by a data decision? If the answer is a committee, ask who chairs it and whether that chair has a casting vote.
Red flag: The data strategy is "shared" between IT and a governance function with no single accountable owner. Shared ownership in ambiguous organisations is the functional equivalent of no ownership.
Key resource: Davenport, T.H. and Prusak, L. (1998). Working Knowledge: How Organizations Manage What They Know. Harvard Business School Press. The foundational text on how institutional knowledge is owned, transferred, and destroyed.
Question 2: Does the data team have a seat in the steering committee?
Presence in governance structures is a leading indicator of organisational respect for the data function. It is not sufficient on its own but its absence is almost always disqualifying.
A data team without a steering committee seat is a delivery function. It receives requirements, executes, and reports back. It does not shape priorities, challenge assumptions, or surface the second-order consequences of decisions made without data context. Over time, this structural exclusion compounds. The data team becomes expert at answering the questions it is asked, rather than surfacing the questions that should be asked.
In regulated financial services specifically, the absence of data representation in steering creates material risk. Technology and data decisions made without a qualified data voice frequently generate BNM RMiT compliance gaps, PDPA exposure, and downstream audit findings that are expensive to remediate.
What to look for: Ask whether the Head of Data or Chief Data Officer attends the IT Management Council, the Technology Steering Committee, and the relevant risk governance forums. Ask not just whether they attend, but whether they present, vote, or advise. There is a meaningful difference between attendance as an observer and participation as a decision-maker.
Red flag: The role you are being hired into reports into a function whose head does not attend steering. This means your escalation path is filtered through someone who is themselves not in the room.
Key resource: DAMA International (2017). DAMA-DMBOK: Data Management Body of Knowledge, 2nd Edition. Technics Publications. Chapter 3 covers data governance structures and the organisational placement of data leadership in detail.
Question 3: What does the core system vendor relationship look like?
In Malaysian FSI, the core system is almost always the gravitational centre of the organisation. Policy administration in takaful, loan origination in banking, claims management in insurance. The vendor that owns the core system has disproportionate influence over what data is accessible, in what format, on what schedule, and at what cost.
A data platform built without a clear understanding of the core system vendor relationship is built on an assumption. That assumption is that data will flow from the core system cleanly, reliably, and without commercial friction. In practice, this assumption fails more often than it holds.
Vendor relationships that are opaque or poorly documented at the point of hire become the primary constraint on data platform delivery. Integration APIs may be proprietary or undocumented. Data extraction may require vendor-billable professional services. Schema changes in the core system may not be communicated proactively to the data team. These are not edge cases. They are the default condition in organisations where the vendor relationship predates the data function.
What to look for: Request sight of the core system vendor contract or a summary of its data access provisions before accepting the role. Ask whether there is a named integration owner on the organisation's side. Ask what the process is for requesting a new data feed or API endpoint from the vendor, and how long it typically takes.
Red flag: No one in the interview process can answer the question. Or the answer is "we have a good relationship with them" with no supporting specifics. Relationship quality in vendor management is not a data access guarantee.
Key resource: Ross, J.W., Weill, P. and Robertson, D.C. (2006). Enterprise Architecture as Strategy. Harvard Business School Press. The operating model concept in this text is directly applicable to understanding how core system vendor dependencies constrain or enable data architecture choices.
Question 4: Has the organisation ever made a decision because of data, rather than despite it?
This is the most important question and the hardest to answer through an interview process. It requires inference from evidence rather than a direct answer.
Every organisation claims to be data-driven. The phrase has been so thoroughly absorbed into corporate communication that it has lost almost all diagnostic value. What reveals the truth is not the aspiration but the history.
Decisions made because of data have specific characteristics. They were contested before the data was available. The data changed the outcome. Someone in a position of authority accepted an answer they did not want because the data said otherwise. These moments are memorable precisely because they are uncomfortable. If the people interviewing you cannot recall a specific instance, it is likely because it has not happened.
In organisations where data is genuinely used for decisions, certain structural conditions tend to be present. Business owners request analysis before committing to product or pricing decisions. Post-mortems reference data. Strategy documents cite internal evidence rather than only external benchmarks. The data team is asked questions, not just asked to produce reports.
What to look for: Ask the hiring manager directly: "Can you give me an example of a business decision in the last 12 months that was changed or reversed because of something the data team surfaced?" Listen not just for the content of the answer but for how readily it comes. A leader who works in a data-informed culture will answer this without hesitation.
Red flag: The answer describes a dashboard that was built, a report that was produced, or a metric that is now tracked. These are outputs. They are not decisions. The question was about decisions.
Key resource: Brynjolfsson, E. and McElheran, K. (2016). "The Rapid Adoption of Data-Driven Decision-Making." American Economic Review, 106(5), pp. 133-139. Empirical evidence on the organisational and performance characteristics of firms that genuinely operationalise data in decision-making.
Synthesis: Reading the Pattern
These four questions are not independent. They form a diagnostic pattern.
An organisation with a strategically-placed data owner, a steering committee seat, a well-governed vendor relationship, and a demonstrable history of data-driven decisions is rare. When you find one, the compensation negotiation is secondary. Take the role.
More commonly, you will find partial scores. Two out of four is workable with the right mandate and sponsorship. One out of four is a delivery role, not a leadership role, regardless of the title on the offer letter.
Zero out of four is not a greenfield opportunity. It is barren ground. The absence of all four conditions does not mean transformation is impossible. It means the organisation has not yet decided it wants to be transformed. That decision cannot be made by the person they hire. It has to precede the hire.
No amount of technical capability, regulatory fluency, or architectural vision compensates for an organisation that has not made that foundational choice.
The tuition for learning this the hard way is expensive. This framework is the cheaper alternative.
Summary Reference Card
| Question | What You Are Diagnosing | Minimum Acceptable Answer |
|---|---|---|
| Who owns data strategy and what is their background? | Strategic intent and leadership range | A named individual with cross-functional authority and analytical credibility |
| Does the data team have a steering committee seat? | Organisational respect for the data function | Active participation, not observer attendance |
| What does the core system vendor relationship look like? | Platform delivery constraints | A documented integration framework with named ownership |
| Has the org made a decision because of data? | Cultural and behavioural data maturity | At least one specific, verifiable example in the past 12 months |
Further Reading
| Resource | Relevance |
|---|---|
| DAMA-DMBOK 2nd Edition (2017) | Data governance structures, organisational placement of data leadership |
| BNM Risk Management in Technology (RMiT) Policy Document (2020) | Regulatory expectations for data and technology governance in Malaysian FSI |
| Ross, Weill and Robertson, Enterprise Architecture as Strategy (2006) | Operating model and vendor dependency frameworks |
| Davenport and Prusak, Working Knowledge (1998) | Institutional knowledge ownership and transfer |
| Brynjolfsson and McElheran, Rapid Adoption of Data-Driven Decision-Making (2016) | Empirical evidence on data-informed organisational behaviour |
| McKinsey Global Institute, The Age of Analytics (2016) | Sector-level benchmarks for data maturity in financial services |
| Gartner, Data and Analytics Maturity Model (updated annually) | Structured maturity assessment framework applicable to FSI |
About Guinevere Analytics
Guinevere Analytics is an independent quantitative analytics and consulting firm focused on data engineering, quantitative Islamic finance, and AI-enabled financial infrastructure in the Malaysian and regional market.
Expensive but valuable tuition has a way of producing the clearest frameworks.