Running the programme: decision rights, conflict, and issues
What you'll learn
Set decision rights and an impersonal rulebook so conflicts settle at the gate, run a light steering cadence on the burndown and top risks, and pre-decide the response to the usual issues — tracked as an owned risk list.
- Set decision rights up front: who owns the rulebook, who approves exceptions, what auto-blocks a release.
- Impersonal, pre-agreed rules settle most conflict at the gate, not on a manager's desk.
- Run a light cadence: one accountable owner, a short regular steering check on burndown + top risks, a clear escalation path.
A Clean Core programme creates predictable tension between teams: feature teams feel remediation is a tax on their roadmap, architects worry that shortcuts add new debt, and the business worries about disruption. Leadership resolves this not by adjudicating each case but by setting decision rights in advance — who owns the rulebook (the check variant), who can approve an exception, and what automatically blocks a release. When the rules are agreed and impersonal, most conflicts settle themselves at the gate instead of escalating to a manager's desk.
The collaboration model that works is a light operating rhythm: a single owner accountable for the programme, a short regular steering check on the burndown and the top risks, and a clear escalation path for the rare genuine deadlocks. The aim is to make the common decisions automatic — a new high-priority finding blocks the change — and reserve leadership attention for the rare trade-offs, such as a costly rewrite worth deferring this quarter.
Expect a familiar set of issues and pre-decide the response: scope creep is answered by a phased plan with bounded capacity; exemptions piling up by giving every exception an expiry and a review; a burndown that stops falling by stopping new debt at the gate before chasing old debt; and team resistance by making progress visible and protecting the capacity so the work isn't unpaid overtime. Tracking these as a short, owned risk list — each with a named owner and a review date — is what separates a programme that finishes from one that quietly stalls.
Key points
- Set decision rights up front: who owns the rulebook, who approves exceptions, what auto-blocks a release.
- Impersonal, pre-agreed rules settle most conflict at the gate, not on a manager's desk.
- Run a light cadence: one accountable owner, a short regular steering check on burndown + top risks, a clear escalation path.
- Make common decisions automatic; reserve leadership attention for rare, costly trade-offs.
- Pre-decide responses to the usual issues (scope creep, exemption sprawl, flat burndown, resistance) and track them as an owned risk list.
Examples
A feature team and an architect disagree on whether a shortcut ships. Because a new high-priority finding is a pre-agreed build-breaker, the gate decides — and the only thing escalated is whether to grant a time-boxed, expiring exception.
Source notes: clean-core-curriculum (business synthesis)
Ask Claude
Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.