GCP Cloud Adoption Framework: Lead Theme — Leadership & Governance, Mobilizing Teams, Cross-Functional Collaboration, and a Cloud Operating Model

In a nutshell

Every enterprise cloud programme eventually hits the same wall, and it is almost never a technical one. The VMs migrate fine; the pipelines run. What stalls the programme is the organization: nobody actually owns the platform, finance has no idea what it costs, security shows up two weeks before launch, and the whole thing quietly depends on one enthusiastic person who might change jobs next quarter. Lead is the Cloud Adoption Framework theme that measures exactly this — whether your people and your leadership are structured, mandated, and motivated to adopt the cloud well. Where the Learn theme asks “are our people skilled enough?”, Lead asks a different question: “does the organization have the mandate, the teams, and the operating model to actually move — and to keep moving after the champion leaves?”

A mental model that makes it click: Lead is the difference between a pickup game and a real football club. A pickup game can have talented players (skills — that is the Learn theme), but it has no owner funding it, no manager, no tactics everyone plays, and nobody accountable when it falls apart. A real club has an owner who funds and backs it (the executive sponsor), a coaching staff that sets the system the whole squad plays (the Cloud Center of Excellence and the operating model), specialists who train together instead of blaming each other across the white lines (cross-functional collaboration — reliability, security, and finance embedded in the team), and rules of the game that apply to everyone automatically (governance, encoded as guardrails rather than refereed play-by-play). Lead is how you turn a room full of good players into a club that can win a league — and, crucially, keep winning after the star striker transfers out.

Concretely, Lead has four moving parts, and this lesson takes each in turn: leadership and governance (a clear mandate plus enforceable guardrails), mobilizing teams (a CCoE and the platform-versus-product team split), cross-functional collaboration (shared accountability across dev, ops, security, and finance), and executive sponsorship with a cloud operating model (the durable system that makes all of it outlive any single champion). Like every CAF theme, each part is rated Tactical → Strategic → Transformational, and the entire point of the theme is to move up that scale on purpose rather than by luck.

Level: Advanced (with a beginner-friendly on-ramp) · Time: ~40 min

One-sentence walkthrough: Read left → right — a named executive sponsor supplies the mandate and budget (1); leadership and governance encode the non-negotiables as guardrails that inherit down the Resource Manager hierarchy (2–3); a Cloud Center of Excellence mobilizes a platform team and product teams behind a self-service paved road (4); SRE, DevSecOps, and FinOps become shared accountability embedded in those teams (5); and a documented target operating model plus a standing Cloud Business Council institutionalize the whole thing so it survives re-orgs and departures (6) — maturing Lead from Tactical → Strategic → Transformational.

Prerequisites. This is part 3 of the Google Cloud Adoption Framework series and assumes you have met the framework’s shape — the four themes, the three maturity phases, and how gaps become funded epics. New to CAF? Read the CAF overview & maturity model first, then the previous part, the Learn theme, because skills gate everything Lead is about to build. It also helps to know GCP’s resource hierarchy — Organization → Folder → Project — and IAM basics, since governance in the Lead theme is built directly on top of them. No hands-on GCP access is required: this is a leadership, organization, and operating-model lesson, not a console lab.

After this lesson you’ll be able to:

• Explain what the Lead theme measures and how it differs from Learn, Scale, and Secure — in your own words.
• Design a Resource Manager hierarchy that acts as a governance backbone, and turn a business risk into a policy statement enforced by an Organization Policy constraint.
• Charter a Cloud Center of Excellence that enables rather than gatekeeps, and split platform from product teams using a clear team topology.
• Embed cross-functional collaboration (SRE, DevSecOps, FinOps) as measurable shared accountability instead of a slogan.
• Codify a target operating model and run a governance cadence that keeps cloud moving whether or not any single champion is in the room.
• Place your own organization on the Tactical → Strategic → Transformational scale for Lead and name the next epic that moves it up a phase.

Where this fits

The Google Cloud Adoption Framework is built on four themes — Learn, Lead, Scale, and Secure — each assessed against three maturity phases: Tactical, Strategic, and Transformational. Together these form the Cloud Maturity Scale, and the framework turns your position on that scale into a concrete program of adoption expressed as epics (discrete, ownable bodies of work). Lead is the theme that asks a deceptively simple question: is the organization, and specifically its people and its leadership, structured and motivated to adopt the cloud? Where Learn measures the quality and scale of your skilling, Lead measures the mandate — the extent to which IT teams are backed by leadership to migrate to the cloud, and the degree to which those teams are themselves cross-functional, collaborative, and self-motivated. This article goes deep on the four sub-components that make up Lead: leadership and governance, mobilizing teams, cross-functional collaboration, and executive sponsorship with a cloud operating model.

Leadership and governance

What it is

In the Lead theme, “leadership and governance” is the pairing of two things the framework treats as inseparable: a clear, top-down mandate to adopt the cloud, and a governance model that channels that mandate into enforceable guardrails without throttling delivery. Leadership sets direction and removes obstacles; governance encodes the non-negotiables — security, cost, compliance, residency — as policy that applies automatically as the estate grows. On Google Cloud, the substrate for that governance is concrete and architectural, not merely procedural: the Cloud Resource Manager hierarchy of Organization → folders → projects, on which IAM allow/deny policies and Organization Policy constraints are inherited from parent to child.

Why it matters

The Adoption Framework is explicit that maturity in Lead is the difference between cloud as a series of disconnected experiments and cloud as a strategic capability. At Tactical maturity, individual workloads exist but there is no coherent plan tying them together — wins are quick, but there is no provision for scale. The thing that closes that gap is leadership that has decided, publicly and with budget attached, plus governance that makes the right thing the easy thing. Without enforceable governance, every project re-litigates the same decisions (which region? which encryption? who can grant Owner?), drift accumulates, and the first audit or cost spike erases the credibility of the whole programme. Leadership without governance is enthusiasm; governance without leadership is a binder nobody enforces. Lead requires both.

How to do it well

• Anchor governance to the resource hierarchy, not to documents. Decide your folder taxonomy first — by environment (prod/nonprod), by business unit, or both — because that hierarchy becomes the inheritance boundary for every policy you will ever write. A folder is “a policy inheritance point for allow, deny, and organization policies.”
• Write the policy as intent first, then enforce. Borrow the discipline of business risk → policy statement → control. Name the risk a leader actually cares about (“customer data must not leave the EU”), state it in plain language, then implement it as an Organization Policy constraint (gcp.resourceLocations) — never the other way around.
• Centralize policy, delegate enforcement. A small governance body owns the strategy and the org-level constraints; platform and application teams operate within them. Leadership’s job is to grant that body explicit authority and air cover.
• Prefer guardrails over gates. Use deny by default with explicit exceptions at the org node, and let teams move freely inside the guardrail. Organization Policy constraints (e.g. restricting external IPs, disabling default service-account key creation, pinning allowed regions) are guardrails that scale; manual review boards are gates that don’t.

Concrete artifacts, decisions, and GCP tools

The single most consequential decision here is the resource hierarchy, because IAM and Organization Policy both inherit down it. Get the folder taxonomy right and governance becomes a property of where a project lives; get it wrong and you will be re-binding IAM project-by-project forever.

Worked example: a business risk becomes an enforced guardrail

The four bullets above are the theory; here is the discipline made concrete. Take one risk a leader genuinely cares about — “customer data must not leave the EU” — and walk it all the way down from a sentence in a boardroom to a control that enforces itself.

1. Business risk (plain language). Customer PII processed by the customer-portal workloads must be stored and processed only in EU regions — a data-residency obligation the CISO and the regulator both care about.
2. Policy statement. Every project under the portal folder may create resources only in EU locations.
3. Control (an Organization Policy constraint). Bind the gcp.resourceLocations list constraint at that folder node so it inherits to every project beneath it — current and future:

# eu-residency.yaml — applied at the portal folder node
name: folders/FOLDER_ID/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:eu-locations

# Apply the constraint (it inherits to every project in the folder)
gcloud org-policies set-policy eu-residency.yaml

# Verify the *effective* policy on a child project before you trust it
gcloud org-policies describe gcp.resourceLocations \
  --project=PROJECT_ID --effective

Now a gcloud compute instances create targeting us-central1 under that folder fails at create time with a policy violation, while europe-west1 succeeds — and the guardrail scales automatically to every current and future project in that branch, with no review board in the loop. That is the entire thesis of “leadership and governance”: the leader names the risk, and governance makes the compliant path the only path, by construction. (in:eu-locations is a Google-maintained value group; pin a specific set like in:europe-west1-locations when you need to be exact.)

Mobilizing teams

What it is

“Mobilizing teams” is the operational counterpart to leadership: turning a mandate into people who are organized, funded, and motivated to deliver cloud outcomes. In the Lead theme this is fundamentally about a shift from project-based thinking to product-based ownership — from temporary teams that disband at go-live to durable, accountable teams that own a service through its life. The organizational pattern Google recommends for catalysing this is a Cloud Center of Excellence (CCoE): a small, senior, cross-functional team of cloud architects, security specialists, and platform engineers that centralizes governance, advocacy, and enablement so the rest of the organization can move faster.

Why it matters

The framework’s definition of Lead literally measures “the degree to which the teams themselves are cross-functional, collaborative, and self-motivated.” You cannot reach Strategic or Transformational maturity with a workforce that treats cloud as someone else’s project. Mobilization matters because the bottleneck in most enterprise cloud programmes is not technology — it is the absence of a team that owns the platform and an operating rhythm that lets product teams self-serve. A CCoE that is staffed but powerless becomes a ticket queue; a mandate with no team to execute it becomes a slide deck. Mobilizing teams is what makes the mandate move.

How to do it well

• Stand up a CCoE, but keep it small and senior. Its job is to enable, not to operate everything. The anti-pattern is a CCoE that becomes a gatekeeping bottleneck; the goal is a CCoE that builds golden paths and then gets out of the way.
• Split the platform from the products. A dedicated platform team owns the landing zone, shared services, and the paved road (Terraform modules, base images, CI/CD templates). Product teams consume that road and own their workloads end to end — the “you build it, you run it” model.
• Fund teams, not projects. Persistent product ownership requires persistent funding. Move from capitalising one-off migrations to funding standing teams measured on outcomes.
• Make self-service the default. Mobilization is real when a product team can get a compliant, fully-governed project without filing a ticket. Build that with project factory automation (Terraform project-factory module) feeding landing-zone folders, so every new project is born inside the guardrails.

Concrete artifacts, decisions, and GCP tools

The defining artifact is the CCoE charter — who is on it, what authority it holds, and crucially what it does not do. The defining capability is self-service project vending, because it is the proof that the platform team has productized governance instead of administering it by hand.

Cross-functional collaboration

What it is

Cross-functional collaboration is the explicit requirement, called out in the Lead theme, for shared accountability for business outcomes across the boundaries that normally silo an enterprise: development, operations, security, networking, finance, compliance, and the business itself. In practice it means embedding the disciplines that used to throw work over the wall — security (DevSecOps), operations (SRE), and cost (FinOps) — directly into the teams that build, and giving them a shared definition of success.

Why it matters

The framework’s hallmark of the Transformational phase is a culture of experimentation and innovation sponsored consistently across the C-suite. That culture is impossible when security is a late-stage gate, ops is a separate kingdom, and finance only sees the bill after the fact. Collaboration matters because the cost of a siloed handoff compounds: the security review that lands two weeks before launch, the production incident nobody owns, the budget overrun discovered at month-end. Shared accountability replaces sequential handoffs with concurrent ownership, which is the only way to combine cloud’s velocity with an enterprise’s risk posture.

How to do it well

• Adopt SRE as the shared operations contract. Define SLOs and error budgets jointly between product and operations so reliability becomes a shared, quantified goal rather than an argument. The error budget is the collaboration mechanism: it tells everyone, objectively, when to ship and when to stabilize.
• Shift security left and make it the platform’s job. Bake controls into the paved road so collaboration is structural — Binary Authorization in the deploy pipeline, org-policy guardrails, Security Command Center findings routed to the owning team, secrets in Secret Manager — rather than a meeting.
• Make cost a first-class, shared signal (FinOps). Give every team its own slice of the billing export in BigQuery, dashboards in Looker Studio, and a budget with alerts. When engineers see their own spend in near-real-time, cost becomes an engineering input, not a finance surprise.
• Engineer collaboration through the hierarchy and groups. Use Cloud Identity groups mapped to IAM roles so cross-functional membership is explicit and auditable, and use shared folders to give security and platform the cross-cutting visibility they need.

Concrete artifacts, decisions, and GCP tools

The cross-functional KPI set is where this becomes measurable:

Executive sponsorship and a cloud operating model

What it is

This sub-component is the apex of the Lead theme. Executive sponsorship is the active, visible, sustained backing of the cloud programme by senior leadership — and the framework is precise about what mature sponsorship looks like: at Transformational maturity, “sponsorship is comprehensive across the entire C-level to include marketing, finance, operations, HR, and more, and extends down to all levels of management.” It is not a single sign-off from the CIO; it is the whole executive layer setting the tone for a culture of experimentation. The cloud operating model is the durable system that sponsorship institutionalizes: how the platform team, product teams, the CCoE, and the governance body relate; who owns what; and how cloud practices are run enterprise-wide so the model outlives any individual project or sponsor.

Why it matters

Sponsorship is the variable that most strongly predicts whether a cloud programme stalls at Tactical or progresses. Money, mandate, and the authority to break ties all flow from it. But sponsorship is fragile and personal — re-orgs and departures can evaporate it overnight. The operating model matters because it is what converts a sponsor’s energy into a system that persists: explicit ownership, funding mechanisms, decision rights, and a governance cadence that keep cloud running whether or not any one champion is in the room. The framework’s whole arc — Tactical → Strategic → Transformational — is really the maturation of the operating model from “a few sponsored experiments” to “the default way the enterprise builds.”

How to do it well

• Secure sponsorship that owns outcomes, not attendance. A real sponsor holds a line item, sets the strategic objectives the programme is measured against, and personally clears the largest blockers (procurement, compliance, headcount). Give them a one-page executive scorecard — migration progress, DORA metrics, cost vs. budget, posture score — so their backing is anchored in data.
• Codify the operating model explicitly. Document the target operating model (TOM): the CCoE, the platform team, product teams, and the governance body, with a RACI across landing zone, security, cost, and delivery. Ambiguity about ownership is where velocity dies.
• Run a governance cadence, not a governance project. A standing Cloud Business Council (sponsor + CCoE + platform + security + finance leads) on a regular rhythm to review the scorecard, arbitrate exceptions, and re-prioritize the epic backlog. Governance is a loop, not a launch.
• Tie the model to the program of adoption. The operating model exists to deliver the framework’s epics; make epic ownership and funding explicit so the model has a concrete output to point at.

Operating-model components and ownership

Maturing the operating model across the Cloud Maturity Scale

Real-world enterprise scenario

Meridian Freight Group is a fictional logistics and supply-chain company: ~14,000 employees, ~₹9,800 crore in revenue, headquartered in Pune with operations across India, the EU, and the US. Their estate is a mix of on-prem SAP, a fleet-telematics platform, and a sprawl of “shadow” cloud projects created by individual teams with personal billing accounts. A Google Cloud maturity assessment scores them Tactical on Lead: real workloads exist, but there is no mandate, no central team, no governance, and finance has no idea what cloud actually costs. The board has approved a three-year goal to reach Strategic maturity. Here is how they apply each sub-component of Lead.

Leadership and governance. The CTO, Ananya Rao, secures a board-level mandate and becomes the executive sponsor with a dedicated three-year budget line. The first artifact is a one-page cloud charter signed by the CEO. The CCoE then designs the Resource Manager hierarchy: a single Organization resource backed by Cloud Identity, with top-level folders prod, nonprod, and shared, and second-level folders per business unit (fleet, sap, customer-portal, data-platform). At the org node they enforce Organization Policy constraints: gcp.resourceLocations restricted to in:eu-locations and in:asia-south1 to satisfy EU residency for customer data, compute.vmExternalIpAccess denied by default, and iam.disableServiceAccountKeyCreation enabled. IAM is group-based via Cloud Identity, with Owner removed from all human users above the project level. The shadow projects are migrated under the Organization and brought into the hierarchy within the first quarter.

Mobilizing teams. Meridian charters a 9-person CCoE (2 architects, 2 security, 3 platform engineers, 1 FinOps lead, 1 program manager) reporting to Ananya. The platform engineers build a landing zone using Cloud Foundation Fabric and a Terraform project-factory pipeline running on Cloud Build with state in a dedicated seed project. The headline win: a product team now requests a new environment through a pull request, and a compliant, fully-governed project lands in the correct folder — with budgets, baseline IAM, logging sinks, and VPC attachment — in under 30 minutes, versus the previous ~3-week ticket cycle. Three pilot product teams (fleet-telematics, customer-portal, data-platform) are stood up as standing, funded teams that own their services in production.

Cross-functional collaboration. Each pilot team embeds the three disciplines. SRE: the customer-portal team defines a 99.9% availability SLO in Cloud Monitoring with an explicit error budget; when the budget burns, feature work pauses by prior agreement between product and ops. DevSecOps: Binary Authorization is wired into Cloud Deploy so only attested images reach production, Security Command Center Premium routes findings to the owning team, and all secrets move to Secret Manager. FinOps: the FinOps lead stands up billing export to BigQuery with a Looker Studio dashboard per team and a budget+alert on every project. Within two quarters, 100% of projects have a budgeted owner, and engineers see their own spend daily.

Executive sponsorship and the operating model. Ananya chairs a monthly Cloud Business Council (sponsor, CCoE lead, platform lead, security lead, FinOps lead, plus the SAP and customer-portal product owners) that reviews a one-page executive scorecard and arbitrates org-policy exceptions. The CFO and the COO join the council within six months — sponsorship widening beyond IT, exactly as the Transformational phase describes. The target operating model is documented with a RACI: CCoE owns guardrails, platform owns the paved road, product teams own build-and-run, FinOps owns cost governance. The model is tied directly to the program of adoption, with each epic (e.g. “migrate fleet-telematics”, “stand up the EU-resident data platform”) assigned a named owner and funding.

Measurable outcome (12 months). A re-assessment moves Meridian from Tactical to Strategic on Lead. Concretely: shadow projects eliminated (from ~40 ungoverned projects to 0); new-environment provisioning down from ~3 weeks to under 30 minutes; 100% of cloud spend now under a budget with a named owner; cloud cost variance to forecast inside ±8%; DORA lead-time for the three pilot teams down ~60%; and a Security Command Center posture score that the council can now track as a trendline rather than discover at audit.

Deliverables & checklist

• Cloud charter signed by the executive sponsor, with a named budget line.
• Identified executive sponsor(s) and a plan to widen sponsorship across the C-suite.
• Resource Manager hierarchy design (Organization → folders → projects) with the folder taxonomy fixed.
• Organization Policy baseline (residency, external-IP, service-account-key, allowed services) defined as policy statements and enforced as constraints.
• IAM / group-based access model with least privilege and Owner removed above project scope.
• CCoE charter — membership, authority, RACI, and explicit non-goals.
• Platform team established with ownership of the landing zone and paved road.
• Self-service project-vending pipeline (project factory) proven end to end.
• Cross-functional disciplines embedded: SLOs/error budgets (SRE), pipeline security (DevSecOps), per-team budgets (FinOps).
• Target operating model (TOM) documented with a RACI across landing zone, security, cost, and delivery.
• Cloud Business Council chartered with a regular cadence and an executive scorecard.
• Program of adoption expressed as epics, each with a named owner and funding.
• Lead KPI baseline captured (DORA metrics, % spend with an owner, posture score, provisioning lead time).

Common pitfalls

• The CCoE becomes a bottleneck. Stood up as a central approval gate, it turns into a ticket queue that teams route around — re-creating the shadow IT it was meant to end. Avoid it: charter the CCoE to enable (golden paths, self-service vending) and write down what it explicitly does not gatekeep.
• Sponsorship is a one-time sign-off, not active ownership. A CIO blesses the kickoff and disengages; the first procurement or compliance blocker stalls everything. Avoid it: hold the sponsor accountable for outcomes via an executive scorecard, give them tie-break authority, and deliberately widen sponsorship to the CFO/COO before the original champion can become a single point of failure.
• Governance is written before the hierarchy is designed. Teams hand-apply IAM and policy project-by-project because no folder taxonomy exists to inherit from, and the estate drifts. Avoid it: design the Resource Manager hierarchy first, then attach IAM and Organization Policy at the org and folder nodes so governance inherits automatically.
• Funding projects instead of teams. Migrations are capitalised as one-offs; the team disbands at go-live and nobody owns the service in production. Avoid it: fund standing product teams measured on outcomes, and make “you build it, you run it” the operating norm.
• Collaboration declared, not engineered. Leadership announces “DevSecOps” but security stays a late gate, ops stays a silo, and finance still sees cost only at month-end. Avoid it: make collaboration structural — controls in the paved road, joint SLOs/error budgets, and per-team billing dashboards — and measure it with shared KPIs.
• Skipping straight for Transformational. The programme tries to leap to enterprise-wide product ownership without the Strategic-phase scaffolding (a real platform team, an enforced governance MVP, a funded CCoE) and collapses under its own ambition. Avoid it: treat the Cloud Maturity Scale as a sequence — earn Strategic before you reach for Transformational.

Going deeper

This section is for the reader who already gets the four sub-components and wants the internals, the sequencing logic, and the naming traps that separate a slide-deck understanding of Lead from an operating one.

Team topologies: the shapes a cloud org actually takes

“Mobilizing teams” is vague until you name the shapes. The vocabulary that maps cleanly onto the Lead theme comes from Team Topologies, and Google’s own guidance leans on it:

• Stream-aligned teams — your product teams. Each owns a slice of business value end to end (build it, run it). They are the many; everything else exists to make them fast.
• Platform team — owns the landing zone, shared services, and the paved road as an internal product with its stream-aligned teams as customers. The paved road is its product; adoption is its metric.
• Enabling team — this is the healthy shape of a CCoE: a small, senior group that coaches stream-aligned teams up a capability curve and then withdraws. It has high influence and low headcount, and it deliberately avoids becoming a permanent dependency.
• Complicated-subsystem team — a specialist pocket (e.g. a bespoke ML platform) justified only when the subsystem genuinely needs deep, rare expertise.

The failure mode to name out loud: a CCoE that behaves like a complicated-subsystem team you must route every request through — i.e. a gate. That is an enabling team that forgot to withdraw. The interaction modes matter too: an enabling team should use facilitating (coach, then leave) and X-as-a-Service (consume the paved road self-serve), not collaboration on every project forever — permanent collaboration is just a bottleneck wearing a friendlier name.

At tens of thousands of engineers, even a healthy central CCoE saturates. The Transformational shape is federated / hub-and-spoke: a small central platform team and CCoE own the paved roads and the standards; embedded “cloud champions” (a thin enabling layer) in each business unit run local enablement and design reviews against the central standard. The center measures paved-road adoption; the spokes measure local time-to-productivity.

Governance internals: how IAM and Org Policy actually resolve down the hierarchy

“Design the hierarchy first” is advice; here is why, mechanically — the part that trips up people who have only read the marketing:

• IAM allow bindings are additive and inherited, and you cannot subtract them lower down. A role granted at the Organization or a folder is inherited by every project and resource beneath it, and a child cannot remove it. The only way to carve out an exception below is an IAM deny policy (deny rules are evaluated before allows and win). Practical rule: grant the narrowest predefined role at the lowest node that works, and reserve deny policies for genuine “never, even for admins” cases.
• Organization Policy list constraints replace the parent by default. When you set a list constraint (like gcp.resourceLocations) on a child, it does not merge with the parent unless you set inheritFromParent: true. Forgetting this is a classic incident: a team sets an allow-list on their folder, silently discards the org’s residency list, and opens a hole. If you mean “add to what’s inherited,” you must say so.
• A deny (in either system) anywhere up the tree wins and cannot be un-denied below. This is a feature — it is how a leader guarantees a non-negotiable — but it means over-broad denies at the org node are painful to walk back.
• Enforcement is at create time, and it is not retroactive. A newly-bound constraint blocks new violating resources (with a FAILED_PRECONDITION); it does not delete resources that already violate it. This is exactly why you dry-run first: ship a dryRunSpec, watch Audit Logs for a week to size the blast radius, then flip to live enforcement. Read the merged result with gcloud org-policies describe CONSTRAINT --effective rather than reasoning about inheritance in your head.

Put together, these four facts are the real argument for the hierarchy-first rule: because policy flows down an immutable-ish inheritance shape, the topology you draw is your governance boundary. Draw it wrong and you spend forever fighting inheritance; draw it right and governance is simply a property of where a project lives.

Change management is the harder 80%

Lead is maybe 20% tooling and 80% behaviour change, and the framework’s phases are really a change-management curve. A useful lens is Kotter’s sequence, mapped onto CAF’s machinery: urgency and a guiding coalition come from the executive sponsor and the Cloud Business Council; short-term wins come from the CCoE shipping self-service vending that turns a three-week wait into thirty minutes (nothing converts skeptics like getting their environment today); and you anchor the change in the culture by making the new way the easy way — guardrails so the compliant path is also the fast path, and incentives that reward running a service well rather than heroically firefighting it.

The dominant failure mode is declaring the target operating model on a slide while leaving the incentives untouched: still funding projects (so teams still disband), still rewarding the lone hero who saves the launch (so nobody builds the boring paved road). If the reward system did not change, the operating model did not change — it was just announced.

The operating model as the durable artifact: funding and decision rights

The operating model earns its keep in two unglamorous places:

• Funding model. Moving from project/capex funding (capitalise a migration, disband the team) to product/opex funding (a standing team with a run-rate budget) is the financial expression of “fund teams, not projects.” On the cost-governance side, FinOps maturity is a ladder: visibility (billing export to BigQuery, dashboards) → showback (each team sees its spend) → chargeback (each team’s budget is theirs, with committed-use discounts and anomaly alerts). Chargeback without prior showback breeds resentment; sequence it.
• Decision rights. The single most valuable line in a TOM is the boundary between what the CCoE mandates (resource hierarchy, IAM baseline, Org Policy, tagging/labeling standard) and what it merely advises (application architecture). Write it as a RACI so it is unambiguous, and remember the one rule you cannot RACI away: accountability cannot be delegated, only responsibility can. A sponsor can delegate the work of governance to the CCoE, but remains the accountable owner of the outcome — which is exactly why the scorecard is their instrument, not the CCoE’s.

How Lead interlocks with Learn, Scale, and Secure

The four themes are not parallel silos; Lead is the one that unlocks the other three:

• Lead → Learn. Sponsorship funds the learning program and the certification budget; a mandate is what lets the CCoE requisition Skills Boost seats and protected study time.
• Lead → Scale. The platform team and the paved road that Scale productizes are paid for and staffed by decisions made in Lead. No mandate, no standing platform team, no repeatable Scale.
• Lead → Secure. The guardrails Secure depends on — Org Policy, IAM baseline, VPC Service Controls, Security Command Center — are mandated and enforced by Lead’s governance body. This is why pouring money into Secure tooling while Lead is still Tactical fails: the tools get bought but misgoverned, misconfigured, and alert-fatigued because no one has the authority to make them stick. The gating logic runs Learn → Lead → Scale → Secure: skills are the precondition, sponsorship unlocks the funding and mandate, those two make repeatable Scale possible, and only a skilled, sponsored, scaled org can make Secure continuous rather than a bolt-on. The operating-model & epics lesson treats the epic backlog that carries all of this as a first-class execution artifact.

Naming and scope caveats (2026)

• “Operating model” is overloaded. In this lesson target operating model and cloud operating model mean the same durable system (teams + ownership + funding + governance cadence); some orgs also have an enterprise-wide TOM that predates cloud — keep the scope explicit so a strategy doc doesn’t confuse the two.
• Every hyperscaler names its leadership pillar differently. Google’s CAF folds leadership into the Lead theme; AWS’s CAF splits similar concerns across its People and Governance perspectives; Azure’s CAF uses Strategy / Plan / Organize / Govern / Manage. The ideas rhyme but the boundaries and phase names do not map verbatim — don’t cross-quote definitions in a multi-cloud shop.
• CAF is not the org chart. The Lead theme prescribes team topologies and decision rights, not reporting lines. A CCoE can be a virtual team drawn from several departments; forcing it onto the HR org chart is a common way to make it political and slow.
• Sponsorship is an accountability, not a delegable role. You can add sponsors and widen the coalition, but “we delegated sponsorship to a steering committee” is usually how ownership quietly evaporates. Name a single accountable executive, then widen the coalition around them.

Practice challenges

Work these top to bottom — they escalate from “can you name the model” to “can you operate it.” Try each before opening the solution.

1. (Beginner) Name the parts. From memory, name the four sub-components of the Lead theme and the three maturity phases. Then, in one sentence each, describe what evidence would put an org at Tactical versus Transformational on Lead.

<details><summary>Solution</summary>

Sub-components: leadership & governance, mobilizing teams, cross-functional collaboration, executive sponsorship + the operating model. Phases: Tactical, Strategic, Transformational. Tactical Lead = one champion with ad-hoc budget, no central team, manual per-project governance, siloed handoffs. Transformational Lead = sponsorship across the whole C-suite and down through management, product teams with a mature CCoE, continuous automated governance, and shared accountability as the culture. Why: you cannot place an org on the maturity scale until you can name the axes and picture both ends. </details>

2. (Beginner) Sponsorship or sign-off? A CIO approves the cloud kickoff in a town hall, is thanked warmly, then delegates it entirely and moves on. Six weeks later a procurement blocker stalls the landing zone for a month. Was that real executive sponsorship? What was missing?

<details><summary>Solution</summary>

No — that was a sign-off, not sponsorship. Real sponsorship owns outcomes, not attendance: a budget line, the authority to break ties (like clearing that procurement blocker in days, not weeks), and a scorecard the sponsor is accountable to. What was missing: sustained ownership, tie-break authority, and a plan to widen sponsorship (CFO/COO) so one person isn’t a single point of failure. Why: active, owned sponsorship is the single variable that most predicts whether a programme escapes Tactical — a one-time blessing is the classic stall. </details>

3. (Intermediate) Design the governance backbone. You are setting up a new Organization for a company with prod and nonprod environments across three business units (fleet, portal, data). Sketch a folder taxonomy that lets you (a) enforce EU residency for portal only, and (b) apply a no-external-IP rule everywhere. Where do you attach each policy, and why there?

<details><summary>Solution</summary>

A two-level taxonomy — a common shape is a BU folder per unit, each containing prod/nonprod, plus a shared folder for host/logging projects:

Organization                         ← attach compute.vmExternalIpAccess (denyAll) HERE
├── fleet/        (prod, nonprod)
├── portal/       (prod, nonprod)     ← attach gcp.resourceLocations = in:eu-locations HERE
├── data/         (prod, nonprod)
└── shared/       (logging, networking host projects)

Attach no-external-IP at the Organization node so it inherits to every project everywhere; attach EU residency at the portal folder only, so it scopes to exactly those projects and nothing else. Why: the hierarchy is the governance boundary — you scope a policy by choosing the node you bind it to, which is precisely why you design the taxonomy before you write policy. </details>

4. (Intermediate) Risk → constraint. Your security lead’s stated risk: “service-account keys are our biggest leak vector; nobody should be able to create them.” Write the Organization Policy that enforces this org-wide, and give the one command to apply it.

<details><summary>Solution</summary>

The boolean constraint iam.disableServiceAccountKeyCreation, enforced at the org node:

# no-sa-keys.yaml
name: organizations/ORG_ID/policies/iam.disableServiceAccountKeyCreation
spec:
  rules:
  - enforce: true

gcloud org-policies set-policy no-sa-keys.yaml

Now any attempt to create a user-managed SA key under the Organization is denied, and teams move to keyless auth (Workload Identity Federation, attached service accounts) instead. Why: this is “policy as intent, then enforce” in one move — the leader names the risk, and a single inherited boolean constraint makes the risky action impossible by construction, org-wide. </details>

5. (Advanced) Charter a CCoE that won’t gatekeep. Write the three things a CCoE charter must contain to avoid becoming the ticket-queue bottleneck, and name the one thing it must explicitly not do.

<details><summary>Solution</summary>

Must contain: (1) Mandate + decision rights — what it mandates (resource hierarchy, IAM baseline, Org Policy, tagging standard) versus what it only advises (application architecture); (2) Its product is the paved road — self-service golden assets (project factory, Terraform modules, base images), not manual approvals; (3) Explicit non-goals + a self-service SLA, and it is measured on paved-road adoption %, not tickets closed. Must not do: be a manual approval gate on every new project or deploy — that recreates the shadow IT it exists to end. Why: a CCoE stood up as a central gate becomes a queue teams route around; charter it as an enabling team that makes the compliant path the fast path. </details>

6. (Advanced) The champion left. Your only executive sponsor takes another job; within a quarter the programme has stalled — budget disputes, no one arbitrating org-policy exceptions, product teams drifting. What in the operating model should have prevented this, and what do you do now?

<details><summary>Solution</summary>

The operating model should have made sponsorship a system, not a person: (1) a documented target operating model with a RACI, so ownership of landing zone / security / cost / delivery didn’t live in one head; (2) a standing Cloud Business Council (multiple leaders) as a guiding coalition, so tie-breaks and exceptions had a forum that survives one departure; (3) widened sponsorship to the CFO/COO before the champion left, so there was no single point of failure. Now: convene the Council, appoint an interim accountable sponsor from it, and use the executive scorecard to re-secure a funded mandate. Why: the entire reason to codify an operating model is that sponsorship is fragile and personal — the model is what makes cloud outlive any one champion. </details>

Common beginner mistakes

These are conceptual misreadings of the Lead theme (distinct from the organizational anti-patterns in Common pitfalls above) — the misconception, why it’s wrong, and the right mental model.

• “Lead just means getting a budget approved.” A budget is table stakes; Lead is mandate plus teams plus collaboration plus a durable operating model. Right model: Lead is an operating system for the organization, not a one-time funding event.
• “Governance means a review board that approves changes.” On GCP governance is architectural — guardrails that inherit down the resource hierarchy and enforce themselves at create time. Right model: guardrails (automatic, scalable) over gates (manual, bottleneck).
• “The CCoE is the team that runs everything in the cloud.” It’s a small enabling team that builds paved roads and then withdraws; product teams run their own workloads. Right model: enable and coach, don’t operate everything.
• “Executive sponsorship = the CIO signed off.” Sponsorship is active, owned, scorecard-anchored, and deliberately widening across the C-suite; a one-time sign-off is the classic Tactical stall. Right model: a sponsor owns outcomes and tie-breaks, not attendance.
• “Cross-functional collaboration is a reporting-line change.” It’s shared accountability engineered into the platform and measured with shared KPIs (SLOs, DORA, % spend with an owner) — not a new box on the org chart. Right model: collaboration you build in, not announce.
• “We should jump straight to Transformational.” Transformational needs the Strategic scaffolding first — a real platform team, a funded CCoE, an enforced governance MVP. Right model: the maturity scale is a sequence; earn Strategic before Transformational.
• “Lead is a separate track from the other themes.” Lead funds Learn, mandates Secure, and pays for the platform Scale productizes. Right model: Lead is the theme that unlocks the other three — treat it as the keystone, not a silo.

Glossary

• Lead (theme) — the CAF theme that measures whether an organization’s people and leadership are structured, mandated, and motivated to adopt the cloud; its four sub-components are leadership & governance, mobilizing teams, cross-functional collaboration, and executive sponsorship + operating model.
• Cloud Adoption Framework (CAF) — Google’s model for assessing how ready an organization is to adopt Google Cloud, across four themes, each rated at one of three maturity phases.
• Maturity phase — the rating a theme gets: Tactical (ad hoc, per-project, heroics), Strategic (planned, funded, org-wide), or Transformational (continuous, automated, measured, sponsored across the C-suite).
• Cloud Maturity Scale — the overall grid of four themes × three phases; real orgs come out “jagged” (strong on one theme, weak on another), and the jag is what tells you where to invest next.
• Epic — a scoped, funded body of work (named owner + key results + deadline) that closes one maturity gap; shipping it moves a theme up a phase. The program of adoption is the epic backlog.
• Executive sponsor — the senior leader who owns the cloud programme’s outcomes: a budget line, tie-break authority, and accountability to a scorecard. Mature sponsorship widens across the whole C-suite.
• Executive scorecard — the one-page instrument (migration progress, DORA metrics, cost vs. budget, posture score) that anchors the sponsor’s backing in data.
• Cloud charter — the short, sponsor-signed document that states the mandate, scope, and budget for cloud adoption; the first artifact of leadership.
• Leadership and governance — the inseparable pairing of a top-down mandate with an enforceable governance model that encodes non-negotiables as guardrails.
• Cloud Resource Manager — the GCP service that provides the Organization → folder → project hierarchy; the inheritance boundary for IAM and Organization Policy.
• Organization / folder / project — the three levels of the resource hierarchy: the Organization is the root (one per company), folders group by team/environment and are policy inheritance points, and projects are the billing-and-blast-radius unit that holds resources.
• IAM allow policy — additive role bindings that grant access; inherited down the hierarchy and cannot be subtracted at a lower node.
• IAM deny policy — explicit deny rules evaluated before allow bindings; the only way to carve out an exception below an inherited grant.
• Organization Policy (Org Policy) — the service that sets configuration guardrails as constraints inherited down the hierarchy; governs what may exist. Boolean constraints are on/off (e.g. iam.disableServiceAccountKeyCreation); list constraints allow/deny values (e.g. gcp.resourceLocations) and replace the parent unless inheritFromParent: true.
• Guardrail vs gate — a guardrail is an automatic, inherited policy that lets teams move freely inside it (scales); a gate is a manual approval step (bottlenecks). Lead prefers guardrails.
• Cloud Center of Excellence (CCoE) — the small, senior, cross-functional team that owns the cloud operating model, builds paved-road assets, and enables the rest of the org; healthiest as an enabling team that coaches and withdraws.
• Platform team — the team that owns the landing zone, shared services, and the paved road as an internal product consumed by product teams.
• Product team (stream-aligned team) — a durable team that owns a slice of business value end to end — “you build it, you run it.”
• Enabling team — a Team Topologies pattern for a small, high-influence team (the healthy CCoE shape) that coaches other teams up a capability curve, then steps back.
• Team topology — the deliberate shape of teams and their interactions (stream-aligned, platform, enabling, complicated-subsystem); the vocabulary for “mobilizing teams.”
• Paved road — an opinionated, self-service platform asset that makes the secure/compliant path the easy path; the platform team’s core product.
• Project factory / project vending — automated, self-service provisioning of new, already-compliant projects (via Terraform/Infrastructure Manager) instead of clicking them by hand.
• Landing zone — the pre-built, governed GCP foundation (Organization → folder → project hierarchy, Shared VPC, IAM baseline, Org Policy guardrails, logging, billing export) that a maturing org’s paved road produces.
• “You build it, you run it” — the operating norm where the team that builds a service also operates it in production, replacing throw-it-over-the-wall handoffs.
• Cross-functional collaboration — shared accountability for outcomes across dev, ops, security, networking, finance, and the business, engineered into the platform rather than announced.
• SRE (Site Reliability Engineering) — the discipline that makes reliability a shared, quantified goal via SLOs and error budgets.
• SLO / error budget — a Service Level Objective is the reliability target; the error budget is the allowed unreliability, and burning it is the objective signal to stop shipping features and stabilize.
• DevSecOps — embedding security controls into the build/deploy pipeline (e.g. Binary Authorization, Secret Manager, SCC findings routed to owners) so security is structural, not a late gate.
• Binary Authorization — a GCP deploy-time control that admits only attested/signed container images to production.
• FinOps — making engineers cost-aware and closing a showback/chargeback loop on cloud spend, using billing export to BigQuery, dashboards, budgets, and committed-use discounts.
• Showback / chargeback — showback shows each team its spend; chargeback makes that spend the team’s own budget. Sequence showback before chargeback.
• DORA metrics — the four DevOps delivery metrics (deployment frequency, lead time for change, change-failure rate, time to restore) used as lagging proof that collaboration turned into delivery velocity.
• Target operating model (TOM) / cloud operating model — the documented, durable system of teams, ownership, funding, decision rights, and governance cadence that institutionalizes cloud so it outlives any one champion.
• Cloud Business Council — the standing governance forum (sponsor + CCoE + platform + security + finance leads) that reviews the scorecard, arbitrates exceptions, and re-prioritizes the epic backlog on a cadence.
• Decision rights — the explicit boundary between what the CCoE mandates and what it only advises, written into the RACI; accountability can’t be delegated, only responsibility.
• RACI — a responsibility matrix (Responsible, Accountable, Consulted, Informed) used to make ownership across landing zone, security, cost, and delivery unambiguous.
• Cloud Identity / groups — the corporate identity backbone; mapping groups to IAM roles makes cross-functional access explicit, auditable, and least-privilege.
• Security Command Center (SCC) — Google’s centralized security and risk platform (org-level findings, posture management, threat detection) that Lead’s governance body mandates and monitors.

What’s next

With the Lead theme establishing the mandate, the teams, and the operating model, the next part of the Google Cloud Adoption Framework series turns to the Scale theme — productizing the platform and using cloud-native and automation practices to grow adoption without growing toil.