Sheet 01
Reading the role
Before proposing an operating model, it is worth showing that I understood what the role is meant to accomplish. Nine themes, six measures of success, and five constraints — each one my reading of the posting, followed by what I would actually do about it and where on this site you can see it working.
What this page is based on
Everything in the “as I read it” column is my paraphrase of a public job description. Nothing is quoted, and nothing here is a statement about your organization, your systems, or the work you already have underway — I have no visibility into any of it. Where I have read something into the posting that is wrong, that is worth knowing early, and it is exactly the kind of thing the first conversation should correct.
How the role reads to me
Nine themes. For each one: what I understand the role to be asking for, what I would actually do about it, and the sheet on this site where you can see that in operation rather than described.
- RT-01
A practical front door
As I read it
The posting describes operating intake as the everyday entry point for AI questions, tool requests, access requests, proposed use cases, pilots, and enablement needs.
What I would do about it
One short form, published pathway timelines, and a weekly slot to work the queue. Incomplete requests come back the same day with specific questions rather than a rejection. The measure of a front door is whether people use it instead of routing around it.
Where you can see it here
- RT-02
Governance operations and a defensible record
As I read it
Coordinating committee agendas, review materials, decisions, action items, ownership, and follow-up; maintaining the inventory, use-case register, decision log, exception log, and related documentation.
What I would do about it
Standing agendas built around decisions rather than status, material distributed ahead of the meeting, and records written within two days while the reasoning is still fresh. The decision log captures what was rejected and why, which is the field that makes a program defensible a year later.
Where you can see it here
- RT-03
Portfolio visibility across a decentralized firm
As I read it
Maintaining visibility into initiatives, pilots, production solutions, tools, agents, and automations across business units and shared services, and coordinating status reporting on owners, milestones, dependencies, and risks.
What I would do about it
A single register that every other view reads from, so counts on a leadership report cannot contradict the underlying records. Visibility across a decentralized firm is earned by making the register worth being in, not by requiring people to file.
Where you can see it here
- RT-04
Coordinating higher-risk reviews without owning the decision
As I read it
Coordinating reviews for higher-risk use cases — HR and recruiting, public-facing content, sensitive data, business-system actions, and autonomous or semi-autonomous agents — and escalating policy, risk, budget, security, legal, vendor, and strategic decisions to the appropriate owner.
What I would do about it
Three pathways with published expectations, and a responsibility matrix where the program manager column contains no approval authority. The program prepares the material, convenes the right people once rather than sequentially, and writes the record. The functional owner decides.
Where you can see it here
- RT-05
Framing opportunities and running pilots to a decision
As I read it
Helping teams define the business problem, document expected outcomes, identify success measures, and prepare use cases for review; tracking approved pilots, owners, timelines, outcomes, risks, and readiness.
What I would do about it
Every pilot has a charter, a baseline captured before the tool arrives, harm indicators alongside benefit measures, and a decision date on the calendar from day one. A pilot without a decision date becomes permanent by default, which is the most common failure mode in this kind of program.
Where you can see it here
- RT-06
Enablement that makes governance feel helpful
As I read it
Office hours, quick-reference materials, role-based enablement, training coordination, champion relationships, and promoting approved tools in a way that encourages voluntary adoption rather than feeling punitive.
What I would do about it
Three role-based pathways, weekly office hours with no agenda required, and a champion network with an explicit list of what champions are not responsible for. Recurring questions become published guidance on a defined loop, and the people who asked get told what changed.
Where you can see it here
- RT-07
Tool, vendor, and buy-versus-build review coordination
As I read it
Maintaining approved-tool and vendor inventory, coordinating reviews using structured criteria for security, compliance, data protection, business value, cost, maintainability, and readiness, and documenting outcomes and open questions for the decision makers.
What I would do about it
One worksheet used every time, so evaluations are comparable and the gaps are visible. The recommendation goes to the decision owner with the open questions attached rather than smoothed over — a vendor gap that stalls a pilot is information, not a failure.
Where you can see it here
- RT-08
Prompts, agents, and reusable resources
As I read it
Supporting consistent storage, discoverability, retention coordination, and ownership tracking for AI-generated artifacts, prompts, agents, and decisions, and identifying gaps, duplication, and opportunities to improve reusable resources.
What I would do about it
A prompt and agent record with a named maintainer, documented assumptions, known failure modes, and how it was tested. Reusable only counts if someone can find it and trust it, and unowned prompts rot as models change.
Where you can see it here
- RT-09
Metrics, value, and leadership reporting
As I read it
Maintaining dashboards, adoption summaries, pilot status, training activity, utilization indicators, and risk themes; tracking outcomes and realized benefits where measurable; preparing decision-support material while final decisions stay with leadership.
What I would do about it
Every number carries an evidence label — measured, estimate, self-reported, or pending validation — and the report includes a section on what is not yet known. Leadership can act on a number when they know how good it is.
Where you can see it here
Constraints that shaped this model
The posting says several things about how this role has to operate. Each one changed the design of the playbook, and two of them are the reason it looks the way it does rather than like a standard governance framework.
- 01
What the posting says
The organization is decentralized, and the posting is explicit that success depends on relationships and influence rather than formal authority.
What that means for the model
The model assumes nothing can be mandated. Intake has to be easier than the workaround, guidance has to be worth linking to, and the champion network does more work than any policy would. The first 30 days are listening for exactly this reason.
- 02
What the posting says
The role reports to the Director of Technology and escalates policy, risk, budget, security, legal, vendor, and strategic decisions to their functional owners.
What that means for the model
The responsibility matrix has no approval authority in the program manager column. Every decision record names an owner who is not the program manager. This is a coordination role with real accountability for records, rhythm, and readiness — and that distinction is drawn everywhere on this site.
- 03
What the posting says
The posting states plainly that the role does not require being an AI developer or technical expert.
What that means for the model
I am not one, and the playbook does not pretend otherwise. What I bring is the ability to turn ambiguous requirements into workflows, records, guidance, and reporting that people use — and to know which technical questions belong to Security, Data, and Risk rather than to me.
- 04
What the posting says
AI adoption is already happening across the firm, and the role is described as bringing structure and momentum to efforts underway.
What that means for the model
The lifecycle starts at Discover, not Intake. A program that behaves as though the work began the day it arrived loses the people already doing it. The first inventory is of what exists, including the informal practices that show where real demand is.
- 05
What the posting says
Existing policy, operating guidance, and responsible-use expectations are referenced as already in place.
What that means for the model
This playbook is designed to sit underneath existing policy, not to replace it. Where the demonstration shows guidance, the real version would be the organization's own — my job would be implementing, communicating, and operating it, with the functional owner approving the substance.
Measures of success
Six measures, as I read them. The third column is the one that matters: how I would know whether it was actually working, rather than whether it looked like it was. A measure nobody can check is a slogan with a number attached.
- SM-01
Stakeholders experience the program as helpful and practical rather than as a gatekeeping function.
How this playbook addresses it
Three pathways with published timelines, so most requests take the short path and everyone can see why. Office hours before review rather than only after. Requests returned with specific questions, never a bare rejection.
How I would know
Share of requests arriving through the front door rather than around it; time from intake to pathway assignment; a direct survey question on whether the program helps or blocks, reported with its response rate rather than as a clean score.
- SM-02
Initiatives, pilots, tools, vendors, agents, and decisions are visible, documented, and easier to coordinate across the firm.
How this playbook addresses it
One register that every other view derives from, with cross-referenced IDs linking use cases, pilots, decisions, exceptions, and tools. Nothing is retyped, so nothing can drift.
How I would know
Whether a leader can answer 'what are we doing with AI in this office' without calling anyone; how often duplicate efforts are found after the fact rather than before.
- SM-03
Employees have clear guidance, training pathways, approved resources, and a practical place to bring questions.
How this playbook addresses it
Role-based pathways for general employees, managers, and power users. One-page references written for someone with four minutes. A feedback loop that turns any question asked more than twice into published guidance.
How I would know
Whether people can name where to go; repeat-question rate falling as guidance improves; training completion reported as distinct people rather than seat count.
- SM-04
Pilot outcomes, adoption activity, risks, and value indicators are tracked consistently enough to support leadership decisions.
How this playbook addresses it
Baselines captured before a tool is introduced, thresholds set before results are known, and evidence labels on every figure. Estimates never stand next to measured numbers without being marked.
How I would know
Whether leadership makes a decision from the material or asks for a different version of it; the share of pilots reaching their scheduled decision date on time.
- SM-05
Higher-risk use cases are escalated to the appropriate owners before broader implementation.
How this playbook addresses it
Explicit triage triggers for employment decisions, sensitive data, automated action, and public-facing output — with the triggering answers recorded so the classification can be challenged specifically.
How I would know
Whether elevated use cases reach their owners before build rather than after; whether any reviewer says they were surprised by something already in production.
- SM-06
Reusable prompts, agents, guidance, records, and lessons learned become easier to find, maintain, and improve.
How this playbook addresses it
A prompt and agent register with named maintainers, documented failure modes, and review dates. Lessons learned captured at each pilot decision rather than at the end of the year.
How I would know
Reuse of documented prompts outside their originating team; how often a lesson from one pilot visibly changes the design of the next.
The other half of this
Reading a posting carefully is not the same as knowing an organization. Everything on this page is an interpretation made from the outside, and the playbook it points to runs on invented records. The companion to this sheet is the list of what I would need to learn before adapting any of it — and that list is deliberately longer than the playbook.