Running a Salesforce Steering Committee That Actually Steers

The Anatomy of an Ineffective Steering Committee

In enterprise Salesforce delivery, the steering committee (SteerCo) is theoretically the highest governing body of the programme. It is comprised of executive sponsors, department heads, technology leaders, and delivery partners who gather regularly to oversee progress, resolve major escalations, and protect the programme's budget and strategic alignment. However, in reality, a shocking number of Salesforce steering committees are highly ineffective, operating as expensive, slow-moving status meetings where executives silently review color-coded slides and listen to generic updates without making a single meaningful decision.

The primary driver of steering committee failure is **status update fixation**. Traditional committees spend 90% of their meeting time walking through historical progress decks, detailing developer velocity metrics, reviewing past task completions, and explaining minor schedule variances. By the time the technical team finishes presenting these details, the meeting is almost over, leaving only a few rushed minutes to address critical program risks or architectural escalations. Executives leave the meeting feeling under-utilized, while the delivery team leaves without the critical strategic decisions and approvals needed to maintain momentum.

The second driver is the **lack of explicit decision-making authority**. Many committees are established without a clear operational charter defining who owns the final vote, what constitutes a quorum, and what financial or scope boundaries the committee can approve. When a major escalation occurs—such as a budget overrun on middleware licensing or a resource conflict between sales and service workstreams—the committee descends into endless debate. Instead of making an active decision, they defer the choice to subsequent sub-committees or request further analysis, stalling the program and accumulating technical and operational debt.

Finally, steering committees frequently suffer from **executive disconnect**. Senior business sponsors are often time-poor and unfamiliar with the Salesforce platform. If the delivery team presents escalations using highly technical, platform-specific terminology (such as discussing trigger recursion, governor limits, or metadata merge conflicts), the executives will check out. They cannot evaluate the business impact of these technical risks, leading them to either rubber-stamp poor architectural choices or block critical DevOps investments. To secure true program velocity, we must restructure our steering committees, transforming them from passive status forums into high-performance decision-making machines.

Designing the Executive Salesforce SteerCo Charter

To rescue a steering committee from passive status fixation, delivery leaders must implement a formal, signed **Salesforce Steering Committee Charter**. The charter is a foundational governance document that establishes the committee's purpose, membership, voting rules, and explicit boundaries of authority, ensuring that every participant understands their operational responsibilities and accountability from day one.

The core of the charter is the **Explicit Authority matrix**. The charter must define exactly what decisions the committee can authorize without escalating to the board or executive committee. This includes setting clear financial approval thresholds (e.g. approving contract variations up to £250,000 or license purchases up to a specific limit), authorizing major milestone schedule shifts (up to a set number of weeks), and resolving cross-workstream design disputes. By establishing these predefined boundaries, the committee can act decisively, eliminating the need to request external approvals for standard programme remediation.

The charter must also define the **Membership and Voting structure**. Membership must be restricted to individuals who hold absolute accountability for their department's budget and operations, including the Chief Technology Officer, the heads of the business units adopting Salesforce (such as the VP of Sales or Customer Success), and the Program Director. The charter should enforce a strict **no-proxy rule**: if an executive sponsor cannot attend, they cannot delegate their voting authority to a junior staff member who lacks the mandate to make financial or operational commitments. This ensures that the meeting maintains its decision-making capacity.

Additionally, the charter establishes the **formal quorum and escalation paths**. A meeting is only valid if a quorum of voting sponsors is present. If a critical decision must be made and quorum is not met, the charter defines an immediate, time-boxed escalation procedure to secure written approvals within 24 hours. By codifying these governance rules, you prevent key decisions from stalling due to calendar conflicts, protecting the delivery team's sprint momentum and maintaining platform velocity.

Structuring the SteerCo Agenda for Decisions, Not Status

Once the charter is signed, the delivery manager must radically restructure the steering committee's meeting format. The absolute standard rule of successful executive governance is the **90/10 Rule**: 90% of the meeting time must be dedicated to discussing key decisions, escalated risks, and strategic alignment; only 10% may be spent reviewing high-level programme health metrics. Status updates are completely removed from the oral agenda, replaced by a pre-distributed dashboard.

The foundation of this new model is the **Pre-Read Dashboard**. At least 48 hours prior to the meeting, the delivery team distributes a concise, three-page status report. The report utilizes standardized RAG (Red-Amber-Green) indicators to summarize schedule, budget, scope, and technical quality. It includes key milestone tracking, active sprint velocity, and a summary of budget burn rate. Executives are expected to review this document prior to entering the room. The meeting begins with the immediate assumption that the status report has been read, bypassing the need to walk through slides and launching directly into the decision-making agenda.

The oral meeting agenda must be structured around the **Decision Log**. The agenda is divided into three distinct segments. The first segment is **Decisions Required** (30 minutes). The Program Director presents a maximum of three critical choices, using structured **Decision Briefs**. Each brief maps out the context, the business impact, the options considered, the financial implications, and the lead architect's recommended path. The committee debates the options and records a formal, binary vote. The second segment is **Escalated Risk Remediation** (20 minutes), where the committee approves mitigation plans for active threats. The final segment is **Strategic Alignment Review** (10 minutes).

By structuring the meeting around active choices, you change the energy of the room. Executives are engaged because they are executing their strategic mandate. They are not being talked at; they are actively steering the program, resolving resource bottlenecks, and removing blockers that would otherwise stall the technical delivery team, ensuring a clean, predictable path to go-live.

Resolving Escalated Risks and Managing Budget Requests

One of the primary strategic functions of a steering committee is the resolution of escalated programme risks and the management of budget contingency requests. In complex Salesforce rollouts, risks often cross departmental boundaries—such as an integration delay caused by an external ERP team, or a licensing cost variation driven by an increase in active users. When these risks escalate, the SteerCo must act as a collaborative resolution body, not a combative auditing committee.

To manage risk escalations effectively, the delivery team must utilize a **Quantitative Risk Register**. Risks cannot be described in vague terms; they must be quantified by probability, operational impact, and cost. For example, instead of stating: "The middleware integration is delayed," the register documents: "Delay in SAP integration API delivery by external vendor. Probability: High. Impact: Postpones end-to-end testing by 3 weeks, costing £45,000 in technical team burn rate." This quantitative formatting immediately frames the risk in language that business sponsors understand, allowing them to evaluate the cost of inaction.

When a risk requires a **budget contingency request**, the Program Director must present a formal variation request. The variation request must document three elements: the root cause of the variation, the technical and business alternatives considered, and the precise ROI of the requested budget. For instance, if the lead architect recommends purchasing a specialized AppExchange backup tool to secure data compliance, the brief must contrast the software cost with the massive financial risk of manual database restoration and compliance failure. The committee evaluates the request against the remaining programme contingency funds, ensuring that additional investments are routed to high-value, strategic needs.

Additionally, the steering committee must enforce a strict **remediation accountability loop**. When a risk mitigation plan or budget variation is approved, the committee assigns a specific executive sponsor to own the remediation action. If the risk is a delay in partner API delivery, the Chief Technology Officer is tasked with personally contacting the partner's leadership to resolve the bottleneck. This active executive intervention removes operational roadblocks that the delivery team has no authority to touch, accelerating progress and protecting the project timeline.

Maintaining Executive Sponsorship and Strategic Alignment

Salesforce is not merely a database or a departmental CRM; in modern enterprises, it is a core business transformation platform that alters how multiple departments interact with customers and each other. Consequently, a Salesforce rollout inevitably triggers **intense departmental conflicts** over business processes, sharing rules, and resource allocation. The steering committee must act as the ultimate arbiter of these conflicts, maintaining long-term strategic alignment and protecting the program's vision.

The first major alignment challenge is **cross-departmental process ownership**. For example, during a Sales and Service Cloud implementation, sales leaders may demand a highly open sharing model to maximize pipeline visibility, while service leaders demand a restricted model to secure sensitive customer support logs. The delivery team cannot resolve this conflict; attempting to configure a compromised middle ground leads to a messy sharing architecture and security gaps. The steering committee must step in, review the business impacts against the strategic charter, and declare a single, authoritative policy that the entire organization must follow.

The second challenge is maintaining **long-term executive sponsorship**. As a multi-year Salesforce transformation progresses, initial excitement can decay, especially if business units experience minor go-live friction or operational change fatigue. To combat this, the steering committee must establish a **Continuous Value Realisation workstream**. The committee runs regular audits to track active system usage, user feedback, and financial ROI against the original business case. By communicating these positive outcomes to the board and the wider organization, the committee preserves strategic support, protecting the program from budget cuts and maintaining platform investment.

Ultimately, a high-performing steering committee transforms Salesforce delivery from a high-risk technical project into a highly successful, strategic business capability. By combining a signed operational charter, a decision-focused agenda, quantitative risk management, and active executive sponsorship, you establish a world-class governance framework that protects your team, secures your budget, and guarantees the long-term strategic success of your platform.