Operating model design: org chart, hiring plan, RACI, and tooling spine

Most 'operating model' deliverables stop at the org chart

Walk into a typical AI strategy engagement deliverable and you find an org chart, a couple of role descriptions, and a list of 'capabilities' the new function will provide. The company's HR team can't actually hire from it because the role descriptions are vague. The PMO can't actually plan from it because the RACI doesn't exist. The platform team can't actually procure from it because the tooling decisions haven't been made. The deliverable is a presentation, not an operating model.

Real operating model design specifies enough that the receiving organization can act. The hiring plan has actual role descriptions, target salary bands, hiring sequence, and reporting lines. The RACI covers the actual decisions the AI function will make, with named role-types responsible. The tooling spine names actual platforms — model gateway, eval framework, observability stack — with rationale and integration patterns.

The org chart specifies reporting lines, capacity, and the boundary with adjacent functions

An AI function reports somewhere — usually engineering, sometimes a chief data office, occasionally a chief AI officer when the function is large enough. The reporting line affects autonomy, budget authority, and how the function intersects with adjacent groups (data engineering, ML platform, product, security, legal). The chart has to pick a reporting line and explain why, not leave it open.

Capacity is the second variable. A 4-person AI team has a different operating model than a 25-person AI organization. The chart specifies the right size for the next 18 months given the company's use-case backlog and risk posture. Bigger is not better; under-scoping is worse than over-scoping at this stage.

Org-chart roles

6–14 depending on company size and risk

Hiring waves

3 platform / applied / governance

RACI decisions covered

~40 across delivery and governance

Tooling-spine components

~8–12 platforms and integrations

The hiring plan sequences platform, applied, and governance

We sequence AI hiring in three waves. Wave 1 is the platform — a senior platform engineer who can stand up the model gateway, retrieval, and observability infrastructure, plus a tech lead. Wave 2 is the applied side — the engineers who build the customer-facing AI features against the platform. Wave 3 is governance and operations — the eval owner, the governance chair, the model risk function as it scales. Hiring against the wrong sequence is one of the most expensive mistakes in this work.

The most common mistake is hiring applied AI engineers before the platform is in place. They show up with no infrastructure to build against, write one-off integrations directly to vendor APIs, and three months later the company has six bespoke integrations that the platform team will spend a year consolidating. Platform first, applied second, governance third.

Role descriptions have to be specific enough for HR to source against

A role description that reads 'AI Engineer with experience in modern AI systems' is unhirable. HR can't source against it. We deliver role descriptions with the actual technical surface — model gateway architecture, retrieval-augmented generation systems, evaluation harnesses, prompt engineering, model deployment — and the actual seniority indicators (years of production AI, scope of prior systems, leadership experience as relevant). The descriptions look more like job postings than strategy documents because that is what the receiving organization needs.

Salary bands are similarly specific. We benchmark against current market data and provide bands per role per geography, with the variance ranges. The bands inform offer construction; the offer construction determines whether the hiring plan is fundable. Operating model design that omits salary bands forces the company to discover its budget gap during recruiting, which is the most expensive moment to discover it.

RACI covers the decisions, not the activities

Most RACI matrices we encounter list activities — 'develop AI features,' 'monitor production AI,' 'evaluate models' — and assign a responsible party to each. This is the wrong granularity. RACI should cover decisions: 'approve a new model deployment,' 'accept an eval threshold exception,' 'decommission a production system,' 'authorize a vendor model upgrade,' 'classify an AI incident severity.' Each decision has a Responsible, Accountable, Consulted, and Informed pattern.

We deliver RACI matrices covering ~40 decisions across delivery and governance, with the role-types (not individual names) responsible for each. When the company hires, the RACI tells the new hire what they decide and what they consult on. Without this, decisions either don't get made or get made by whoever happens to be in the room — neither of which scales.

The tooling spine prevents twelve teams from picking twelve stacks

Without a defined tooling spine, every applied team picks its own model gateway, its own eval framework, its own observability stack, and the company ends up with a fragmented AI surface that can't be operated coherently. The spine specifies the chosen platforms and the patterns for integrating with them. Teams build on the spine; they don't get to bypass it without explicit governance approval.

The spine is opinionated by design. The right number of model gateways is one. The right number of eval frameworks is one (with extension points for domain-specific evals). The right number of observability stacks is one. Standardization on the platform is what makes governance possible; without it, governance becomes a per-team negotiation.

Budget envelopes turn the operating model from aspiration to reality

Operating models without budget are slide decks. We deliver operating model design with a 24-month budget envelope: headcount cost (fully loaded), platform and tooling cost, training and certification, vendor and inference spend, and contingency for scope expansion. The CFO can see the total ask. The CEO can see the trade-off against other initiatives. The decision to fund the operating model becomes legible.

When the budget envelope is tighter than the operating model requires, we explicitly de-scope rather than ship a model that can't run within budget. Cutting a wave-2 hire, deferring the governance function, downsizing the platform footprint — each is a documented trade-off with its consequences. The receiving organization gets choices, not aspirations.

We had two prior 'AI strategy' decks before we engaged for the operating model. The decks looked impressive in the boardroom. They didn't help our HR team source a single candidate or our CTO procure a single platform. The operating model deliverable was specific enough that we made fifteen hires and three platform decisions in the first quarter. Specificity was the difference.

— Chief Operating Officer, mid-market enterprise

Frequently asked

Why do most operating model deliverables fail to land? +

Because they stop at the org chart. The deliverable looks rigorous in the boardroom and doesn't help HR source candidates, the PMO sequence work, or the platform team procure tools. Real operating model design specifies enough — actual role descriptions with salary bands, RACI covering actual decisions, named tooling choices with rationale — that the receiving organization can act on it within weeks.

How is the AI hiring plan sequenced? +

Three waves. Wave 1: platform engineers who stand up model gateway, retrieval, observability. Wave 2: applied engineers who build customer-facing AI features against the platform. Wave 3: governance and operations — eval owner, governance chair, model risk function as it scales. Hiring applied before platform is the most common and expensive mistake; the applied engineers write one-off integrations that the platform team spends a year consolidating later.

What's the right granularity for RACI? +

Decisions, not activities. 'Approve new model deployment,' 'accept eval threshold exception,' 'decommission a production system,' 'authorize a vendor model upgrade,' 'classify an AI incident severity.' Each decision gets Responsible, Accountable, Consulted, Informed roles. We deliver RACI matrices covering ~40 decisions across delivery and governance. New hires read the RACI to understand what they decide and what they consult on.

What is the tooling spine and why is it opinionated? +

The named platforms and integration patterns the AI function builds on — model gateway, eval framework, observability, vector retrieval, model risk management tooling, identity. Opinionated by design: one model gateway, one eval framework, one observability stack. Standardization is what makes governance possible. Without a spine, every applied team picks its own stack and the result is fragmented surface that can't be operated coherently.

Are salary bands really part of operating model design? +

Yes. Without salary bands, the receiving company discovers its budget gap during recruiting — the most expensive moment. We benchmark against current market data and provide bands per role per geography. Salary bands inform offer construction; offer construction determines whether the hiring plan is fundable. Operating model design that omits this forces a downstream re-scoping conversation that should have happened during design.

How is budget handled in the operating model? +

A 24-month budget envelope: fully-loaded headcount cost, platform and tooling cost, training, vendor and inference spend, contingency. The CFO sees the total ask; the CEO sees the trade-off against other initiatives. When the envelope is tighter than the model requires, we de-scope explicitly — cutting a wave, deferring governance, downsizing the platform — with documented trade-offs. Operating models without budget are slide decks.