The senior data leadership posting at most institutions — whether titled Director of Data Platforms, Director of Data Analytics and Engineering, Director of Data Systems, VP of Analytics, Head of Data or Head of Analytics, Chief Data Officer, Chief Data and Analytics Officer, or Chief AI Officer — is two roles fused into one job description. One role is engineering: build and operate the warehouse, the ETL, the semantic layer, the lineage tooling. Stand up the dbt models. Maintain the Snowflake schemas. Configure the Fivetran connectors. Keep the freshness SLAs in line. That is a senior data-engineering role the field knows how to define, screen for, and reward. The screens know what to look for.
The other role is governance and subject-matter expertise: own the contracts on top of the warehouse, the decision interface those contracts feed, and the relationships with the stakeholders whose decisions the contracts have to support. Write the explicit, named understanding that turns integrated bytes into something a stakeholder can act on with authority. Know what a principal needs to act on a recruitment funnel. Know what a clinician needs to act on a no-show count. Know what a District Education Officer needs to act on multiple state systems’ incompatible cycles. Know what a program officer needs to stand behind a quarterly figure when a funder asks. That is a senior governance-and-domain role. Organizations that have it know what it looks like, but the screens for it are underdeveloped and the rubric rarely names it as its own thing.
The institutional posting names both roles. The screens assess only the first.
Why the rubric misses the half that matters
This is not a critique of the screens. Engineering rubrics know how to assess engineering depth. They have benchmarks. They can ask candidates to walk through past projects, write SQL, defend architectural decisions, debug pipelines. Engineering competence is observable and rateable. The governance-and-SME half is not. There is no equivalent benchmark. No standardized question reveals whether a candidate can sit across the table from a Provost, a CFO, a program officer, or a clinician, hear what they need from the data system, and translate that into a contract the institution will write down and enforce. There are no standard interview questions for “can you author the contract that makes a $50M aid scenario reversible at machine cadence when the AI assistant gets the recommendation wrong?” So the screen defaults to what it can measure. The engineering half passes the rubric. The governance half is treated as either implicit or as a soft skill that will fill itself in.
The result is predictable. The institution hires a senior data engineer. The engineer builds the integration. The integration runs. The dashboards work. The schemas are tight, the freshness SLAs hold, the lineage tooling reports green. And then the Provost still cannot get a 360 view, the program officer still cannot answer the funder when the number moves, and the clinician still cannot act on the population-health view because nobody has written the contract that says they are allowed to. The engineering succeeded and the decision interface stayed unowned, which means the role failed at the half of its work that mattered.
The institution’s response to this is, usually, to hire another engineer. Or to commission a governance committee. Or to buy more tooling. None of these address the actual gap, because none of them brings into the institution the person who can write the contract — not because the contract is technical, but because it is operational. The contract specifies who reads, who writes, on what cadence, under what consent, with what reversibility, with what audit trail, with what authority to act. Writing that contract requires knowing what the principal, the clinician, the program officer, the dean need to be able to do. The knowledge lives in domain context, in stakeholder fluency, in the operator’s understanding of the decision the contract is meant to support. It does not live in the stack. (For the anatomy of the contract itself, see The contracts between systems.)
A senior engineer who has built three warehouses does not, by default, know any of this. There is no reason they would. The knowledge is not transmitted by warehouse-building. It is transmitted by sitting inside institutions for years and watching what decisions get triggered, what contracts hold, what stakeholders trust. That is not engineering experience. It is subject-matter experience with operational depth, and it is the half of the role that gets assumed in by the rubric.
Two architectures, one honest choice
The structural correction is not to replace engineers with subject-matter experts. Engineering depth is necessary. The integration has to be built. The schemas have to be designed. The freshness has to hold. The correction is to specify the role honestly: the Director of Data Platforms or Director of Data Analytics and Engineering or Chief Data Officer at most institutions is two halves of one job, and the screen has to assess both halves. The current screen assesses one and assumes the other. The half it assumes is the half the role fails on when it fails.
There are two valid architectural resolutions to this gap, and the institution has to choose between them deliberately rather than drift into one by default.
The first is a single-role fusion: structure the role as two halves and screen for both. The candidate brings engineering depth and governance-authoring depth into a single senior position, reports into an independent function, and writes the contracts on top of the integration they also help build. Most foundations, smaller mission-driven organizations, and K-12 networks are best served by this architecture because the volume of governance work does not justify a second senior position.
The second architecture is appropriate when the institution is large enough or the contracts complex enough to warrant separate functions: a Director of Data Engineering for the engineering half, and a separate Director of Decision Systems, Chief Data Governance Officer, or equivalent for the governance and SME half. Both roles report into the same independent function. The engineering role builds and operates the substrate. The governance role writes and enforces the contracts on top of it, supports the stakeholders who act on the data, and owns the decision interface. The roles work together, but each has its own rubric and its own authority.
Architect roles sub-divide across these two functions. Substrate-first architects (platform, cloud, data platform) report into the engineering side. Definition-first architects (enterprise, information, semantic, master data management) report into the governance side, because canonical data models, enterprise data dictionaries, and semantic layers are governance work. Data architects and solution architects sit at the seam, typically reporting into engineering but partnering with governance because their designs anticipate the contracts the governance function will author on top.
Most R1 universities, large foundations, regional healthcare systems, and state-scale public-sector organizations are large enough to need this two-role architecture, and many of them have not yet realized it. The senior data role they keep posting and filling is the engineering role. The governance role is missing from the org chart entirely, so even when the engineering role is filled by a strong engineer, the work that would require a governance authority has no owner.
Managed-platform vendor strategy (Snowflake’s managed services, Databricks workspace, and equivalents) has also reduced the in-house engineering ceiling a governance-anchored role requires, which makes the second architecture viable at smaller scale than it would have been a decade ago. A senior governance lead can partner with engineering on guardrails and policy while using managed services to move the data function forward, without needing a large in-house engineering team behind the work.
A growing pattern at large research universities is to fuse both halves into a single senior associate-CIO-level role that names both data infrastructure and data governance in its title, sometimes paired with a distinct data-officer designation, and reporting into IT leadership with an academic-side coordination line. The title names both halves: enterprise data strategy, governance and policy infrastructure, data stewardship culture, and the technological substrate the strategy sits on. The dual reporting line signals institutional awareness that the role serves both academic strategic decision-making and IT delivery, not only the engineering function.
The structural risk that remains is rubric capture. Even with a title that names governance and an academic-side coordination line, the screen often still gets written from inside the function the role reports into. Reporting line under a CIO means the rubric for evaluating candidates could revert to engineering depth, regardless of what the title says. The title is a step forward. The screen has to follow it, or the role’s posted scope and the role’s actual screen drift apart from the day the position is opened.
Either resolution requires the institution to name what is currently being assumed. The rubric is hiring for half the role. Whether the fix is a better single role or the addition of a missing second role is an architectural choice. Refusing to make the choice is the failure mode.
Where the role sits shapes what the screen sees
The rubric problem has a deeper root in where the role sits. Most institutions place data infrastructure ownership under the CTO or CIO. Once that placement happens, the rubric gets written by an engineering function, the screens filter for engineering depth, and a governance-and-SME-anchored candidate looks “non-traditional” to a screen calibrated for pipeline depth. The contracts the role writes end up optimizing for the reporting function’s incentives rather than the institution’s whole-organization decision interface. Even within a misplaced reporting line, though, the rubric could assess for the missing half. It does not. (The upstream argument about the seat itself is Where should data sit?)
The pattern is visible from several angles to anyone who has been around senior data hiring at scale.
The empirical pattern that JD scans reveal
A focused scan of senior data role postings across sectors makes the rubric problem concrete. The pattern holds across Director of Data Platforms, Director of Data Analytics and Engineering, Director of Data Strategy, VP of Analytics, Chief Data Officer, and, increasingly, Director of AI Transformation and Director of AI Center of Excellence titles, sampled across six org-core types — technology company, product company, research institution, foundations or nonprofits anchored in monitoring, evaluation, and learning (MEL), service provider, and traditional enterprise.
The reporting line is the first signal the scan reveals. The roles overwhelmingly sit inside engineering functions. Director of Data Platforms postings at technology and ed-tech companies report into the CTO, VP of Engineering, or Chief Product and Technology Officer. Director of Data Analytics and Engineering postings at technology companies report into the CTO or VP of Engineering, and at media and ed-tech companies often into a Chief Product Officer or Chief Product and Technology Officer. At universities, Chief Data Officer or Associate CIO for Data roles report into the CIO. VP of Analytics roles at enterprise organizations report into IT or operations. Director of Data Analytics roles at K-8 networks and operationally-heavy mission-driven organizations often report into the COO. The exception, when it appears, is a small subset of foundations and MEL-anchored organizations where the role has been placed under a Chief Impact Officer or SVP for Design and Impact rather than a CIO. At a national mission-driven foundation, for example, a Director of Data Strategy and Impact Analytics (a MEL / Impact Measurement role in the map’s general vocabulary) was structured to report into an SVP for design and impact rather than into IT. When the role sits under an impact function, the rubric can reflect both halves: governance and stakeholder fluency are named explicitly, the skill tier includes program evaluation and mission alignment, the stated outcomes include funder reporting and partner-facing analytics. But this placement is champion-dependent. When the chief impact officer who wrote the role leaves, the placement often does not survive. Without sustained investment in the cross-functional collaboration the integrated role required, the organization reverts to its siloed defaults — data governance and architecture pulled back into a technology or digital-products function, research and evaluation regrouped into its own specialist cluster, delivery work sometimes outsourced to contractors — and the integrated rubric dissolves into whichever silo’s rubric is dominant. The rubric problem was papered over by the champion, not resolved by structure.
The skills tier is the second signal. The engineering tier is named with specificity in every posting: Snowflake or BigQuery or Databricks, dbt, Fivetran or Airflow, Python, SQL, Tableau or Power BI, often a long list of specific tools and platforms a candidate must prove they have used in production. The domain-SME tier and the governance-contract-authoring tier are named more abstractly when named at all: “stakeholder management skills,” “experience in cross-functional collaboration,” “ability to translate business requirements into technical solutions.” These phrasings are not assessable in the way specific tool proficiency is assessable. A candidate without dbt experience cannot fake their way through a technical interview. A candidate without governance-authoring experience can describe stakeholder management plausibly without ever having written a governance contract that actually held in production. The screen catches the engineering gap. It cannot catch the governance gap.
The emerging AI-native roles show the same pattern in a newer register. Recent postings for Director of AI Transformation or Director of AI Center of Excellence, sometimes reporting into an SVP for Data rather than into a CTO or CAIO, name the engineering tier with production-grade specificity — model registries, integrations, single sign-on, data-loss prevention, agentic systems, large-language-model tooling — while the governance and SME tiers are named as traits rather than as capabilities that can be screened: “strong governance instincts,” “proven ability to influence across an organization,” “ability to make complex technical topics clear to non-technical audiences.” The rubric problem is not something the AI-native evolution of the role has resolved. If anything, the governance gap is more consequential here than it was in the pre-AI role: engineering-tier specificity has grown, governance and SME tiers have stayed as trait-language, and the stakes of a governance failure at machine cadence are higher than they were at pipeline cadence. Regulated sectors — health (HIPAA, HITECH, 42 CFR Part 2), education (FERPA), commercial data platforms (SOC2), financial services (GLBA, PCI) — are the partial exception, because compliance frameworks force specificity in the compliance tier regardless of reporting line. But compliance specificity is not the same as governance specificity. A JD can name HIPAA or FERPA carefully while leaving “strong governance instincts” as the only signal for the semantic-and-decision-authoring tier that the role actually needs. Where the two coincide — a small number of academic medical center governance postings, or Fortune-scale enterprise CDO roles that name semantic layer, knowledge graphs, and RAG readiness explicitly — the rubric is meaningfully better. Where compliance is named but the semantic layer stays abstract, the rubric problem is masked by regulatory language, not solved.
The stated outcomes are the third signal. Engineering-anchored postings name engineering KPIs: pipeline uptime, data freshness, schema reliability, lineage coverage, time-to-insight. MEL-anchored postings name decision-quality outcomes: program officer ability to act on the data, funder reporting that lands, partner-facing analytics that drives decisions, evaluation findings that inform program design. The MEL postings are the contrast case the scan reveals most clearly. They show what the rubric looks like when the institution has structured the role around the decision interface rather than around the engineering substrate. They are also the rarest pattern in the corpus.
The cross-tabulation that emerges is consistent. Engineering-anchored reporting lines produce engineering-tier-only rubrics. Impact-anchored or program-anchored reporting lines produce rubrics that name both halves of the role. The reporting line is upstream of the rubric. Where the role reports determines what the screen assesses. And in the institutions where the contracts most need to be written (foundations doing impact reporting, K-12 networks doing student-success analytics, behavioral-health agencies doing population-health work, public-sector education systems doing state-level integration) the role most often reports into an engineering function whose rubric then misses the half of the role that the institution needs. Part of what drives this is stakeholder self-doubt on the program side. Program and mission-side leaders often feel they cannot supervise a data leader effectively, and read tight coupling with an engineering function as the safer, better-managed placement — even when the role’s substantive work sits closer to their side.
The visible asymmetry in JD skill-tier language
Across the scan, what postings name and how specifically they name it follows a sharp pattern.
The engineering tier is named with specificity. The SME tier is named abstractly. The governance and contract authoring tier is rarely named at all. A candidate reading the rubric is being told, implicitly, which half of the role the institution cares about screening for.
The role landscape underneath the rubric
The asymmetry the chart above reveals in JD emphasis has a counterpart in what the roles are for. The map below distributes seven senior data-leadership roles across the five stages of the decision arc — build the system, govern the system, interpret the signal, support the decision, own the decision. Each cell shows how heavily the role loads that arc position. The roles in the map cluster around one or two arc positions. No single role carries every arc stage to a heavy level. The band underneath the map shows what the composite role many JDs imply would require: heavy across every arc position at once — the shape no real role fits. That is why rubrics written for the composite produce senior-data-leadership searches that stall.
The contrast cases visible in the scan
Where the screen did include both halves, the role had been structured to demand both halves from the start, and the rubric followed. A Data Hub leadership role posted at a national philanthropy-supporting organization screened for full-stack data fluency (engineering, governance, stakeholder management, sector knowledge) as a baseline requirement, and the screen worked because the role had been structured to demand it. A separate Director of Data Strategy and Impact Analytics role at a national mission-driven foundation, which reports into an SVP for design and impact rather than into an engineering function, named the engineering tier (survey platforms, Python, statistical-analysis environments, SQL, BI tooling, cloud warehouse) with comparable specificity to the SME tier (mission-driven and public-sector context, domain knowledge in the foundation’s focus area) and the governance tier (data governance structures, steward roles, metadata standards, quality control systems, RASCI project management). Both roles are sometimes described in the trade press as “unicorn” roles because they require capability ranges most candidates do not bring. They are not unicorns. They are what the role needs at most institutions; they are just rare because most institutions have not structured the role to demand both halves and so have not bothered to screen for both.
The pattern across postings
The sector breadth these observations draw on is what makes the pattern legible. Reading Director, Head, VP, and Chief-level data leadership postings across sectors — K-12 networks and public-sector education, behavioral-health agencies and healthcare-services organizations, MEL-anchored foundations and philanthropy-support intermediaries, ed-tech and educational publishing, health-tech and clinical research organizations, enterprise data leadership at Fortune-scale healthcare payers, financial services (wealth management, community banking, fintech), enterprise SaaS, and legal-services organizations building AI and data-intelligence functions — is what makes the pattern legible. The same engineering-tier-specific and governance-tier-abstract shape recurs regardless of sector, with the specific exceptions the earlier paragraphs name (regulatory compliance, impact-anchored placement, deliberate two-role architecture). The pattern lives in how the JDs are written. Any specific candidate’s screen outcome depends on many things — resume shape, cultural fit, referral network, current head-count and scope, adjacent-experience gaps against the eventually-hired candidate — that are not being diagnosed here.
A live scan of six recent VP Data and AI postings across sectors — mission-driven humanitarian services, private-sector mission-driven housing, media, mission-driven federated healthcare, regulated mission-driven service delivery, and enterprise SaaS — confirms the pattern directionally but adds nuance. Engineering-anchored reporting lines (CTO, CPO) produce engineering-anchored rubrics with governance and SME as trait-language. Impact-anchored reporting lines (Chief Impact Officer, Chief Design and Impact Officer, or an equivalent Measurement / Evaluation / Learning function) produce rubrics that name all three tiers. Two exceptions matter. Regulated compliance environments force governance to be named specifically because HIPAA, FERPA, refugee-services compliance, or equivalent requirements make governance non-optional. And at least one major mission-driven federation has already implemented the two-role architecture named earlier — a VP Data Strategy and Analytics reporting into the COO, partnered with a separate VP Technology Strategy under the CIO — pointing at what the deliberate structural resolution can look like in practice.
The operator’s test that resolves the hiring question
The operator’s test that resolves the hiring question is the same operator question the integration-contracts argument used. Asked of the candidate: can the person you are about to hire write the contract that lets a stakeholder act on what comes out the other side of the integration? Not can they build the integration. Can they specify, in writing, who reads what, who writes what, on what cadence, under what consent, with what provenance, with what reversibility, and with what authority — for the decision the stakeholder is trying to trigger. If the screen does not assess for that, the screen is hiring half the role.
The fix is not heroic. The fix is to add the governance-and-SME half to the rubric explicitly, design the interview to assess for both halves, and structure the role’s reporting line so the half the institution most often misses is given the authority to do the work it was hired for. This is editorial work on the job description and structural work on the org chart, not a new hiring philosophy. It does, however, require the institution to admit that the role it is hiring for is not the role it has been screening for.
When a leader asks me what they should be doing differently in this hire that their predecessors did not, the answer is not more rigorous engineering screens or better recruiters. It is a rubric that names both halves of the role honestly, an interview process that assesses for both, and a reporting line that lets the governance half hold authority across the institution rather than defer to whichever function it reports into. Without those pieces, the screen keeps hiring engineers to do work half of which is not engineering. (For the paired argument on what the institution is actually betting on when it makes this hire, see Two bets, one institution.)
Written July 2026 for the Analytic Bytes Library. A rubric-and-role piece drawn from a focused scan of senior data postings across six org-core types, contrast cases at two national mission-driven organizations that have structured the role to demand both halves, and one candidate’s hiring loop offered as a data point rather than as evidence.
Questions, pushback, or a problem that looks like this one? Write to chai@analyticbytes.systems.