What a "change advisory board" should look like when there are two people to advise

A change advisory board, in its enterprise ITIL form, is a standing committee that reviews proposed changes before they go live — multiple stakeholders, a scheduled meeting, a formal risk assessment template. A two-person MSP reading that description reasonably concludes it doesn't apply to them, and then usually throws out the underlying function along with the enterprise ceremony around it. That's the mistake worth catching, because the function — a deliberate pause and check before a risky change ships — doesn't stop being valuable just because there's no committee-sized team to run it.

What CAB is actually for, underneath the ceremony

Strip away the meeting and the multi-stakeholder sign-off, and a CAB exists to answer three questions before a change goes live: what could this break, how would we know if it did, and how do we undo it if it does. A large organization needs a formal committee to get multiple perspectives on those questions reliably. A two-person shop doesn't need the committee — it needs a habit that forces those three questions to actually get asked, because the natural failure mode for a two-person team isn't "we forgot to convene a committee," it's "we were both slammed and the change went out without either of us pausing on it."

A lightweight version that actually fits two people

• A written pre-flight checklist for anything touching production infrastructure — not a meeting, a short list you actually fill in: what's changing, what could break, what the rollback looks like, has the other person looked at it.
• A hard rule that risky changes get a second pair of eyes, even asynchronously — a Slack message with the plan and a thirty-second "does this look right to you" before executing, not a scheduled review.
• A rollback plan required in writing before execution, not improvised after something goes wrong — the discipline of writing it down before you need it is what actually changes behavior under pressure.
• A change log that exists whether or not anyone reviews it in real time, so that when something breaks three weeks later, "what changed recently" has an actual answer instead of two people trying to reconstruct it from memory.

None of this requires software — a shared document and a habit is enough to start. What it does require is treating the habit as non-negotiable specifically during the moments it's most tempting to skip: the Friday-afternoon fix, the "it's a small change" change, the fix applied directly on a client's box because writing it down felt like overhead in the moment. Those are exactly the changes a CAB, even a two-person one, exists to catch.

The natural failure mode for a two-person team isn't forgetting to convene a committee — it's that both people were slammed and the change went out without either of them pausing on it.

We hold ourselves to a version of this internally at Nexus, on our own infrastructure and our own product changes — a lightweight pre-flight and rollback discipline scaled to our actual team size rather than a borrowed enterprise process we don't have the headcount to run. We don't have a change-management module in the product built around this yet; it's a practice, not a shipped feature, and we'd rather describe it accurately as that than imply otherwise. If you're running a two- or three-person shop, the checklist above costs almost nothing to start and mainly requires the discipline to use it on the change that feels too small to bother with — which is usually the one that bites.