Add ATO role & hiring page; clarify what/how split, ATO-as-gate, consume-before-build

**The principle.** Create infrastructure and incentives for team members to build and share AI-powered workflows, not just consume centrally deployed tools. The goal is an internal ecosystem of proven AI solutions.

**Consume before build.** The flip side of empowering builders is the discipline to consume before building: reach for what already exists across the company first, and build new only when nothing fits. That is what turns a pile of individual builds into a shared ecosystem.

**Why this matters.** Central IT teams cannot possibly understand the nuances of every role and workflow across GitLab. The people closest to the work understand their pain points, their edge cases, and what "good" looks like in their context. When we empower them to build AI solutions (and share those solutions with others facing similar challenges) we multiply our innovation capacity dramatically.

### What this looks like in practice

### Enterprise AI (the platform Hub)

Owns the AI platform, engineering capacity, governance, security review, and cross-function standards. Builds skills, agents, and integrations that any function can pick up. Does not own use cases inside any single function.

Owns the AI platform, engineering capacity, governance, security review, and cross-function standards. Builds skills, agents, and integrations that any function can pick up. Does not own use cases inside any single function. It does, however, own the *how*: partnering with the ATO to shape the technical approach and the best practice each solution should follow, regardless of which team ultimately builds it.

### ATO, AI Transformation Owner (the spoke)

A senior role embedded inside a function. Owns the AI roadmap for that function, qualifies use cases, partners with the assigned AI Engineer to deliver them, and reports value back to the function's exec sponsor. The ATO is the single accountable bridge between Enterprise AI and the function.

A senior role embedded inside a function. Owns the AI roadmap for that function, qualifies use cases, partners with the assigned AI Engineer to deliver them, and reports value back to the function's exec sponsor. The ATO is the single accountable bridge between Enterprise AI and the function. The split is right-hand / left-hand: the ATO owns the *what* and *why* (which problems to solve, in what order) and brings those problem statements to Enterprise AI, who own the *how*. The ATO also gates work built inside the function, by Champions or individual contributors, keeping it aligned to centralised strategy and standards. See the [AI Transformation Owner](ato/) page for the full role.

### Champions (the in-function Hub)

1. **Raise.** Team members surface ideas through their function rather than building independently.

2. **Triage.** The ATO prioritises against business outcomes and executive guidance.

3. **Scout.** The embedded AI Engineer explores, prototypes, and proves what works.

4. **Deliver.** A small cross-functional team takes proven concepts to production.

4. **Deliver.** A small, focused team takes proven concepts to production. Depending on complexity and the expertise required, the build runs through the assigned AI Engineer, the function's own engineering capacity, or Champions and builders inside the function. Enterprise AI owns the *how* throughout, and the ATO gates in-function builds for alignment.

5. **Share.** Successful solutions, patterns, and lessons feed back through the Hub for reuse across other functions.

**Consume before build.** Before building anything new, the ATO and the builders they pull in check what Enterprise AI, other ATOs, and other teams have already shipped, and build new only when nothing fits or the existing thing is genuinely wrong for the use case. In a federated model the largest risk is every function quietly rebuilding the same capability. Reaching for existing patterns first is what makes the shared library compound rather than fragment.

## A worked example

A Champion in a function notices that her teammates are spending roughly six hours a week reformatting the same kind of customer-facing email into different formats for different briefs. Some of the friction is raised with her directly; some she picks up by being close to the work. She raises it at the next Champion sync with the function's ATO.

| Decision | Owner |

|---|---|

| Use-case prioritisation in a function | ATO, guided by the exec sponsor's org priorities and company objectives. Larger or cross-functional calls escalate to the Exec Sponsor. |

| How a solution is built (technical approach and best practice) | Enterprise AI, partnering with the ATO. |

| Platform and tooling choices | Enterprise AI |

| Security, data, and governance review | Enterprise AI (accountable platform reviewer with published SLAs) |

| Success metrics in a function | The function's own business metrics. The ATO is responsible for moving them. |

| Aggregated metrics across functions | Enterprise AI |

| Champion selection in a function | ATO with sub-team manager sign-off |

| Success metrics in a function | The function's own business metrics. The ATO is responsible for moving them. The Hub aggregates across spokes. |

| Replatforming bespoke tools onto the standard stack | Enterprise AI |

| In-function builds (Champion or individual contributor) | ATO gates for alignment to centralised strategy and standards |

| Champion selection in a function | ATO, with sub-team manager sign-off |

| ATO hiring | Five-step loop; see [AI Transformation Owner](ato/) |

## Function vs division

---

title: "AI Transformation Owner"

description: "What the AI Transformation Owner role is, the operating mode it runs on, the profile we hire for, and how we run the hiring loop."

---

The AI Transformation Owner (ATO) is the spoke in our [Hub & Spoke & Hub](../) model: a senior role embedded inside a function that owns that function's AI roadmap and is the single accountable bridge between Enterprise AI and the function. This page covers what the role owns, the operating mode it runs on, the profile we look for, and how we hire for it.

It is the companion to [Operating Rhythm](../operating-rhythm/), which covers the cadence, channels and decision rights the role works within.

## What the ATO owns

The ATO owns the *what* and the *why* of AI inside their function: which problems are worth solving, in what order, and how value is reported back to the exec sponsor. Concretely, the ATO:

1. Owns the function's AI roadmap and qualifies use cases against business outcomes and executive priorities.

1. Brings problem statements to Enterprise AI, who own the *how*: the technical approach, the solution shape, and the best practice that should apply, regardless of which team ends up building.

1. Composes small, focused delivery teams from the right mix of builders, drawing on the assigned AI Engineer, the function's own engineering and operations capacity, and Champions across the function. Who builds depends on complexity, the expertise required, and the scale of the work.

1. Gates work built inside the function. Champions and individual contributors are encouraged to build, but the ATO keeps what they ship aligned to centralised strategy and best practice so the function's AI footprint stays coherent rather than fragmenting.

1. Reports value back to the function's exec sponsor against the function's own business metrics.

The ATO does not own the platform, the tooling choices, or the governance and security review. Those sit with Enterprise AI. The ATO is the connective tissue, not a parallel platform team.

## The operating mode: influence, not authority

The ATO succeeds by being trusted, not by being right. The role carries limited formal authority. The ATO can hold a line on the function's roadmap, but cannot compel a leader to accept a redesigned process, compel a Champion to contribute their time, or compel Enterprise AI to reorder its queue. Everything flows through influence: making the case for change with evidence and respect, and demonstrating value as work ships so the next conversation is easier than the last.

That makes trust the precursor to every hard conversation, and it builds in a deliberate sequence:

1. **Learn the process.** Sit close to the work, understand how it actually flows, and earn the respect of the people who own it.

2. **Earn the leader's buy-in.** The leader whose process is about to change has to believe the ATO understands it, respects it, and is redesigning it to make their team better, not to score a transformation win.

3. **Redesign the process.** Only once the first two are banked does the rebuild conversation get off the ground.

Skipping step two is the most common way the role fails at step three. The same trust has to be earned in the other direction too: with Enterprise AI and with the function's builders, who choose every day whether the ATO is a net positive to work with. None of that trust is granted by the role. It is earned by how the person shows up.

## What the role is, and what it is not

The ATO is a power user, not a software engineer. Enterprise AI's AI Engineer brings the technical depth and production delivery. The ATO brings business context, process intelligence, strategic prioritisation, and the ability to prototype at the no-code and low-code layer. High engineering depth is welcome but it is not the differentiator, and it is not what the role is evaluated on.

To be explicit, because people self-select toward the wrong frame:

1. Not a pure AI engineer role.

1. Not a build-everything role. The ATO orchestrates a pool of builders to deliver against the roadmap.

1. Not a top-down enforcement role. It runs on influence, evangelism, and the Champion network as much as on prioritisation authority.

1. Not an org-chart placeholder. If the ATO does not bridge well between Enterprise AI and the function, the model breaks.

## What we look for

The attributes that make someone successful in the role:

1. **Trust-builder by default.** Treats trust as the precursor to every hard conversation, and influence as the actual skill of the role rather than overhead alongside the "real" work.

1. **Tenacity.** Willing to hold a line and drive a change through, including with senior peers, without becoming the person leaders route around.

1. **Reimagination capacity.** Can rip up the way work is currently done and rebuild it, rather than simply accelerating the existing version. This is the practical expression of [Principle 2: redesign workflows, don't retrofit AI](../../guiding-principles/).

1. **Consume-before-build instinct.** Reaches for existing patterns first, and builds only when nothing fits. In a federated model the biggest risk is every function quietly rebuilding the same thing, so the ATO is tuned to surfacing and reuse, not just building.

1. **Curiosity and hands-on AI fluency.** Always looking for a better way, and already working with the tools: someone who has used our AI platforms, prototyped, and built a skill, rather than only read about them.

1. **Systems thinking.** Comfort with the complex but not necessarily complicated: integrating many moving parts into something that runs simply.

1. **Cross-functional orientation.** Defaults to understanding how their work affects and is affected by adjacent teams, rather than optimising in isolation.

## The profile we look for

People arrive at this role from different backgrounds. The strongest fit is a blend of two orientations:

1. **Programme and operations.** Operational rigour: rituals, cadence, change management, and the ability to build and sustain a peer community of Champions. This is what keeps adoption moving and the bridge role working.

1. **Domain depth plus hands-on AI.** Deep expertise in how the function actually works, combined with enough hands-on AI fluency to picture the redesigned version of a process rather than the lightly-automated one. This is what lets the ATO speak the language of every team and reimagine the work.

Pure engineering depth, while useful, is not the fit on its own. The AI Engineer from Enterprise AI brings the technical depth and production delivery; the ATO's value is business context, process intelligence, and the judgement to prioritise and redesign. Someone who defaults to building things themselves rather than orchestrating the system tends to recreate the AI Engineer role instead of the one the function needs.

## How we hire an ATO

ATOs are hired through a five-step loop designed to filter for both Hub partnership and function fit.

1. **TA screen.**

2. **Dual gate:** the Director, Enterprise AI and the function-side Hiring Manager, in either order. Either rejection is a hard no.

3. **Enterprise AI Engineer**, who assesses hands-on fluency with our AI tooling. Power user, not software engineer, is the bar.

4. **Peer ATO**, where one is available.

5. **Exec Sponsor**, who makes the final call and the offer.

The hard gates are the TA screen, the step-two dual gate, and the Exec Sponsor. Interviewers complete structured scorecards and calibrate as a panel before a decision.

## Related

- [Hub & Spoke & Hub](../): the operating model the ATO sits inside.

- [Operating Rhythm](../operating-rhythm/): the cadence, channels and decision rights the role works within.

- [Guiding Principles](../../guiding-principles/): the principles the role puts into practice.

- [Prompts are Process](../../prompts-are-process/): why owned, versioned process is the thing the ATO is really maintaining.

| Decision | Owner |

|---|---|

| Use-case prioritisation in function | ATO, guided by the exec sponsor's org priorities and company objectives. Larger or cross-functional calls escalate to the Exec Sponsor. |

| Use-case prioritisation in a function | ATO, guided by the exec sponsor's org priorities and company objectives. Larger or cross-functional calls escalate to the Exec Sponsor. |

| How a solution is built (technical approach and best practice) | Enterprise AI, partnering with the ATO. |

| Platform and tooling choices | Enterprise AI |

| Security, data, governance review | Enterprise AI (accountable platform reviewer with published SLAs) |

| Success metrics in function | The function's own business metrics. The ATO is responsible for moving them. The Hub aggregates across spokes. |

| Security, data, and governance review | Enterprise AI (accountable platform reviewer with published SLAs) |

| Success metrics in a function | The function's own business metrics. The ATO is responsible for moving them. The Hub aggregates across spokes. |

| Replatforming bespoke tools onto the standard stack | Enterprise AI |

| Champion selection in function | ATO plus sub-team manager |

| ATO hiring | See the ATO hiring overview below |

| In-function builds (Champion or individual contributor) | ATO gates for alignment to centralised strategy and standards |

| Champion selection in a function | ATO, with sub-team manager sign-off |

| ATO hiring | Five-step loop; see [AI Transformation Owner](../ato/) |

## Escalation path

Each AI Engineer pairs with up to two ATOs (a 1:2 ceiling). During the early phase of a spoke (typically the first quarter) we pair closer to 1:1 to accelerate ramp-up. As a spoke matures and a delivery rhythm sets in, the same AI Engineer can support a second one without losing depth.

## ATO hiring overview

ATOs are hired through a five-step process designed to filter for both Hub partnership and function fit.

**Step summary.**

1. TA screen.

2. Director, Enterprise AI plus Hiring Manager dual gate.

3. Enterprise AI Engineer.

4. Peer ATO.

5. Exec Sponsor (final and offer).

**Hard gates.** Step 2 is the dual gate: the Director, Enterprise AI and the function-side Hiring Manager both interview the candidate, in either order, and either rejection is a hard no. The other hard gates are TA (Step 1) and the Exec Sponsor (Step 5, who makes the offer call).

Full hiring detail lives with Enterprise AI.

## Related

- [Hub & Spoke & Hub](../) - the strategic narrative.