Change management doesn't require a change advisory board — what a two-person MSP actually needs

Change management has a reputation, at small MSPs, as something for organizations big enough to afford a committee — a change advisory board, a formal request-for-change template, a multi-day approval cycle before anyone touches a production system. That reputation is mostly earned by how it's usually described, not by what it actually requires. The underlying discipline behind change management is simple: know what changed, know why, know who approved it, and know how to undo it if it goes wrong. None of that requires a board. It requires the four answers to exist somewhere, consistently, for every change that could break something.

What actually breaks without any change discipline at all

• A patch goes out to a whole client's fleet at once, something breaks, and there's no record of exactly what version or config changed to compare against — so troubleshooting starts from zero instead of from a diff
• Two technicians independently \"fix\" the same recurring issue with different approaches on different days, and neither knows the other did it, so the environment drifts in ways nobody can explain later
• A rollback exists in theory but was never actually planned for the specific change being made, so when something breaks at an inconvenient hour, undoing it becomes its own emergency
• A client asks why something changed on their systems and the honest answer is nobody quite remembers, which is a worse conversation than any technical failure

What a two-person shop actually needs

• A ring rollout habit for anything applied broadly — patches, config changes — so a bad change surfaces on a small subset before it's live everywhere, without needing a committee to decide the ring size
• One place the change, the reason, and the approver are recorded together, even if the approver is the same person who made the change, because the record is what matters, not the org chart implying separation of duties
• A rollback plan written down before the change goes out, not improvised after it breaks something
• A habit of checking that habit — a short, honest review of whether the last few changes actually followed the pattern, since the discipline decays fastest exactly when there's no board enforcing it

Change management at two people isn't a smaller version of change management at two hundred. It's the same four questions, answered by fewer people, faster, and just as consistently.

This is part of why patch deployment with ring rollout is one of the job classes we've actually built end-to-end and use in our own practice rather than left as a roadmap promise — a signed, staged rollout is change management mechanics without the committee, and it works the same whether the person approving the ring is a change board or the one technician who owns the client. The discipline scales down; the bureaucracy doesn't have to come with it.