Most technology governance fails in the same way. A steering committee is stood up, it meets, it receives a status deck, and it makes no decision that would not have been made anyway. Six months later it is a standing meeting that senior people send delegates to, and the obligation it was created to meet is still being met by the two people who care most.
The failure is almost never the cadence or the tooling. It is that the charter does not say what the committee is allowed to decide, so it decides nothing, so attendance decays, so the decisions route back to whoever answered last time.
The evidence underneath this document: the technology and artificial intelligence governance operating model for the California Department of Health Care Services — an agency serving more than 13 million Medi-Cal beneficiaries — comprising three governance committees, standardized escalation paths, an OKR framework aligned to state technology strategy, and multi-horizon roadmaps across 11 critical applications, with HIPAA compliance embedded. Delivery velocity improved 40% and technical escalations fell 23%. That work was performed by Jeff Kimble as an employee of Guidehouse, in a prior role. It is not Northmark past performance.
Six questions a charter has to answer before the first meeting
A charter that does not answer all six produces a meeting rather than a committee. Write them in this order, because each one constrains the next.
- 1. What decisions belong to this body, by name. Not a subject area — a list of decision types. “Approves a change to an application’s target architecture” is a decision. “Provides oversight of the application portfolio” is a mood.
- 2. What decisions explicitly do not. The exclusions are the harder half and the reason the body stops being asked to rubber-stamp. A charter without exclusions absorbs whatever arrives.
- 3. Who has to be present for a decision to be valid. Named roles, and whether a delegate carries the authority. If a delegate does, say so; if not, the meeting that convenes without the role does not decide, and that is a rule someone will test in month two.
- 4. What arrives before the meeting, and by when. A committee that reads the material in the room is a committee that ratifies. Name the artifact and the lead time.
- 5. Where a decision goes once it is made. The record, who writes it, and who is bound by it. A decision that lives in minutes nobody reads gets remade.
- 6. What happens when this body cannot decide. Which is the escalation path, and it is the section most charters leave for later.
An escalation path terminates in a person, not a forum
Most escalation paths are a list of forums in increasing order of seniority. That is not a path, because none of the entries is obliged to answer. A path terminates when the last entry is a named role that can decide alone and cannot pass it on.
Three properties make the difference between a path that resolves and a diagram in a deck.
- A trigger, not a judgment. What condition moves an item up. “Unresolved after two cycles” is a trigger. “Significant impact” is a negotiation.
- A clock on every step. An escalation without a duration sits at whichever level is most comfortable holding it.
- A terminal decider. One role that can decide without consensus, and a written statement that the decision stands once made. Absent that, the path loops.
Standardizing the escalation paths across eleven critical applications was the change that moved the escalation number at DHCS. Escalations fell 23% — not because fewer problems occurred, but because problems that used to travel up were resolved at the level that owned them, which is what a path with a trigger and a clock does.
The cadence that survives month three
Every governance model works in month one, when the people who designed it are in the room. The test is month three, when the novelty is gone and the calendar is under pressure. Four things decide whether it survives.
- One owner per meeting, named, not a function. The owner prepares the material and holds the decision record. A meeting owned by a team is owned by nobody by month three.
- A horizon per body. Mixing a two-week delivery question and a three-year portfolio question in one room produces a meeting that always discusses the two-week question. Separate the horizons and the long one gets air.
- A standing input, not a standing agenda. The agenda should be generated by what arrived — open decisions, breached triggers, roadmap changes — rather than repeated from last time. A repeated agenda is how a committee becomes a status report.
- A rule for cancelling. If nothing arrived, the meeting does not happen, and that is written down. A body that meets with nothing to decide teaches its members that attendance is optional.
What to measure, and the two numbers worth reporting
Governance is measured badly almost everywhere, because the obvious measures — meetings held, attendance, artifacts produced — all report effort and none report effect. Two measures report effect, and both were the ones tracked at DHCS.
- Delivery velocity. If the governance model is working, work moves faster, because decisions that used to wait now have a place to be made. If a governance model slows delivery, it is administering rather than governing. Measured at DHCS: a 40% improvement.
- Escalation volume. Falling escalations mean decisions are being made where they belong. Measured at DHCS: a 23% reduction.
An OKR framework aligned to the parent organisation’s technology strategy is what keeps those two from being gamed against each other — velocity can always be bought by deciding less carefully, and escalations can always be suppressed by not raising them. Tying both to an outcome somebody outside the committee cares about is the check.
Multi-horizon roadmaps do the same job across a portfolio. Across 11 critical applications the roadmap is what makes a decision in one application visible to the other ten, which is the difference between a portfolio and eleven programs sharing a budget line.
Artificial intelligence governance belongs inside this model, not beside it
The common instinct when an AI obligation arrives is to stand up a separate AI committee. It produces a body with no delivery authority, reviewing work that a different body has already approved, and it is routed around within two quarters.
At DHCS, AI governance was a component of the same enterprise architecture rather than a parallel structure: policy standards, committee charters that name AI decisions alongside the other decisions those bodies already make, and a compliant adoption pathway a team can actually follow to get something into production. The pathway is the part that determines whether the policy is obeyed — a standard with no route to compliance is a standard people work around.
In a health agency this runs under HIPAA, which is the useful forcing function: a policy standard that cannot be stated in terms of an existing regulatory obligation is usually a preference.
Where governance stops
A governance operating model is not an authorization and does not lead to one. Northmark holds no ATO, no RMF package at any level, and nothing under FedRAMP or CMMC. A charter that implies otherwise is the fastest way to lose a reader who has carried a package through.
It is also not a headcount solution in disguise. What a model of this kind changes is where decisions are made and how long they take. If the obligation genuinely requires more people to execute it, governance will make that visible faster; it will not make it untrue.
Ask about anything in this guide.
The methods here are the ones we use. If one of them is wrong for your program, that is worth a conversation.