The committee that never decided anything

A regional municipality launched a web governance committee eighteen months before I worked with them. By the time we spoke, the committee had met eleven times. It had produced six meeting summaries, three working group proposals, and a draft terms of reference document that had been revised four times but never formally adopted.

It had not made a single binding decision about the website.

Every legitimate issue that came to the table got referred to a working group, tabled for more information, or deferred because the right person wasn't in the room. The website accrued inconsistencies, outdated content, and conflicting priorities from twelve different departments, all of which continued doing whatever they wanted because no one had the authority to say otherwise.

This is what a governance committee designed by consensus looks like. Everyone is represented, everyone has input, and nothing gets decided.

A web governance council designed to actually work looks very different. It has a small core group with real decision-making authority. It meets on a defined schedule with a defined agenda. It produces decisions, not summaries. And it has a clear process for handling the most common source of gridlock: competing priorities from departments that all believe their content is the most urgent.

Here is how to build one.

Who belongs on the council

The most common mistake in assembling a governance council is including too many people. When everyone with a stake in the website is on the council, you have a representative body, not a decision-making one. Every meeting becomes a negotiation between departmental interests. Decisions require unanimous agreement that never comes.

The council should have three to five core members, maximum. Here is who those seats belong to.

The web lead (or digital communications manager)

This person owns the operational day-to-day of the website: content standards, publishing workflow, technical coordination with developers, and vendor management. They bring the council an informed picture of what the site is doing, what's breaking down, and what requests are in the backlog. They are not the decision-maker on priorities. They are the person who makes the effects of decisions concrete and testable.

This seat is non-negotiable. Without an operational owner in the room, the council makes decisions disconnected from what's actually feasible.

A senior communications or marketing lead

Someone with authority over organizational brand, messaging strategy, and external communications. They hold the line on content standards, ensure decisions align with how the organization wants to present itself publicly, and have the credibility to push back on department requests that conflict with brand or messaging strategy.

A representative from IT or digital infrastructure

Web governance decisions have technical consequences: CMS configuration, hosting, security, integrations with other systems. Without someone in the room who understands those consequences, the council will make decisions that look straightforward on paper and turn into six-month infrastructure projects in practice.

A senior generalist from leadership or operations

Someone with cross-organizational visibility, a mandate to represent the public interest rather than a departmental interest, and ideally some authority to make resource allocation calls. In a municipal context, this is often a CAO's office representative, a director of corporate services, or equivalent. In a nonprofit or business context, it's a COO, operations director, or senior manager. Their role is to break ties, escalate resourcing decisions, and ensure the website is serving organizational strategy, not just departmental preferences.

One rotating departmental seat (optional but recommended)

Departments that are heavy website contributors (parks and recreation, planning, finance, communications) benefit from having a voice in governance discussions. Rather than giving every department a permanent seat (which recreates the original problem), rotate one seat quarterly among department liaisons. This gives departments visibility into the process and a channel for raising issues without giving every department blocking power.

What the council reviews and decides

A governance council that reviews everything becomes another bottleneck. A good charter defines what categories of decision belong to the council and what categories are delegated to the web lead or individual departments.

Council-level decisions

These are decisions that affect the whole site, set precedent, or involve resource allocation across departments:

Web lead-level decisions (delegated)

These do not require council sign-off:

Departmental decisions (within their approved scope)

Departments that have been onboarded to the CMS and trained on content standards make these independently:

The boundary between these categories is what makes delegation work. When departments know what they can do without approval, they stop submitting everything to the web lead as a request. When the web lead knows what they can decide without escalating, they stop bringing minor decisions to the council for cover. The council's time is preserved for decisions that genuinely require its attention.

Meeting structure and cadence

A governance council that meets monthly for two hours with a vague agenda will drift toward the committee outcome described at the start of this post. A council that meets monthly for sixty minutes with a fixed agenda structure that forces decisions will not.

Recommended cadence

Monthly for core business, with a quarterly strategic review.

Monthly meetings handle active decisions: reviewing the content backlog, adjudicating escalated department requests, reviewing metrics against goals, and approving any in-flight changes. Sixty minutes is sufficient if the agenda is structured and pre-read materials are distributed forty-eight hours in advance.

Quarterly reviews zoom out: reviewing the site's performance against the year's strategic objectives, reviewing the governance process itself (what's working, what's creating friction), and setting content and investment priorities for the next quarter.

Meeting agenda structure

A fixed agenda structure for every monthly meeting means participants know what to expect and come prepared. Here is the structure I recommend:

1. Metrics review (10 minutes)

The web lead presents three to five pre-selected indicators: traffic to priority pages, key event completion rates, top internal search terms, and any significant anomalies. No deep analysis — the council has reviewed the pre-read. This section surfaces anything that requires a decision response.

2. Active decisions (25 minutes)

The council works through decisions that are ready to be made. Each decision item in the pre-read has: a clear statement of the issue, the web lead's recommended resolution, any alternatives, and the information needed to make the call. The council discusses, decides, and records the outcome before moving to the next item. Items without sufficient information are not discussed — they go back to the web lead for more information and return the following month.

3. Escalated requests (15 minutes)

Department requests that the web lead could not resolve bilaterally are reviewed. Each request has a standard summary format (department, request description, why it can't be resolved at the web lead level, web lead recommendation). The council decides: approve, reject, defer with conditions, or escalate to leadership.

4. Forward agenda (10 minutes)

What is coming in the next thirty to sixty days that the council needs to be aware of? Upcoming high-traffic periods, planned content pushes, vendor renewals. No decisions here — this is situation awareness.

The strict time allocation is intentional. Items that run over their time do not eat into subsequent items. They go back to the pre-read for the following month with more preparation.

Handling conflicting departmental priorities

Competing priorities from different departments are the most common source of governance gridlock. Department A wants to promote a major upcoming program on the homepage. Department B wants the same space for a service they argue is more frequently accessed. Department C is threatening to build a microsite outside the main domain if their content doesn't get better visibility soon.

Without a decision framework, the council debates relative importance indefinitely and either makes an arbitrary call or defers. With a framework, the discussion becomes: does this request meet the criteria, or doesn't it?

A three-factor prioritization framework

Evaluate competing requests against these three factors, each scored one to five:

User impact: How many users need this content, and how urgently? Content that serves a high-volume recurring user need scores higher than content serving a low-frequency edge case. Urgent service information (emergency closures, active health advisories) scores higher than promotional content for a future event.

Organizational priority: Is this content aligned with the organization's stated strategic priorities for the year? If leadership has identified economic development as a strategic focus, related content has a higher organizational priority score than content unrelated to that focus.

Technical feasibility: Can this be implemented given current resources and technical constraints? A request that requires a new page template developed from scratch scores lower for immediate implementation than a request that uses existing infrastructure.

Total the scores. Higher total means higher priority in the queue. The framework doesn't make the decision for the council — a score of 12 doesn't automatically beat a score of 9 — but it shifts the conversation from "my department's content is more important" to "here's how this request scores against the established criteria."

When a department disagrees with a council decision made using the framework, the burden is on them to show why the scoring was wrong, not to relitigate the argument that their content is important. This is the cultural shift that makes governance work over time.

The decision log

Every decision the council makes should be recorded in a shared, accessible decision log. Not meeting minutes — a decision log. The difference matters.

Meeting minutes record what was discussed. A decision log records what was decided, why, and what it authorizes or prevents.

Each entry in the log should contain:

The decision log serves several functions. It prevents decisions from being relitigated when council membership changes. It creates a record that departments can reference when they think governance decisions were made arbitrarily. It surfaces patterns: if the same department is escalating requests repeatedly, that's a signal the bilateral process isn't working and the onboarding or scope definition needs revisiting.

Keep the log in a shared location accessible to all council members and department liaisons. A simple spreadsheet works fine. A shared document in your intranet works. What doesn't work: buried in a folder that only the web lead can access, or reconstructed from meeting notes six months later.

Sample first-year governance calendar

Here is a realistic first-year structure for a new governance council:

Month 1: Foundation

Months 2-3: Backlog clearance

Months 4-6: Steady-state operations

Month 6: First quarterly review

Months 7-12: Refinement

The terms of reference: the one document worth writing before you meet

Every governance council needs one founding document: a terms of reference (ToR). It can be one page. It does not need to be formal or legalistic. It needs to establish:

The ToR is not a policy document. It does not need legal review. It is a shared understanding between council members about the rules of the process they've agreed to operate within. The act of writing and adopting it — even if it takes one meeting to finalize — is what converts a committee into a governance body.

If you're setting up a new governance structure or trying to fix one that's stalled, get in touch for a governance design session that produces a working charter, decision framework, and first-meeting agenda your team can walk into ready.