Has anyone actually written a stakeholder 'rules of engagement' that survives shifting priorities?

i’m a PM at a growth-stage b2b saas. the biggest stressor isn’t shipping; it’s priority whiplash when a VP rolls in with a fresh “p0” that nukes what we agreed last week. i’ve been testing a lightweight “rules of engagement” doc: who decides what, how we trade scope when interrupts land, when we accept mid-sprint changes, and how we record decisions. wins so far: a 2‑week “change window” with a single triage, a swap‑equal‑effort rule for mid-sprint adds, and a one-line DRI map. fewer drive-by asks, calmer standups. where it broke: revenue dipped and the doc had no teeth—no exec sponsor, no SLA for interrupts, and no public change log, so commitments got memory-holed. if you’ve made one that actually holds under pressure, what absolutely has to be in it (metrics like cost of delay? pre-commit signoffs? trade rules?) and how did you socialize it so it survives leadership pivots?

stop writing manifestos. make a one‑pager the VP signs. spell out who decides, what gets traded when a new “p0” appears, and the cost you’re willing to pay (capacity/lead time hit). publish a public change log, weekly. no signature, no process—it’s just vibes. also, tie interrupts to an explicit swap: add X, drop Y of equal size. if sales yells, point to the log. they hate receipts. keep it boring, mechanical, and very visible. otherwise, enjoy the chaos treadmill.

i tried a tiny “rules” doc in a student build team. the trick was a visible change log + swap of equal effort. ppl stopped sneaking requests when they saw thier names on it lol. small, but it worked.

What gives your document “teeth” is institutionalizing it as a ritual, not a reference. Establish a single intake and a standing review (e.g., weekly) chaired by the executive sponsor who cares most about predictability—often Ops or Engineering. Define an interrupt SLA (response time, allowed volume per cycle) and tie each accepted change to a compensating trade. Maintain a public decision record with rationale and expected impact on lead time or revenue risk. Use a simple cost-of-delay rubric to rank urgent asks, and pre-wire the rubric with Finance so it’s not debatable mid-meeting. Finally, circulate a one-slide summary in your exec update every cycle; repetition is what hardens norms.

Love this! You’re close. Make it visible, keep it simple, and get one exec to champion it. The combo of a public log and swap rule can really stick. You’ve got this!

I tried something similar after a brutal quarter where every week got re-written. My first doc was too academic and nobody read it. What finally clicked: a one-page “trade rules” plus a Friday change review with our COO. We made a promise—new priority in equals equal scope out, documented in a shared log. People still tried to sidebar me, but I’d just paste the log link and say, “Add it to Friday.” Took a few weeks, but the noise dropped and engineering reclaimed focus time.

Context switching typically costs 20–40% throughput in software teams, and mid-iteration changes raise cycle time variance. To counter that, enforce a single intake, cap work-in-progress, and measure lead time before/after interrupts. Use a basic cost-of-delay formula (value per week vs. effort) to prioritize “P0s” transparently. Publish a weekly change log and plot accepted changes versus missed sprint goals. When we added executive sign-off plus a 1:1 scope swap, change volume fell ~30% and predictability (commit-to-complete) improved ~15% over two months.