Why You Need a Governance Board
Without a governance board: anyone can change organization-level AI rules. A well-meaning engineer adds a rule that makes sense for their team but breaks 5 other teams' workflows. A tech lead removes a security rule they find inconvenient. A new hire copies rules from their previous company that conflict with the organization's architecture. The governance board prevents: unvetted changes to rules that affect the entire organization, conflicting rules across teams, and the erosion of security and quality standards.
The governance board is needed when: the organization has 50+ developers (enough that informal coordination breaks down), multiple teams share a codebase or depend on shared APIs, compliance requirements mandate formal change control (SOC 2, ISO 27001), or rule changes have caused incidents (a rule change broke the build for multiple teams). At smaller organizations: the staff engineer and tech leads can coordinate informally.
The board's scope: organization-wide rules only. Technology-specific rules are managed by technology leads. Team-specific rules are managed by teams. The board reviews only changes that affect all teams. This narrow scope keeps the board focused and prevents it from becoming a bottleneck for routine rule updates.
Board Composition and Meeting Cadence
Board members (5-7 people): principal or staff engineer (technical authority, chairs the board), 2-3 senior engineers representing major technology stacks (TypeScript, Go, Python), security engineering representative (ensures security rules are not weakened), and VP Engineering or delegate (organizational authority, tie-breaker). AI rule: 'Keep the board small. 5-7 members make decisions efficiently. Larger boards: scheduling is impossible, discussions are unfocused, and decisions are slow.'
Meeting cadence: bi-weekly for 30 minutes. Agenda: review proposals submitted since last meeting, discuss and decide (approve, reject, or request revision), and quick status update on approved changes in progress. AI rule: 'Bi-weekly 30-minute meetings. If there are no proposals: cancel the meeting. Do not meet for the sake of meeting. The board's value is in decisions, not in gathering.'
Async decision-making: for non-controversial changes (adding a new technology rule, minor wording updates), use async approval. Post the proposal in the board's Slack channel. If no objections within 48 hours: approved. Only bring controversial changes (removing a security rule, major pattern change) to the synchronous meeting. AI rule: 'Default to async. Reserve synchronous meetings for decisions that need discussion. Most rule changes are non-controversial and can be approved asynchronously.'
Most rule changes are non-controversial: adding a convention, updating a library reference, clarifying existing guidance. These do not need a meeting. Post in the board's Slack channel, wait 48 hours for objections, auto-approve if none. Reserve synchronous meetings for: removing security rules, changing architectural patterns, or resolving disagreements. This async-default approach: handles 80% of proposals without scheduling a meeting.
Proposal and Decision Process
Proposal template: anyone in the organization can propose a rule change. Template: title (concise description of the change), motivation (why is this change needed? What problem does it solve?), proposal (the specific rule text â what, why, when), impact assessment (which teams are affected? How many repos?), alternatives considered (what other approaches were evaluated? Why were they rejected?), and rollout plan (how will the change be distributed and communicated?). AI rule: 'The proposal template ensures: every change is justified, alternatives are considered, and impact is assessed before the board reviews.'
Decision criteria: the board approves changes that: improve code quality measurably (not just aesthetically), do not create undue friction for teams, are consistent with the organization's technical direction, and have a clear rollout plan. The board rejects changes that: only benefit one team (should be a team-level rule), weaken security protections, or lack justification (a change in search of a problem). AI rule: 'The board's default is to approve if the proposal is well-justified. The bar for rejection should be: this change will cause harm, not: I prefer a different approach.'
Conflict resolution: when the board cannot reach consensus, the process: the chair summarizes the positions, affected teams provide input (async or in person), the chair makes a recommendation, and the VP Engineering (or delegate) makes the final decision if the board remains split. AI rule: 'Consensus is preferred but not required. A clear decision by the chair with VP backing is better than an endless debate. Most rule decisions are not worth extended deliberation â make the call and iterate.'
A team proposes a rule change. The board meets in 2 weeks. Requests more information. Meets again in 2 weeks. Discusses but does not decide. Meets again in 2 weeks. Finally approves with modifications. Total: 6 weeks. The proposing team has already worked around the issue and no longer cares about the rule change. Decision speed is the board's most important metric. If proposals routinely take more than 2 weeks: simplify the process.
Keeping the Board Effective
Speed metric: track the time from proposal submission to decision. Target: 1 week for async decisions, 2 weeks for synchronous decisions. If proposals take more than 2 weeks: the process has too much friction. AI rule: 'The board's effectiveness is measured by decision speed. A 2-month decision cycle: means teams stop proposing changes (why bother if it takes forever?). Fast decisions with iteration are better than perfect decisions that take months.'
Relevance check: quarterly, the board reviews its own effectiveness. Questions: are proposals being submitted (if not: teams may have given up on the process)? Are decisions being implemented (if not: the board's authority is not respected)? Are the rules actually improving outcomes (if not: the board is approving the wrong changes)? AI rule: 'A board that receives no proposals: is not effective. Either the rules are perfect (unlikely), teams do not know about the process (communication problem), or teams do not trust the process (trust problem). Diagnose and fix.'
Board rotation: members serve 1-year terms with staggered rotation (2-3 members rotate each year). This prevents: groupthink (the same people making all decisions), stagnation (no new perspectives), and burnout (governance is a service, not a permanent assignment). AI rule: 'Fresh perspectives on the board: prevent the rules from calcifying. Rotating members bring: new technology expertise, different team perspectives, and renewed energy for governance work.'
The board has received zero proposals in 3 months. This does not mean the rules are perfect â it means one of: teams do not know the proposal process exists (communicate it), teams tried and found the process too burdensome (simplify it), or teams have given up because previous proposals were rejected or ignored (rebuild trust). A healthy board receives 2-4 proposals per month. Investigate if proposal volume drops to zero.
Governance Board Summary
Summary of the AI Governance Board setup and operating model.
- Scope: organization-wide rules only. Technology and team rules managed separately
- Composition: 5-7 members. Principal/staff chair, tech reps, security, VP Engineering
- Cadence: bi-weekly 30 min. Cancel if no proposals. Async for non-controversial changes
- Proposals: anyone can propose. Template: motivation, specific rule, impact, alternatives, rollout
- Decisions: approve if well-justified. Reject if harmful. Default to approve with iteration
- Speed: 1 week async, 2 weeks synchronous. Track proposal-to-decision time
- Quarterly review: proposals submitted? Decisions implemented? Outcomes improving?
- Rotation: 1-year terms, staggered. Prevents groupthink and burnout